Modules and Packages practice questions

Nothing; by default, all names are exported.

Why it fails: Merely relying on the default import-star behavior does not populate the `analytics` package namespace. When a package is imported, Python executes its `__init__.py`, but unless that file contains an explicit `import` or `from ... import` statement, no submodule names (like `mean` or `std`) are bound as attributes of the package. Therefore, `from analytics import *` would find nothing to import, even though Python normally exports all names not starting with an underscore when `__all__` is absent.

__all__ = ['stats.mean', 'stats.std']

Why it fails: This uses dotted paths in `__all__`, which is invalid because Python looks for simple attribute names in the namespace. `stats.mean` is not a valid attribute name, so this would cause an error or import nothing.

__all__ = ['mean', 'std']

Why it fails: Setting `__all__ = ['mean', 'std']` alone is insufficient because the names `mean` and `std` are not defined in the `analytics` package namespace without an explicit import. Thus, `from analytics import *` would not be able to find them.

from . import helper

Why it fails: Incorrect. 'from . import helper' attempts to import from the current package (the subpackage itself), not from the parent package.

from ... import helper

Why it fails: Incorrect. 'from ... import helper' uses three dots, which refers to the grandparent package, not the immediate parent.

from math import * as m

Why it fails: Invalid because the asterisk (*) cannot be combined with an alias in a `from ... import` statement.

import math m

Why it fails: Invalid because it is missing the `as` keyword; correct syntax is `import math as m`.

import math alias m

Why it fails: Invalid because `alias` is not a valid keyword; the correct keyword is `as`.

from math import sin as m

Why it fails: Imports only the sin function from math and aliases it as m, but it does not import the math module itself; thus it is not a valid way to import the module with an alias.

Modify the PYTHONPATH environment variable to include the directory containing your 'pipeline' package before the site-packages directory.

Why it fails: Modifying PYTHONPATH does not consistently override site-packages in Python 3.8 and later, and is not the most reliable method.

Rename your local 'pipeline' package to something else and update all imports.

Why it fails: Renaming the package avoids the conflict but requires updating all imports and is less elegant than using a virtual environment.

Add an __init__.py file with a special import hook to override the global package.

Why it fails: Adding an import hook in __init__.py is a non-standard, fragile solution that can lead to unexpected behavior and maintenance issues.

There is a circular import between utils.py and the main script.

Why it fails: A circular import between utils.py and the main script raises an ImportError, but the error message typically states that a name cannot be imported from a partially initialized module (for example, 'cannot import name X from partially initialized module Y'). It does not produce a generic 'No module named utils' error, because the module is found and parsing begins; the failure occurs during execution of the module. Therefore, the observed symptom of a missing module points away from circular imports.

The directory containing utils.py is not in sys.path.

Why it fails: Python's import mechanism searches for a module in the ordered list of directories stored in sys.path, which begins with the directory containing the script that was invoked. If utils.py resides in a directory that is not on sys.path — for example, if the script is executed from a different current working directory or invoked via a wrapper that doesn't add the directory — the import statement fails with ModuleNotFoundError: No module named 'utils'. This is the most direct explanation for an isolated import failure of a module that exists on disk but is invisible to the interpreter.

The directory lacks an __init__.py file.

Why it fails: An __init__.py file is required only for a directory to be treated as a regular package when Python imports a module using dotted notation, such as 'from pkg import utils'. If utils.py is a standalone module in the same directory as the main script, the directory is already on sys.path as the script directory, and the import behaves correctly even with no __init__.py. Furthermore, since Python 3.3, namespace packages can be imported without __init__.py, so the absence of this file would not produce a missing-module error for a directly adjacent file.

The __init__.py file must include 'import shapes.circle' to make the submodule accessible.

Why it fails: Wrong. The __init__.py does not need to include 'import shapes.circle'; it could use 'from . import circle' or any import that brings the submodule into the package namespace. The key is that the submodule must be imported as a submodule, but the statement is not necessarily required or accurate.

The submodule name 'circle' conflicts with the class name 'Circle' due to case sensitivity.

Why it fails: Python is case-sensitive, so the lowercase identifier `circle` and the capitalized class name `Circle` are distinct names that cannot conflict in the same namespace. A class named `Circle` inside the `circle.py` module lives in that module's namespace, not in the package's namespace, and therefore does not shadow or interfere with a package attribute called `circle`. The actual reason the code fails is that the package's `__init__.py` never loaded the `circle` submodule as an attribute of `shapes`, so the problem is entirely related to how imports are structured, not to case sensitivity.

