{"title":"Creating Modules","description":"","content":"The first three chapters in this section covered how to import modules and what happens during import. This one is about the other side: writing them. Once a script grows past one screen of code, breaking it into modules keeps the project readable. This lesson covers what makes a `.py` file a module, how to organize code inside one, the `if __name__ == \"__main__\":` pattern that lets a file act as both script and library, where Python looks for modules, and how to install a module so it's available from anywhere on the machine.\n\n---\n\n# What Makes a `.py` File a Module\n\nA module is any `.py` file Python can find and load. There's no decoration required, no declaration, no tag. Code in a file with a `.py` extension, placed somewhere Python looks, is a module.\n\nThe module's name is the filename without the `.py` extension. `pricing.py` is the module `pricing`. `customer_orders.py` is the module `customer_orders`. The name matters because that's what other code writes in `import` statements, so pick filenames that are short, lowercase, and use underscores rather than hyphens (Python's parser reads `cart-utils` as subtraction).\n\nThe smallest possible module is a file `pricing.py` next to a main script:\n\n\n```python\n# pricing.py\nTAX_RATE = 0.08\n\ndef cart_total(prices):\n return sum(prices) * (1 + TAX_RATE)\n```\n\n\nThat's a module. Two lines that matter, plus a top-level constant and a top-level function. Everything inside this file is, in Python's terms, the module's body. When another file writes `import pricing`, Python finds this file, runs the body from top to bottom, and stores the resulting names on a module object.\n\nThe act of writing the file is the entire creation step. No registration, no setup, no metadata file. Compare to languages that require a class declaration, registration with a build system, and an entry in a manifest; Python looks at directories on its search path and treats any `.py` file it finds as a module.\n\nA module's body is a one-time setup script that builds up a namespace. The constant `TAX_RATE = 0.08` puts the name `TAX_RATE` on the module. The `def cart_total(...)` puts the name `cart_total` on the module. Anything else done at the top level (open a file, build a dictionary, call a function) also runs at import time and either sets up state or has side effects. Side effects come up again later in this lesson.\n\nUsing the module from another file in the same folder:\n\n\n```python\n# shop.py\nimport pricing\n\ncart = [29.99, 14.99, 9.99]\nprint(f\"Total: ${pricing.cart_total(cart):.2f}\")\n```\n\n\nTwo files, one import line. Everything beyond this point in the lesson is about doing the same thing well rather than only making it work.\n\n---\n\n# Module-Level Code Runs on First Import\n\nWhen Python imports a module for the first time, it runs every top-level statement in the file, in order, from top to bottom. Function bodies don't run (a `def` defines a function; it doesn't call it), but everything else does: assignments, function definitions, class definitions, prints, file reads, anything at the outermost indentation.\n\nThis first-time run builds the module's namespace. The names defined at the top level become attributes of the module object. After the body finishes, Python stores the module object in `sys.modules` and hands it back to whoever asked for the import.\n\nThe \"first time\" qualifier matters. Python imports each module exactly once per process. The first `import pricing` runs the file. Every later `import pricing` (regardless of location in the codebase) finds the already-loaded module in `sys.modules` and reuses it. The body doesn't run again.\n\nA print at module level demonstrates this:\n\n\n```python\n# pricing.py\nprint(\"pricing.py is loading\")\n\nTAX_RATE = 0.08\n\ndef cart_total(prices):\n return sum(prices) * (1 + TAX_RATE)\n```\n\n\n\n```python\n# shop.py\nprint(\"shop start\")\nimport pricing\nimport pricing\nimport pricing\nprint(\"shop end\")\nprint(pricing.cart_total([10]))\n```\n\n\nThe `print` inside `pricing.py` fires once, between `shop start` and `shop end`. The second and third `import pricing` statements find the module already cached and skip the file entirely. Module-level code is initialization that runs once per process.\n\nPutting expensive work at the top level is a trap. A module that reads a 100 MB file or opens a network connection at the top level forces every program that imports anything from the module to pay that cost on first import, even if only one small constant is needed. Push expensive work into a function the caller invokes explicitly when needed.\n\n\n```python\n# Bad: every importer pays the cost, whether they need the data or not\nPRODUCTS = load_products_from_disk(\"products.json\") # 100 MB at import time\n\n# Better: callers explicitly trigger the load\ndef load_products():\n return load_products_from_disk(\"products.json\")\n```\n\n\nThe first version moves the cost to import. The second version lets callers pay it only when they need the products.\n\nModule-level work happens once, but that \"once\" is at import time, which is often the worst time for it. Imports happen at startup, before any of the calling code starts running. Heavy module-level work delays startup for every script that imports the module, including tools like linters and IDEs that scan code without running it.\n\nThe other consequence of \"module body runs once\" is that the top level can intentionally build shared state. Lookup tables, configuration dicts, regex objects: things that are expensive to build once and cheap to read forever. Be intentional about it. Unintended side effects at module level (printing, writing files, making network calls) are a common source of bugs.\n\n\n```python\n# pricing.py: deliberate one-time setup\nimport re\n\n# Compile a regex once at import time so every call to validate_coupon\n# reuses the same compiled pattern.\n_COUPON_RE = re.compile(r\"^[A-Z]{4,8}\\d{0,4}$\")\n\nTAX_RATE = 0.08\nSHIPPING_THRESHOLD = 50.0\n\ndef validate_coupon(code):\n return bool(_COUPON_RE.match(code))\n\ndef cart_total(prices):\n return sum(prices) * (1 + TAX_RATE)\n```\n\n\nThe underscore-prefixed `_COUPON_RE` is a convention: it's \"internal to this module\" and not part of the public API. Callers can still reach it (Python doesn't enforce private names), but the underscore signals that the name might change.\n\n---\n\n# `if __name__ == \"__main__\":` for Dual-Use Files\n\nA `.py` file can play two roles. It can be a library that other files import, and it can be a script run directly with `python pricing.py`. Both are legitimate, and Python doesn't force a choice between them.\n\nRunning a file as a script and importing it both run the file's top-level code. When the file should do one thing when imported (define functions, set up constants) and a different thing when run directly (print a demo, run tests, start the program), the two cases need a way to be distinguished.\n\nThe hook is `__name__`. The first lesson introduced it: a dunder attribute Python sets on every module. For an imported module, it's the import name. For the file Python is running directly, it's the special string `\"__main__\"`.\n\nThe `if __name__ == \"__main__\":` idiom uses that distinction. Code inside the block only runs when the file is the entry point. When the file is imported by something else, `__name__` is the module's name (like `\"pricing\"`), the condition is false, and the block is skipped.\n\nA typical layout:\n\n\n```python\n# pricing.py\n\"\"\"Pricing helpers.\"\"\"\n\nTAX_RATE = 0.08\n\ndef cart_total(prices):\n return sum(prices) * (1 + TAX_RATE)\n\ndef apply_discount(price, percent):\n return price * (1 - percent / 100)\n\nif __name__ == \"__main__\":\n sample_cart = [29.99, 14.99, 9.99]\n print(f\"Sample cart total: ${cart_total(sample_cart):.2f}\")\n print(f\"50% off $99.99: ${apply_discount(99.99, 50):.2f}\")\n```\n\n\nRunning this file directly:\n\n\n```shell\n$ python pricing.py\nSample cart total: $59.36\n50% off $99.99: $50.00\n```\n\n\nImporting it from another file does **not** trigger the demo:\n\n\n```python\n# shop.py\nimport pricing\n\nprint(pricing.cart_total([10, 20]))\n```\n\n\n\n```shell\n$ python shop.py\n32.4\n```\n\n\nThe `if __name__ == \"__main__\":` block didn't run during the import because `pricing.__name__` was `\"pricing\"`, not `\"__main__\"`. The functions and constants were defined as usual, and `shop.py` used them without seeing the demo output.\n\n\n```mermaid\nflowchart TD\n File[\"pricing.py\"]:::cyan\n RunDir[\"python pricing.py\"]:::orange\n Imp[\"import pricing\"]:::orange\n Set1[\"__name__ == '__main__'\"]:::green\n Set2[\"__name__ == 'pricing'\"]:::teal\n Block1[\"if block runs
demo / CLI prints\"]:::green\n Block2[\"if block skipped
only defs run\"]:::teal\n\n File --> RunDir --> Set1 --> Block1\n File --> Imp --> Set2 --> Block2\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n```\n\n\nThe diagram shows the two paths. Both run the file's top-level code (functions and constants get defined either way). The difference is the value of `__name__`, and that one difference controls whether the demo block runs.\n\nThree typical uses for the block:\n\n**Quick demos and smoke tests.** A few lines that exercise the module's main features. Running the file checks it works without needing a separate test file. Convenient during development, easy to leave in place.\n\n**Command-line interfaces.** When a module is useful from the command line (a converter, a calculator, a one-shot tool), the `if __name__` block is where argument parsing and dispatch live:\n\n\n```python\n# pricing.py\nimport sys\n\nTAX_RATE = 0.08\n\ndef cart_total(prices):\n return sum(prices) * (1 + TAX_RATE)\n\nif __name__ == \"__main__\":\n args = [float(x) for x in sys.argv[1:]]\n print(f\"${cart_total(args):.2f}\")\n```\n\n\n\n```shell\n$ python pricing.py 29.99 14.99 9.99\n$59.36\n```\n\n\nNow `pricing.py` is a library when imported and a small CLI when run.\n\n**Entry points for whole programs.** A larger application often has a `main.py` (or `__main__.py` for packages) whose entire job is the `if __name__` block. It imports everything it needs from other modules and starts the program. The same file can be imported by tests without firing the main function.\n\n\n```python\n# main.py\nfrom shop.cart import build_cart\nfrom shop.pricing import cart_total\n\ndef run():\n cart = build_cart()\n print(f\"Total: ${cart_total(cart):.2f}\")\n\nif __name__ == \"__main__\":\n run()\n```\n\n\nPutting the work inside a `run()` function and only calling it from the guard block is a common pattern. It keeps the entry point trivial, makes the program easy to test (call `run()` from a test), and lets other code import `main.py` for its definitions without accidentally running the whole program.\n\n---\n\n# Module Attributes\n\nThe four most common dunder attributes on a module are `__name__`, `__doc__`, `__file__`, and `__loader__`. As a module author, three of them are useful to set or read.\n\n**`__doc__`: the module docstring.** A triple-quoted string at the top of the file becomes `__doc__`. Tools like `help()`, documentation generators, and IDEs read this string to describe a module. Writing one is a one-minute habit that pays off forever:\n\n\n```python\n# pricing.py\n\"\"\"Pricing helpers for the AlgoMaster store.\n\nExposes:\n cart_total(prices) -- subtotal plus tax for a list of prices\n apply_discount(price, percent) -- price after a percent discount\n TAX_RATE -- the sales tax rate used by cart_total\n\"\"\"\n\nTAX_RATE = 0.08\n\ndef cart_total(prices):\n \"\"\"Return the total of a cart, including tax.\"\"\"\n return sum(prices) * (1 + TAX_RATE)\n```\n\n\nThe module's docstring is the first thing a reader sees. A one-line description plus a brief list of what the module exposes turns a bare file into a self-describing module. Module docstrings also feed directly into Sphinx and similar tools that build a project's API reference automatically.\n\n**`__name__`: the module name (or `\"__main__\"`).** Already covered. It's read, not written by the module author. The one place it changes behavior is the `if __name__ == \"__main__\":` idiom.\n\n**`__file__`: the path to the source file.** Useful when a module needs to find files shipped alongside it: a config file in the same directory, a JSON data file, a template. Take the directory of `__file__` and build paths relative to it:\n\n\n```python\n# pricing.py\nfrom pathlib import Path\n\n# Find the file next to this module, no matter where the caller runs from.\n_THIS_DIR = Path(__file__).parent\n_TAX_TABLE_PATH = _THIS_DIR / \"tax_rates.json\"\n\ndef load_tax_rates():\n import json\n return json.loads(_TAX_TABLE_PATH.read_text())\n```\n\n\nWhen a user runs `python /some/other/path/their_script.py`, the current working directory has nothing to do with where `pricing.py` lives. `__file__` resolves that: it's always the path to `pricing.py` itself, so derived paths point to the right place. `pathlib` is covered properly in the file-handling section; here the relevant fact is that `__file__` is the anchor.\n\nA module's full list of dunder attributes is longer (`__package__`, `__spec__`, `__cached__`, `__builtins__`, `__loader__`), but for modules in user code, the three above cover the everyday needs.\n\n---\n\n# Documenting Modules\n\nA well-documented module gives a reader three things they need to use it: a sentence about what it's for, a brief list of what it exposes, and per-function docstrings that explain inputs and outputs. None of this takes much time, and the quality difference is large.\n\nA reasonable template:\n\n\n```python\n\"\"\"One-line summary of what this module is for.\n\nOptional longer paragraph that gives context: when to use this module,\nhow it relates to other modules in the project, any gotchas.\n\nPublic API:\n cart_total(prices) -- subtotal plus tax for a list of prices\n apply_discount(price, percent) -- price after a percent discount\n TAX_RATE -- standard sales tax rate\n\nExample:\n >>> from pricing import cart_total\n >>> cart_total([29.99, 14.99])\n 48.5784\n\"\"\"\n\nTAX_RATE = 0.08\n\ndef cart_total(prices):\n \"\"\"Return the total of a cart, including tax.\n\n Args:\n prices: An iterable of numeric prices.\n\n Returns:\n The sum of all prices multiplied by (1 + TAX_RATE).\n \"\"\"\n return sum(prices) * (1 + TAX_RATE)\n\ndef apply_discount(price, percent):\n \"\"\"Return a price after a percentage discount.\n\n Args:\n price: The original price.\n percent: The discount percent (0-100).\n\n Returns:\n price * (1 - percent / 100)\n \"\"\"\n return price * (1 - percent / 100)\n```\n\n\nThe module docstring is what someone running `help(pricing)` sees. The function docstrings are what they see when they run `help(pricing.cart_total)`. Both are also what an IDE shows on hover. A few minutes of writing saves hours of guessing later.\n\nThere are documentation conventions (Google style, NumPy style, reST style) that go into more structure for type information and complex parameter descriptions. For most modules, the \"Args / Returns\" style above is enough. Pick a convention per project and stick with it.\n\nThe `>>> from pricing import ...` lines in the docstring are an example of a doctest: a runnable example that documents how to use the function. They're parsable by the standard `doctest` module, which can run them as part of a test suite to verify the documentation still matches the code. Not every project uses doctests, but the format is readable even without automatic execution.\n\n---\n\n# Where Python Looks for Modules: `sys.path`\n\nWhen `import pricing` runs, Python doesn't scan the whole disk. It walks through a specific, ordered list of directories called `sys.path`. The first directory containing `pricing.py` (or a `pricing/` package) wins.\n\nThe list can be inspected directly:\n\n\n```python\nimport sys\nfor path in sys.path:\n print(repr(path))\n```\n\n\nThe exact contents depend on how Python was installed and what's running. The order is what matters. `sys.path` is built from three main sources:\n\n1. **The directory of the running script.** Or an empty string `''` meaning \"current working directory\" at the REPL. This is what makes \"put `pricing.py` next to `shop.py` and import it\" work without any setup.\n2. **The directories listed in the `PYTHONPATH` environment variable**, if it's set. Used to add ad-hoc directories without touching the script.\n3. **The standard library directories** that ship with Python.\n4. **The `site-packages` directory** where `pip` installs third-party packages.\n\n\n```mermaid\nflowchart TD\n Start[\"import pricing\"]:::cyan\n P1[\"1. Script's directory
(or CWD)\"]:::orange\n P2[\"2. PYTHONPATH
directories\"]:::orange\n P3[\"3. Standard library\"]:::orange\n P4[\"4. site-packages
(pip-installed)\"]:::orange\n Found[\"Run pricing.py once
Cache in sys.modules\"]:::green\n Fail[\"ModuleNotFoundError\"]:::red\n\n Start --> P1\n P1 -->|found| Found\n P1 -->|not found| P2\n P2 -->|found| Found\n P2 -->|not found| P3\n P3 -->|found| Found\n P3 -->|not found| P4\n P4 -->|found| Found\n P4 -->|not found| Fail\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n```\n\n\nThe diagram shows the search order. Python stops at the first match. When `pricing.py` exists in both the project directory and somewhere on `PYTHONPATH`, the project directory wins because it comes first.\n\nThis ordering has a sharp edge. Naming a local file `math.py` shadows the standard library's `math` module: `import math` finds the local file before reaching the stdlib path. Symptoms include cryptic errors like `AttributeError: module 'math' has no attribute 'sqrt'` caused by accidentally importing a local file. The fix is to rename the file. Standard library names to avoid for local modules include `math`, `random`, `time`, `os`, `sys`, `json`, `re`, `string`, `email`, `socket`, `types`.\n\n`sys.path` can be modified at runtime, though it's usually a sign the layout is wrong:\n\n\n```python\nimport sys\nsys.path.append(\"/some/other/directory\")\nimport pricing\n```\n\n\nThis works, but cleaner paths exist: organize the code into packages, install the package with `pip` (covered next), or set `PYTHONPATH` in the shell. Runtime `sys.path` manipulation suggests one of those better options was skipped.\n\nFor development inside a single project, the rule of thumb is simpler: put related files in the same directory and run the entry point from there. `python shop.py` (where `shop.py` and `pricing.py` are in the same folder) is the simplest setup, and it works without any configuration.\n\n---\n\n# Installing Your Module Locally: Editable Installs\n\nPutting all modules in one folder works fine for small scripts. For a larger project, especially one used from anywhere on the machine, install it instead. The Python tool for that is `pip`, and the install mode for development is called an **editable install**.\n\nThe full story belongs in a dedicated packaging lesson, but the gist:\n\nAdd a small file called `pyproject.toml` at the root of the project:\n\n\n```shell\nmy-shop/\n pyproject.toml\n pricing.py\n shop.py\n```\n\n\nA minimal `pyproject.toml`:\n\n\n```shell\n[build-system]\nrequires = [\"setuptools>=61\"]\nbuild-backend = \"setuptools.build_meta\"\n\n[project]\nname = \"my-shop\"\nversion = \"0.1.0\"\n\n[tool.setuptools]\npy-modules = [\"pricing\", \"shop\"]\n```\n\n\nThen, from the project root:\n\n\n```shell\n$ pip install -e .\n```\n\n\nThe `-e` flag means \"editable.\" Pip installs the project in a way that points back to the source files instead of making a copy. Every edit to `pricing.py` is immediately visible to anything that imports it; no reinstall after every change.\n\nAfter this, `import pricing` works from anywhere on the machine, not only from the same directory. A Python REPL opened anywhere on disk can run `import pricing` and load the code. Tests in a separate directory can import the modules without any path manipulation.\n\nFor a package (a directory of modules with an `__init__.py`, which the next two chapters cover), the setup is the same; change `py-modules = [...]` to `packages = [...]` and list the package directory instead.\n\nThis is the way to make local code reusable across projects: install it locally with `pip install -e .` rather than copying files around or modifying `PYTHONPATH`. The packaging side comes later; for now, knowing that \"install your module locally\" is a real, supported thing is enough.\n\nEditable installs are free during development. The overhead is one-time setup (writing `pyproject.toml`, running `pip install -e .`) and removing the install with `pip uninstall my-shop` when the project is abandoned. The payoff is that `import pricing` works from any directory and imports stop being fragile.\n\n---\n\n# Module Size and Cohesion\n\nA module should have one job that can be described in one sentence. Once a module's purpose can't be described without the word \"and\" twice, split it.\n\nThis isn't a hard rule; it's a heuristic that prevents the most common mistake: the giant `utils.py` that grows to 2,000 lines of unrelated functions because nobody decided where each helper belonged. A 2,000-line `utils.py` is the worst kind of module, because the name promises nothing and the file delivers chaos. Finding \"where's the date formatter?\" requires reading the whole file.\n\nSome practical guidelines:\n\n**Aim for 50-500 lines.** Below 50, the module barely earns its own file; consider merging it with a sibling. Above 500, the file gets hard to scan in one sitting; consider splitting it.\n\n**One coherent topic per module.** `pricing.py` is about pricing. `cart.py` is about carts. `customer.py` is about customers. The name of the module should tell a reader what's inside. Don't use `helpers.py` or `utils.py` as a default home for orphan functions; give each function a real home.\n\n**Group by what changes together.** Functions that always change together (when one needs an update, the other usually does too) belong in the same module. Functions that change for independent reasons belong in different modules.\n\n**Keep the public surface small.** Most modules should expose a handful of public names (functions, classes, constants) and prefix internal helpers with an underscore. A module with 40 public names is doing too much; split it.\n\n**Small modules are fine.** A module with two functions is acceptable when those two functions belong together and nothing else does. The cost of a small module is one extra file; the benefit is a name that tells the reader what's inside.\n\nA typical e-commerce project layout:\n\n\n```shell\nshop/\n pricing.py -- cart totals, tax, discounts\n cart.py -- cart structure, add and remove\n customer.py -- customer records, profile lookups\n orders.py -- order placement, status transitions\n shipping.py -- shipping cost, delivery estimates\n reviews.py -- product reviews, ratings\n inventory.py -- stock counts, availability\n shop.py -- entry point that ties it together\n```\n\n\nEach file has a clear job. None of them is more than a few hundred lines. The entry point (`shop.py`) doesn't define much itself; it stitches together work that lives in the other files. When the tax rate changes, only `pricing.py` changes. When the order status workflow changes, only `orders.py` changes. The blast radius of any single change stays small.\n\n---\n\n# Putting It Together: A Reusable Pricing Module\n\nA complete, well-organized small module that pulls together everything in this lesson:\n\n\n```python\n# pricing.py\n\"\"\"Pricing helpers for the AlgoMaster store.\n\nExposes:\n TAX_RATE -- standard sales tax rate\n cart_total(prices) -- subtotal plus tax for a list of prices\n apply_discount(price, percent) -- price after a percent discount\n apply_coupon(price, code) -- price after applying a known coupon code\n\nExample:\n >>> from pricing import cart_total\n >>> cart_total([29.99, 14.99])\n 48.5784\n\"\"\"\n\nfrom pathlib import Path\n\n# Public constants\nTAX_RATE = 0.08\nFREE_SHIPPING_THRESHOLD = 50.00\n\n# Internal: paths and lookup tables built once at import time\n_THIS_DIR = Path(__file__).parent\n_COUPONS = {\n \"WELCOME10\": 10,\n \"SUMMER20\": 20,\n \"BLACKFRIDAY50\": 50,\n}\n\ndef cart_total(prices):\n \"\"\"Return the total of a cart, including tax.\n\n Args:\n prices: An iterable of numeric prices.\n\n Returns:\n The sum of all prices multiplied by (1 + TAX_RATE).\n \"\"\"\n return sum(prices) * (1 + TAX_RATE)\n\ndef apply_discount(price, percent):\n \"\"\"Return a price after a percentage discount.\"\"\"\n return price * (1 - percent / 100)\n\ndef apply_coupon(price, code):\n \"\"\"Return a price after applying a known coupon code.\n\n If the coupon code is unknown, the original price is returned unchanged.\n \"\"\"\n percent = _COUPONS.get(code, 0)\n return apply_discount(price, percent)\n\ndef _format_price(value):\n \"\"\"Internal helper: format a number as a USD-style price.\"\"\"\n return f\"${value:.2f}\"\n\nif __name__ == \"__main__\":\n # Quick demo when run directly\n sample_cart = [29.99, 14.99, 9.99]\n sample_price = 99.99\n print(f\"Cart total: {_format_price(cart_total(sample_cart))}\")\n print(f\"With WELCOME10 coupon: {_format_price(apply_coupon(sample_price, 'WELCOME10'))}\")\n print(f\"With unknown coupon: {_format_price(apply_coupon(sample_price, 'NOPE'))}\")\n```\n\n\nRunning this directly:\n\n\n```shell\n$ python pricing.py\nCart total: $59.36\nWith WELCOME10 coupon: $89.99\nWith unknown coupon: $99.99\n```\n\n\nImporting it from another file:\n\n\n```python\n# shop.py\nfrom pricing import cart_total, apply_coupon\n\ncart = [29.99, 14.99, 9.99]\nprint(f\"Total: ${cart_total(cart):.2f}\")\nprint(f\"Sale: ${apply_coupon(99.99, 'SUMMER20'):.2f}\")\n```\n\n\nThe module has a docstring, three public functions, one public constant, two underscore-prefixed internal names, and a `__main__` block for ad-hoc use from the command line. It's small enough to read in one sitting, every name is on the module for a reason, and the file works both as a library and a runnable demo.","pageType":"python"}

Creating Modules

Get Premium