Modules and Packages practice questions

Append the repository path to sys.path in the script.

Why wrong: Appending a repository URL to sys.path is incorrect because sys.path is a list of local filesystem directory paths, not remote endpoint locators; Python's import machinery will attempt to treat the URL string as a directory path on disk and fail. Even if the repository were checked out locally and its raw path were appended, this would only affect the current interpreter session's module lookup without registering the package with pip or installing its transitive dependencies. It also provides no version metadata or dependency resolution, making the approach non-portable and non-reproducible.

Place the package files in the site-packages directory manually.

Why wrong: Manually copying package files into site-packages bypasses pip's dependency resolution, so required third-party libraries will not be installed automatically and version conflicts go undetected. It also leaves no pip metadata (such as RECORD or dist-info), meaning pip cannot cleanly upgrade or uninstall the package, and a future pip command may overwrite or orphan those manually placed files. This approach is especially fragile for packages with compiled extensions or data files that must be placed in multiple locations.

Use os.system to run a pip install command from within the script.

Why wrong: Invoking pip via os.system in a script is an anti-pattern because it shells out to a separate process, captures no meaningful return status through Pythonic exceptions, and requires the script author to manually construct and sanitize command-line arguments. A package installed while the script is running will not be importable in the same interpreter unless the post-installation path is explicitly refreshed, and the operation is invisible to the caller's dependency manager. It also creates coupling to the host operating system's shell, making the script non-portable and harder to debug; instead, dependencies should be installed before the program runs.

Nothing; by default, all names are exported.

Why wrong: This option is incorrect because 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 wrong: 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 wrong: 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.

sys.path.append('utils/config.py')

Why wrong: sys.path must contain directory paths, not paths to module files. Appending 'utils/config.py' tells the import machinery to treat that exact file as a search location, so when importing config, Python would look under utils/config.py/config.py or fail outright, rather than adding utils/ to the search path. To make config importable, append the containing directory 'utils', not the file itself.

sys.path = os.path.join(sys.path, 'utils')

Why wrong: os.path.join concatenates string path components; sys.path is a list, so calling os.path.join(sys.path, 'utils') raises a TypeError because join does not accept a list as its first argument. Even if the list were coerced to a string, the result would be a single path string, not a list of search directories, and assigning that to sys.path would break the module search mechanism. sys.path must remain a list, so you should append to it directly rather than trying to join.

os.chdir('utils')

Why wrong: os.chdir('utils') changes the process's current working directory, which affects relative file I/O but does not modify the module search path stored in sys.path. Imports are resolved against sys.path entries, not against the OS working directory, except for a possible empty-string entry that may be resolved dynamically. Simply changing directories won't make modules in utils importable in a reliable or portable way, so this is not a correct solution.

import formulas

Why wrong: This statement binds only the module object named `formulas` in the current namespace, not the `calculate` function. To call the function you must use `formulas.calculate(...)`, which requires the module prefix and means `calculate` is not directly accessible. It also executes the entire module's top-level code, which may be unnecessary overhead if you only need one function.

import calculate from formulas

Why wrong: This is invalid Python syntax and will raise a `SyntaxError` at compile time. The `import` statement grammar requires the module to come first after the keyword `import`, followed by the `from` clause only when using the `from module import name` form. The correct order is `from formulas import calculate`, because `from` introduces the source module, and `import` introduces the names to bind.

import formulas as f

Why wrong: This statement aliases the entire `formulas` module under the name `f`, so the function is still accessed as `f.calculate(...)`. The name `calculate` itself is not bound in the current namespace; only `f` is available, which means direct calls like `calculate(...)` will raise a `NameError`. Aliasing a module is useful for shortening a long module name, but it does not import a specific function.

from . import helper

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

from ... import helper

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

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

Why wrong: 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 wrong: 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 wrong: 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.

analytics/, analytics/statistics/ (__init__.py), analytics/ml/ (__init__.py)

Why wrong: The top-level `analytics` directory lacks an `__init__.py` file, so Python will not recognize it as a package. Consequently, even though `statistics` and `ml` have `__init__.py`, they cannot be imported as subpackages of `analytics` because the parent package is not importable. A package must have `__init__.py` at every level, starting from the root, for the entire hierarchy to be traversable by the import system.

analytics/ (__init__.py), analytics/statistics/ (__init__.py), analytics/ml/ (__init__.py), analytics/__init__.py (file)

Why wrong: This structure is impossible and redundant because a directory cannot contain two different files with the identical name `__init__.py`. The list implies both a directory entry `analytics/ (__init__.py)` and a separate file `analytics/__init__.py` in the same location, which is a contradiction. Even if it were syntactically allowed, having multiple `__init__.py` files in one directory would be redundant and serve no purpose; the correct structure has exactly one `__init__.py` per package directory.

analytics/ (__init__.py), analytics/statistics/, analytics/ml/