The import statement 'import shapes.circle' is invalid because submodules must be imported using 'from' syntax.

Why it fails: Wrong. 'import shapes.circle' is a valid syntax for importing a submodule. While 'from shapes import circle' is also valid, the import statement does not require 'from' syntax. The error occurs because the submodule is not imported in the package's __init__.py.

The __init__.py file in /opt/mypipeline/core/ is missing or empty.

Why it fails: The file exists and was working before; the error is about importing 'process', not about the package itself.

The import statement in run.py is incorrect; it should use 'from core.processor import process as process' or similar.

Why it fails: The import syntax is correct and was previously working.

The PYTHONPATH environment variable is set incorrectly; it should include /opt/mypipeline before /opt/external_lib.

Why it fails: It does include /opt/mypipeline first, but even so, if external_lib's core is a namespace package or if there's a .pth file, it could still interfere. However, the most direct cause is the conflict.

The package does not have an `__init__.py` file.

Why it fails: The exhibit explicitly shows an __init__.py file inside mypackage, so the package is a regular package, not a namespace package lacking an initialization file. Even if that file were absent, Python 3 would treat the directory as a namespace package, and the empty dir() result would still be caused by the defined __all__ being empty, not by the missing __init__.py.

The `__init__.py` file must be empty for `from package import *` to work.

Why it fails: __init__.py does not need to be empty for from package import * to work; it often contains imports, variable assignments, or package initialization logic. The behavior of import * is controlled by defining __all__ if present, otherwise by importing all public names (not starting with an underscore) that are defined in or imported into __init__.py. An empty __init__.py is simply one possibility, not a requirement.

`__all__` causes submodules to be ignored during `import *`.

Why it fails: This option misstates the role of __all__: it does not cause submodules to be ignored; instead, it explicitly lists the names that should be imported when a client uses from mypackage import *. If a submodule is included in __all__, it will be imported, so __all__ does not inherently ignore submodules. Here the empty __all__ means no names, including no submodules, are imported, but that is a consequence of leaving the list empty, not of __all__ ignoring submodules.

from .mypackage import foo

Why it fails: `from .mypackage import foo` uses a relative import (leading dot), which is only valid inside a module that is part of a package, because the import system needs a non-empty `__package__` to resolve the relative reference. A top-level script, such as one located in a parent directory, has `__package__` set to `None` or empty, so this statement raises `ImportError: attempted relative import with no known parent package`. Additionally, the dot in `.mypackage` would refer to a package nested within the current package, not the top-level `mypackage` package.

import foo from mypackage

Why it fails: `import foo from mypackage` is invalid Python syntax because the `import` statement does not support the ordering `import <module> from <package>`. The correct grammar is either `import mypackage.foo` or `from mypackage import foo`; putting the module name before `from` produces a `SyntaxError`. This mistake likely confuses the natural English phrasing with Python's required `from ... import ...` structure.

Only func from module_a

Why it fails: A package's __init__.py controls what the wildcard imports; if it re-exports names from module_a and module_b, both sets enter the global namespace. It tempts because a package exposing only one module's function would indeed yield just that name.

It raises an ImportError because __all__ should contain function names

Why it fails: __all__ is a list of strings naming exported objects, and omitting it simply falls back to importing all public names; no ImportError occurs. It tempts because a malformed __all__ containing non-string entries would raise an error, which is a genuine but different failure.

func from both module_a and module_b

Why it fails: Star imports respect each module's __all__; if module_a defines __all__ excluding func, only module_b's func is exported, so the global name binds to one function, not both. The option tempts when neither module declares __all__, since then all public names, including func, are imported.

os.path.dirname(os.path.abspath(__file__))

Why it fails: Correct. `os.path.abspath(__file__)` converts Python's often relative `__file__` attribute into an absolute path using the current working directory as the reference point, and `os.path.dirname()` then strips the filename component to leave the directory. This reliably yields the directory containing the script as it was actually invoked, without resolving symbolic links. It is the standard way to locate sibling files such as a configuration file in the same folder as the script.

os.getcwd()

Why it fails: Incorrect. `os.getcwd()` returns the current working directory of the process, which is the directory from which the Python interpreter was started, not necessarily the directory in which the script file resides. A user might run the script from anywhere—for example, `python /path/to/script.py` from the home directory—making `os.getcwd()` depend on the caller's location rather than the script's location. This makes it unreliable for locating a configuration file that is stored alongside the script.

