Python Programming Modules, Packages and Error Handling Syllabus

Modules, Packages and Error Handling syllabus — full chapter and topic list

Expand any chapter to see its topics and sub-topics. This is the whole examinable outline for Modules, Packages and Error Handling in Python Programming, not a summary of it.

1. 1

   Modules and Packages

   4 topics

   • Importing Modules
   • Creating Your Own Modules
   • Packages and __init__.py
   • The __name__ == '__main__' Idiom
2. 2

   Package Management with pip

   3 topics

   • Installing Third-Party Packages
   • Requirements Files
   • PyPI and Dependency Management
3. 3

   Exception Handling

   4 topics

   • try, except, else and finally
   • Exception Hierarchy and Built-in Exceptions
   • Raising Exceptions
   • Custom Exception Classes
4. 4

   File Handling and I/O

   5 topics

   • Opening and Closing Files
   • Reading and Writing Text Files
   • Context Managers and the with Statement
   • Working with Binary Files
   • File System Operations with os and pathlib
5. 5

   The Python Standard Library

   4 topics

   • Math and Random Modules
   • Date and Time
   • Collections Module
   • itertools and functools

Modules, Packages and Error Handling flashcards for Python Programming

21 of 51 cards from the Modules, Packages and Error Handling deck — real questions with worked answers.

1. What is a module in Python, and how do you make its contents available in another file?

   A module is any file with a .py extension containing Python definitions and statements. You make its contents available using the import statement, e.g. `import math`, which runs the module once and binds its name in the current namespace.

2. Compare `import module`, `from module import name`, and `from module import *`.

   `import module` binds the module object (access via `module.name`). `from module import name` binds a specific attribute directly (access as `name`). `from module import *` binds all public names (those not starting with `_`, or those listed in `__all__`), polluting the namespace and hurting readability.

3. How do you import a module under a different (alias) name, and why is it done?

   Use the `as` keyword: `import numpy as np`. It shortens long names, avoids naming conflicts, and follows community conventions (e.g. `import pandas as pd`).

4. When you run `import my_module`, how does Python find the file, and what object results?

   Python searches the directories listed in `sys.path` (script dir, PYTHONPATH entries, and installation-dependent defaults). On success it executes the file once and creates a module object bound to `my_module` in the local namespace.

5. What is `sys.path` and what does it control?

   `sys.path` is a list of strings giving the directories Python searches for modules to import. It is initialized from the script's directory (or current dir), the PYTHONPATH environment variable, and installation defaults. You can append to it at runtime to add search locations.

6. What does `__all__` control in a module?

   `__all__` is a list of strings naming the public attributes exported when a client does `from module import *`. If undefined, `*` imports all names not beginning with an underscore.

7. When you create your own module, how do you prevent its top-level test/demo code from running on import?

   Guard the code with `if __name__ == '__main__':`. Code inside this block runs only when the file is executed directly as a script, not when it is imported.

8. What is the value of the `__name__` variable when a module is (a) imported versus (b) run directly?

   When imported, `__name__` equals the module's name (e.g. `'my_module'`). When the file is run directly as the main program, `__name__` equals the string `'__main__'`.

9. Explain the purpose of the `if __name__ == '__main__':` idiom.

   It lets a file serve dual roles: as an importable module (whose functions/classes are reusable) and as a standalone script. Code under the guard executes only during direct execution, providing an entry point without side effects on import.

10. What is a package in Python, and how has it traditionally been distinguished from an ordinary directory?

    A package is a directory that groups related modules into a namespace. Traditionally a directory became a (regular) package by containing an `__init__.py` file, which Python runs when the package is first imported.

11. What is the role of `__init__.py` in a package?

    It marks a directory as a regular package and runs on first import. It can be empty, or it can initialize the package, define `__all__`, or import selected submodule names to expose them at the package level (e.g. `from .core import main`).

12. What is a namespace package, and how does it differ from a regular package?

    A namespace package (PEP 420, Python 3.3+) is a package that has NO `__init__.py` and can be split across multiple directories/`sys.path` entries. A regular package has an `__init__.py` and lives in a single directory tree.

13. In a package, what is the difference between an absolute import and a relative import?

    An absolute import gives the full path from the top-level package, e.g. `from mypkg.utils import helper`. A relative import uses leading dots to reference the current package: `from . import sibling` (same package) or `from .. import cousin` (parent package).

14. How do you install a third-party package from PyPI, and what tool is standard?

    Use pip, the standard package installer: `pip install package_name`. It downloads from the Python Package Index (PyPI) and installs the package plus its dependencies.

15. What is PyPI?

    PyPI (the Python Package Index) is the official public repository of third-party Python packages, hosted at pypi.org, from which pip downloads and installs packages by default.

16. What is a requirements file, and what is its conventional name?

    A requirements file, conventionally named `requirements.txt`, lists a project's dependencies (one per line, optionally version-pinned) so an environment can be reproduced with `pip install -r requirements.txt`.

17. How do you generate a requirements file capturing the currently installed packages?

    Run `pip freeze > requirements.txt`, which writes every installed package with its exact version in `name==version` format.

18. In a requirements file, what is the difference between `requests==2.31.0`, `requests>=2.31.0`, and `requests~=2.31.0`?

    `==2.31.0` pins exactly that version. `>=2.31.0` allows that version or any newer. `~=2.31.0` (compatible release) allows `>=2.31.0, <2.32.0` — patch-level updates but not a new minor version.

19. What is a virtual environment and why is it used in dependency management?

    A virtual environment is an isolated directory with its own Python interpreter and installed packages, created with `python -m venv env`. It prevents dependency conflicts between projects by keeping each project's packages separate from the system Python.

20. What is semantic versioning (MAJOR.MINOR.PATCH), and what does each part signal?

    MAJOR increments for incompatible (breaking) API changes, MINOR for backward-compatible new features, and PATCH for backward-compatible bug fixes. So version `2.5.1` means major 2, minor 5, patch 1.

21. Write the general structure of a full try/except/else/finally statement and state when each clause runs.

    `try:` runs the protected code. `except SomeError:` runs only if a matching exception is raised. `else:` runs only if the try block raised no exception. `finally:` always runs (exception or not), used for cleanup.

See more Modules, Packages and Error Handling flashcards →

Planning Modules, Packages and Error Handling for Python Programming

Modules, Packages and Error Handling (Python Programming) FAQ