Modules, Packages & Environments · Lesson 95

Create Your Own Module

A Python module is normally a .py file that can define functions, classes and constants for reuse.

ConceptWorked examplePracticeKnowledge check
Textbook walkthrough

Create Your Own Module

A Python module is normally a .py file that can define functions, classes and constants for reuse. Importing a module executes its top-level code once for that process and creates a module object whose attributes expose the definitions. Separating reusable logic into modules reduces duplication and gives code a stable import interface.

Learning goal: explain why Create Your Own Module behaves this way, apply it to a small example, and verify the result independently. Begin by being able to justify this first step: Move related reusable definitions into a descriptive .py file.

Deeper walkthrough

Read Create Your Own Module as a mechanism, not a recipe

Treat this as a sequence of observable decisions rather than one opaque command. Stage 1: Move related reusable definitions into a descriptive .py file. Stage 2: Avoid executing heavy analysis as an import side effect. Stage 3: Import the module or selected names from a caller. Final checkpoint: Test the module interface independently of the calling script.

Mechanism

Follow the transformation

Move related reusable definitions into a descriptive .py file.

Avoid executing heavy analysis as an import side effect.

Import the module or selected names from a caller.

Evidence

Know what would convince you

  • Trace a tiny input by hand and compare the runtime result.
  • Inspect type, value/shape and any mutation/side effect explicitly.
Useful distinctionInput: Objects/values supplied to the operation.
Click a stage to inspect what happens, what changes, and what should be checked before moving on.
Stage 1

Move related reusable definitions into a…

Move related reusable definitions into a descriptive .py file. For Create Your Own Module, identify the exact state before this stage, the operation or rule applied here, and the observable state afterwards so the mechanism remains inspectable.

State focus: identify exactly what changed at this stage and what observable evidence confirms that change.
How it works

Trace the mechanism step by step

  1. Move related reusable definitions into a descriptive .py file.
  2. Avoid executing heavy analysis as an import side effect.
  3. Import the module or selected names from a caller.
  4. Use __name__ == "__main__" for code that should run only when the module is executed directly.
  5. Test the module interface independently of the calling script.
Worked demonstration

Module boundary

# metrics.py
# Step 1 — Define the reusable `conversion_rate` function; its indented body describes what happens for each call.
def conversion_rate(conversions, visits):
    # Step 2 — Return the computed value to the caller so the result can be reused or tested.
    return conversions / visits

# analysis.py
# from metrics import conversion_rate
# print(conversion_rate(20, 100))
Expected / illustrative result
Importing conversion_rate makes the reusable function available without copying its implementation into analysis.py.
Interpret the result.

For Create Your Own Module, trace the specific input through the mechanism above and independently verify one returned value, state change or side effect.

Distinctions & related ideas

Place the concept correctly

InputObjects/values supplied to the operation.
StateNames or mutable objects that may change during execution.
OutputReturned value, side effect, file, plot or exception to inspect.
Use deliberately

When it is appropriate

Use Create Your Own Module when it answers a defined question in Modules, Packages & Environments and its inputs/assumptions match the current data or program state.

Boundary conditions

When to stop or reconsider

Reconsider Create Your Own Module when the required information is unavailable, the operation would violate a validation/data boundary, or a simpler operation answers the question more transparently.

Common mistakes

Failure modes to recognise

  • Running the operation on the wrong object/type or in the wrong environment.
  • Inferring correctness from “no exception” without checking the produced value/state.
  • Hiding a boundary case instead of making its behaviour explicit.
Verification

How to check the result

  • Trace a tiny input by hand and compare the runtime result.
  • Inspect type, value/shape and any mutation/side effect explicitly.
  • Run an edge or invalid case and confirm the exception/behaviour is deliberate.
Hands-on practice

Demonstrate understanding

Try this:

Construct a tiny example of Create Your Own Module. First move related reusable definitions into a descriptive .py file. Then avoid executing heavy analysis as an import side effect. Predict the result before execution and explain one boundary or failure case.

Use one tiny file or module with an explicit path/encoding/environment. Validate it by loading or importing it again.
Knowledge check

Check reasoning, not memorisation

Which approach best demonstrates understanding of Create Your Own Module?

Quick reference

Remember the logic

Step 1Move related reusable definitions into a descriptive .py file.
Step 2Avoid executing heavy analysis as an import side effect.
Step 3Import the module or selected names from a caller.
Step 4Use __name__ == "__main__" for code that should run only when the module is executed directly.
Lesson summary

What to remember

  • A Python module is normally a .py file that can define functions, classes and constants for reuse. Importing a module executes its top-level code once for that process and creates a module object whose attributes expose the definitions. Separating reusable logic into modules reduces duplication and gives code a stable import interface.
  • Move related reusable definitions into a descriptive .py file.
  • Running the operation on the wrong object/type or in the wrong environment.
  • Trace a tiny input by hand and compare the runtime result.