os.path.abspath(__file__)

Why it fails: Incorrect. `os.path.abspath(__file__)` returns the absolute path to the script file itself, including the filename and extension, not the directory that contains it. If you used this directly to construct a config file path you would be treating the .py file as if it were a directory, which would fail at runtime. The missing step is `os.path.dirname()`, which is exactly what separates the correct expression from this one.

from mypackage import bar.foo

Why it fails: Python's import statement cannot chain attribute access after 'import'; 'bar.foo' is invalid syntax there. It is tempting because dotted paths appear in 'from mypackage.bar import foo', which is valid, but that form names the module directly rather than nesting it after 'import'.

from . import bar.foo

Why it fails: The syntax `from . import bar.foo` is invalid: `import` after `from` accepts module names, not dotted attribute paths, so `bar.foo` cannot follow it. It tempts because relative imports with a leading dot are legitimate for sibling modules, and that form would work as `from .bar import foo`.

import mypackage.bar.foo

Why it fails: `import mypackage.bar.foo` binds the top-level name `mypackage`, not `foo`, and Python treats `foo` as a submodule, not the function. It tempts because dotted absolute imports are valid syntax, and this form would correctly import the module `mypackage.bar`.

The __init__.py file in the lib directory is empty and should contain imports.

Why it fails: An empty __init__.py is valid and normal; it marks the directory as a package, and its contents do not affect import resolution. It tempts because missing package markers cause ImportErrors, but here the marker exists, so the failure lies elsewhere.

The lib directory is not in sys.path when the script is run from cron.

Why it fails: The relative import from . requires the script to run as part of a package; executing the file directly sets __package__ to None, so no package context exists regardless of sys.path. It tempts because cron's minimal environment often breaks imports, but adding lib to sys.path cannot resolve a relative import.

The cron job uses a different Python interpreter that does not have the required standard library.

Why it fails: The ImportError concerns the local config module, not a standard library module, so interpreter differences are irrelevant; cron's python is typically the same binary. It tempts because cron environments do differ, but the failing import is application code, not stdlib.

The import order is wrong; sys.path.append should be after the import.

Why it fails: Order is fine; the append happens before the import.

mylib.py exists in the same directory as the script.

Why it fails: That would not cause an error.

The appended path does not exist on the filesystem.

Why it fails: Path existence is not checked at append time.

python -c "print(requests.__path__)"

Why it fails: The `__path__` attribute is only defined on packages (directories containing modules), not on simple single-file modules. Since `requests` is a package, `requests.__path__` does exist, but it returns the list of directory paths that make up the package, not the location of the `__init__.py` file itself. Running this command would print something like `['/usr/local/lib/python3.12/site-packages/requests']`, which is indeed a path, but it's the package directory, not the module file. The question asks for where the module is installed, and while that directory is related, it doesn't directly point to the module's `__file__` as a specific file.

pip list --path

Why it fails: `pip list --path` is not a valid pip subcommand or option; pip's `list` command supports options like `--format`, `--outdated`, and `--user`, but not `--path`. If you run it, pip will error out with something like `Usage: pip list [options]` and `no such option: --path`, so it cannot reveal the install location. The correct way to get paths from pip is `pip show -f <package>`, which shows the `Location:` field and the list of files, or `pip list -v` for verbose output. Because the option doesn't exist, this is a non-starter for finding where requests was installed.

pip show requests

Why it fails: `pip show requests` displays metadata about the package, such as Name, Version, Summary, Home-page, Author, License, and Location, but the file path shown in `Location` is the parent directory where the package is installed, not the full path to the module file itself. It does not directly give you `requests.__file__` or the path to `requests/__init__.py`; you would still need to combine `Location` with the package's subdirectory structure. Moreover, the command's output can be confusing because `Location` typically points to site-packages, but it doesn't reveal the exact file that gets imported. So while `pip show` is useful for metadata, it does not directly answer the question of where the module's code lives with the same precision as the Python one-liner.

Add 'module_a' to __all__ in mypackage/__init__.py.

Why it fails: Adding `module_a` to `__all__` in `mypackage/__init__.py` only affects `from mypackage import *` by telling Python which names to export on wildcard imports. It does not create a binding for `module_a` in the `mypackage` namespace, nor does it influence an explicit `from mypackage import module_a` statement, which requires the name to already be present and imported. Furthermore, `__all__` has no effect inside a subpackage, so this change cannot repair the import in `module_b.py`.