Why wrong: Here the top-level `analytics` is correctly marked as a package, but the subdirectories `statistics` and `ml` are missing their own `__init__.py` files. Without those files, Python 3 treats them as ordinary directories, not as packages, so `import analytics.statistics` or `from analytics import ml` will fail with a ModuleNotFoundError. They are simply not included in the package's module namespace.

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

Why wrong: 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 wrong: 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 wrong: 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.

Packages cannot be imported using the import statement with dot notation.

Why wrong: This statement is false because the `import` statement fully supports dot notation for referencing nested packages and modules. For example, `import os.path` imports the `path` submodule of the `os` package, and `from collections.abc import Iterable` uses dot notation in the module path. Dot notation is the standard syntax for traversing the package hierarchy, so imports with dots are not only possible but are the primary mechanism for accessing subpackages.

An __init__.py file is required in every directory to make it a package.

Why wrong: This statement is incorrect for Python 3.3 and later. The introduction of namespace packages allows a directory to act as a package without an `__init__.py` file, provided it is part of a namespace package spread across multiple portions on `sys.path`. If no regular package with the same name is found, the import system can still create a namespace package from a directory that lacks `__init__.py`. Therefore, while regular packages traditionally require `__init__.py`, it is not a universal requirement for every directory.

A package is a single .py file.

Why wrong: This statement is wrong because a single `.py` file is classified as a module, not a package. A package is a directory containing a collection of modules and possibly subpackages, usually identified by an `__init__.py` file (or as a namespace package without one). The distinction matters for import behavior: importing a module executes that one file, while importing a package executes its `__init__.py` and gives access to its submodules and subpackages.

import app.operations.math_ops.calculate

Why wrong: The statement 'import app.operations.math_ops.calculate' is invalid because Python's import statement treats each dotted segment as a module or package name. Functions are attributes of modules, not sub-modules, so this syntax tries to find a module named 'calculate' inside 'math_ops' and raises a ModuleNotFoundError. To import a function, you must use the from-import form or manually reference the attribute after importing the module.

from app.import operations.math_ops import calculate

Why wrong: This line is a syntax error because the word 'import' appears after 'from' and again before the function name; the grammar is 'from <module> import <object>', and it allows only one 'import'. Additionally, the dotted path 'app.import operations.math_ops' contains a space and an invalid component 'import', which Python's parser rejects immediately. Even without the space, you cannot place 'import' inside the module path.

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

Why wrong: 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 wrong: 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 wrong: 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 wrong: This option is wrong because 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 wrong: This option is incorrect because __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 wrong: 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.

Activate virtual environment, Create virtual environment, Install packages, Deactivate virtual environment

Why wrong: This sequence is invalid because the activation command (e.g., `source myenv/bin/activate`) will fail if `myenv` does not already exist; activation requires a pre-existing structure with a `pyvenv.cfg` and a `bin` or `Scripts` directory that only the creation step produces. Without first running the venv-creation command, there is no isolated interpreter or `site-packages` to reference, so the shell simply returns an error and the rest of the steps cannot proceed. In contrast, the correct order is to create the environment first, then activate its known path, ensuring the activation script can locate the necessary files.

Create virtual environment, Install packages, Activate virtual environment, Deactivate virtual environment

Why wrong: Running `pip install` before activation causes the `pip` command to resolve to the global (system) Python's pip, so the packages are written into the global `site-packages`, not into the virtual environment intended for isolation. This defeats the entire purpose of a virtual environment, which is to keep project dependencies separate from system-wide packages and from other projects. Activation must occur immediately after creation and before any package installation so that the `PATH` is updated and pip targets the environment's own `site-packages`; otherwise, the environment remains empty and the global environment becomes polluted.

Create virtual environment, Activate virtual environment, Deactivate virtual environment, Install packages

Why wrong: Deactivating the environment immediately after activation leaves the shell back with the global Python and pip, so any subsequent `pip install` command installs packages globally rather than inside the virtual environment. The sequence implies that package installation happens after deactivation, which means the environment never receives the dependencies it was created to hold—rendering the setup useless. The proper order is to keep the environment active during all installation work, then deactivate only after all packages are installed and you no longer need the isolated interpreter on your `PATH`.

Define handler class, import http.server, create HTTPServer instance, call serve_forever()

Why wrong: Defining the handler class before importing http.server fails because Python resolves base classes at class definition time. Since http.server is not yet in the module's namespace, the expression http.server.BaseHTTPRequestHandler raises NameError. The import statement must execute first to make the module's attributes available. Thus, starting with the class definition is invalid.

Import http.server, create HTTPServer instance, define handler class, call serve_forever()

Why wrong: Creating the HTTPServer instance before defining the handler class is invalid because the constructor's second argument must be the actual handler class (e.g., a subclass of BaseHTTPRequestHandler). At that point, the name for the handler class is either undefined (NameError) or, if a placeholder was used, the server would be bound to the wrong class and fail on every request. The handler class must be fully defined first so it can be passed as a reference and stored by the server for later per-request instantiation.

Import http.server, define handler class, call serve_forever(), create HTTPServer instance