Move module_b.py to the mypackage directory.

Why it fails: Moving `module_b.py` to the `mypackage` directory is not a fix because it alters the entire package layout rather than correcting the import statement. If `module_b.py` is moved to `mypackage`, it is no longer inside the subpackage, so all its relative imports would need to change, and any other module expecting the original subpackage path would break. The import `from mypackage import module_a` would then refer to the top-level package, but the developer's goal is to keep `module_b` in the subpackage and simply import a sibling/parent module using proper relative syntax.

Use import mypackage.module_a instead.

Why it fails: `import mypackage.module_a` may succeed if `mypackage` is importable as a top-level package on `sys.path`, but it is the wrong approach for intra-package imports. Hard-coding the full absolute path makes the code fragile: if the top-level package is renamed, installed under a different distribution, or used as a nested module, the import breaks. It also bypasses the relative import mechanism that Python provides specifically for sibling and parent references, and can lead to subtle double-import issues when both absolute and relative forms are used.

Place all code in a single module.

Why it fails: Collapsing all code into a single module sidesteps the ImportError only by removing the import statements that expose the cycle, but it does not resolve the underlying dependency problem. A single module sacrifices separation of concerns, making the code harder to test, reuse, and maintain because every component shares one namespace. The issue is not that Python's import system is broken; it is that the module boundaries were poorly designed, and merging them merely hides that design flaw.

Use relative imports instead of absolute imports.

Why it fails: Relative imports, such as `from . import module_b`, only alter the lookup path used during package loading, not the order in which modules are initialized. If module A and module B import each other at the top level, a relative import still references a partially initialized module, so it raises ImportError just as an absolute import would. The cyclic dependency remains because the static dependency graph is unchanged; only the import syntax differs.

Use the import statement inside function definitions to defer imports.

Why it fails: Deferring imports with function-level `import` statements delays the lookup until runtime, by which time the target module has likely finished loading, so it can avoid the immediate ImportError. However, this is a workaround that obscures actual dependencies, makes code harder to statically analyze, and risks AttributeError if the deferred module has not yet been imported when an attribute is accessed. Restructuring the modules is more maintainable because it removes the cycle itself instead of hiding it behind deferred execution.

Set __all__ to an empty list

Why it fails: Setting __all__ to an empty list in shapes/__init__.py would make `from shapes import *` import absolutely nothing, because the star-import mechanism honors __all__ literally. Although this avoids unintended name collisions, it defeats the purpose of exposing the package's submodules and forces users to import each submodule manually. Thus, an empty list is explicitly the wrong way to define the package's public API.

import Math

Why it fails: The import statement treats module names as case-sensitive identifiers, so "Math" is a completely different name from "math". The Python standard library does not contain a module named "Math"; it provides the lowercase "math" module. If you attempt this import, Python raises ModuleNotFoundError because no module file matching that exact capitalization exists anywhere on the search path.

import math,

Why it fails: A trailing comma in an import statement is invalid syntax because Python's grammar for import statements expects a comma-separated list of module names with no dangling separator. Unlike tuple literals, where a trailing comma is explicitly allowed, an import statement cannot end with a comma. This line therefore produces a SyntaxError before the import system even begins its work.

from math import

Why it fails: This version is incomplete because the from-import syntax requires a target after the keyword import: you must specify either a concrete attribute name or an asterisk. With no target, the parser cannot decide what to bind and reports a SyntaxError at compile time. A corrected statement would be like "from math import sqrt" or "from math import *".

Manually check sys.modules before importing.

Why it fails: Inspecting sys.modules before importing is not a recommended solution to circular imports because it only reveals whether a module object has been inserted into the cache, not whether that module has finished executing. During a circular import, the dependent module may be present in sys.modules as a partially initialized object, so checking for its existence can give a false sense of safety and then fail when you try to access a name that has not yet been defined. This approach also adds fragile, boilerplate conditions to the import section without addressing the underlying dependency problem.

Use the __all__ variable to control what is exported.

Why it fails: The __all__ variable merely declares which names are exported when a client performs a wildcard import with from module import *. It has no effect on the internal import ordering or on how the import system resolves circular references, because circular imports are determined by load-time execution flow, not by name visibility. Even if you carefully define __all__, the imported module's top-level code still references the other module before the other module has finished initializing, so the circular failure remains. Thus, __all__ is a namespace-publicity tool, not a dependency-management tool.