Why wrong: Calling serve_forever() before constructing the HTTPServer object is a logical and runtime error: a method call requires an existing instance. Since no instance has been created, the call either refers to an unbound name (NameError) or, in some contexts, an attribute lookup on None (AttributeError). The server's main loop must be started on an already-bound and configured server object, so instantiation must precede the serve_forever() call.

len(): Applies a function to every item of an iterable and returns a map object.

Why wrong: This statement is false because it confuses len() with map(). len() takes a single object and returns an integer representing the number of items, using the __len__ protocol; it never accepts a function as an argument and does not produce a map object. The behavior described — applying a function to every item — is exclusively that of map(), so the function call to len() would actually raise a TypeError when passed a function.

map(): Returns the length (number of items) of an iterable.

Why wrong: This option incorrectly attributes the behavior of len() to map(). When map() is called, it returns a map object (an iterator), not an integer length, and it requires at least one iterable along with a callable to apply. The length of an iterable is determined by len(), while map() is used for element-wise transformation, so the statement conflates two fundamentally different operations.

2 ** 3: 6

Why wrong: Incorrect. The correct output of 2 ** 3 is 8, because the exponentiation operator (**) raises 2 to the third power, meaning 2 * 2 * 2. The value 6 would result from multiplying 2 by 3 (2 * 3), which is a different operation. This mistake likely stems from confusing exponentiation with ordinary multiplication.

10 // 3: 1

Why wrong: Incorrect. In Python, the // operator performs floor division, which for 10 // 3 gives the integer quotient 3, since 3 goes into 10 exactly 3 times with a remainder. The value 1 is actually the remainder of the division, which would be obtained using the modulo operator: 10 % 3. Floor division always returns the largest integer less than or equal to the exact quotient when both operands are positive, so the result cannot be 1.

from .mypackage import foo

Why wrong: `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 wrong: `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.

PYTHONPATH then sys.path

Why wrong: This option misidentifies the search order because PYTHONPATH is not a separate path searched before sys.path; rather, its entries are inserted directly into sys.path after the script's directory. At startup, Python sets sys.path[0] to the directory containing the script, then prepends the directories listed in PYTHONPATH to the remaining sys.path entries, which already include standard library and site-packages. Thus the actual lookup sequence is script-directory, then PYTHONPATH entries, then the rest of sys.path—not simply 'PYTHONPATH then sys.path'.

sys.path + [current directory]

Why wrong: This option reverses the actual placement of the current directory in sys.path. When a script is executed, Python inserts the directory containing that script at sys.path[0], so it is searched first, not last. Appending the current directory to the end of sys.path would mean local modules would only be found after searching all other paths, which contradicts Python's documented behavior of giving the script's directory highest priority. The correct representation is '[current directory] + sys.path', where sys.path already contains PYTHONPATH entries and standard library paths.

[current directory] + sys.path

Why wrong: This is correct because Python builds sys.path by placing the directory containing the executed script at index 0, then appending the remaining entries derived from PYTHONPATH, the standard library, and site-packages. During an import, the interpreter iterates through sys.path in order, so the script's directory is examined first, giving local modules precedence over installed packages. This ordering ensures that a module in the same directory as the script can be imported without relying on the process's current working directory or on PYTHONPATH being set.

They are automatically created when a directory containing .py files is added to sys.path.

Why wrong: Merely adding a directory containing .py files to sys.path does not automatically create a namespace package. A directory without __init__.py can indeed be imported as a namespace package, but this happens at import time, not as a side effect of modifying sys.path. Furthermore, whether a namespace package is formed depends on the import system finding one or more matching portions, not on the presence of .py files in the directory.

They can only contain __init__.py files.

Why wrong: This claim is doubly wrong: namespace packages deliberately have no __init__.py, and they are not limited to containing only that file. In fact, a namespace package can hold any number of Python modules, nested subpackages, and data files, exactly like a regular package. The absence of __init__.py is what enables multiple directories to merge, but it imposes no restriction on the kinds of files the directories may contain.

They require an __init__.py file.

Why wrong: If a directory contains an __init__.py, the import system classifies it as a regular package, not a namespace package. Namespace packages were designed specifically to make __init__.py optional, which allows different directories to share a package name without any single file claiming ownership. Thus, requiring an __init__.py would contradict the very definition of a namespace package and would actually disable the feature.

The module file has a syntax error.

Why wrong: A syntax error in the module's source code is discovered by the parser during bytecode compilation, before the module is ever executed. When the import system attempts to compile the file, the parser raises a SyntaxError (or a subclass like IndentationError), not an ImportError. This is a compile-time failure distinct from the import machinery failing to locate or initialize the module.

The module's __init__.py is empty.

Why wrong: An empty __init__.py is perfectly valid and is, in fact, a normal way to mark a directory as a regular package in Python (before PEP 420 namespace packages). When Python imports the package, it executes __init__.py; if the file is empty, it simply has no side effects, and the import completes successfully. The presence or absence of content in __init__.py never causes ImportError; it only affects whether the package defines any import-time initialization behavior.