Python Fundamentals

Python Functions and Modules

Organize Python code with functions, parameters, modules, imports, and an explicit script entry point.

Beginner14 min read
Python Fundamentals lessonAutomation foundationsLearn

Organize Python code with functions, parameters, modules, imports, and an explicit script entry point.

What you will be able to do

  • Explain the five core programming decisions involved in python functions and modules.
  • Choose a small code or command method that matches a stated input and output need.
  • Interpret execution output and errors before changing broader system state.
  • Apply an inspect, implement, test, verify, and recover workflow to a realistic automation task.

01

Build the Execution Model

Organize Python code with functions, parameters, modules, imports, and an explicit script entry point.

Reliable automation separates input, representation, decision, action, output, and failure behavior. Before writing a longer script, state the exact starting data, the intended transformation, the observable result, and which state the program is permitted to change.

Use a disposable project and small deterministic samples. Run read-only inspection first, keep the interpreter or shell and working directory visible, and preserve the exact input with its output. A reproducible example is more useful than a large script whose state is unknown.

02

Function definition

A def statement creates a function object with a name and executable body. It is one distinct part of python functions and modules, so keep its input and output visible instead of hiding them inside a larger unexplained script.

Keep one responsibility in each function and add a short contract. Start with this small method: Define and then call a small function. Record the code, interpreter or shell version, working directory, sample input, and visible result together.

The safety boundary is clear: Definition does not execute the function body. The expected evidence is The function definition result matches the documented input and expected state. If the result differs, keep the failure and reduce the example before changing unrelated code or system state.

03

Function arguments

Positional and keyword arguments supply values under the function signature. It is one distinct part of python functions and modules, so keep its input and output visible instead of hiding them inside a larger unexplained script.

Use keyword arguments when they make call intent clearer. Start with this small method: Call with explicit keyword arguments. Record the code, interpreter or shell version, working directory, sample input, and visible result together.

The safety boundary is clear: Mutable default values can persist between calls. The expected evidence is The function arguments result matches the documented input and expected state. If the result differs, keep the failure and reduce the example before changing unrelated code or system state.

04

Returned results

Return ends the current function call and supplies a value to its caller. It is one distinct part of python functions and modules, so keep its input and output visible instead of hiding them inside a larger unexplained script.

Return data instead of mixing calculation with display. Start with this small method: Assign and assert the returned value. Record the code, interpreter or shell version, working directory, sample input, and visible result together.

The safety boundary is clear: A function without return produces None. The expected evidence is The returned results result matches the documented input and expected state. If the result differs, keep the failure and reduce the example before changing unrelated code or system state.

05

Modules and imports

A module is a Python file whose definitions can be imported under a module namespace. It is one distinct part of python functions and modules, so keep its input and output visible instead of hiding them inside a larger unexplained script.

Import the module and access named members explicitly. Start with this small method: Import a local module in a disposable project. Record the code, interpreter or shell version, working directory, sample input, and visible result together.

The safety boundary is clear: Import-time code can create unexpected side effects. The expected evidence is The modules and imports result matches the documented input and expected state. If the result differs, keep the failure and reduce the example before changing unrelated code or system state.

06

Main guard

The `__name__` guard separates script entry behavior from importable definitions. It is one distinct part of python functions and modules, so keep its input and output visible instead of hiding them inside a larger unexplained script.

Place command-line execution under the guard and keep reusable functions outside it. Start with this small method: Compare direct execution with module import. Record the code, interpreter or shell version, working directory, sample input, and visible result together.

The safety boundary is clear: Top-level actions run when a module is imported. The expected evidence is The main guard result matches the documented input and expected state. If the result differs, keep the failure and reduce the example before changing unrelated code or system state.

07

Implement One Small Behavior

Translate the requirement into one input-output example before implementation. Name the target and side effects explicitly, validate input at the program boundary, and keep secrets and environment-specific configuration outside source code and ordinary logs.

Add the smallest code that makes the example work. Inspect intermediate values as structured data, not only formatted display text. When an operation can modify files, accounts, services, remote systems, or API resources, build a preview or disposable test path first.

Handle the expected failure that belongs to the operation. Preserve its type, message, target, and timing, then return a meaningful result or nonzero exit. Do not catch errors the program cannot explain merely to make the run appear successful.

08

Test and Handoff the Automation

Test a normal input, one boundary input, and one safe failure. Compare actual output with the written expectation and verify any changed state through an independent read-only query. A zero exit code or successful request is only part of the evidence.

Make the run reproducible. Record runtime version, dependencies, parameters, configuration source, sample data, output shape, and cleanup or reversal procedure. Remove temporary credentials, test files, sessions, and permissions after verification.

A useful handoff explains what the program accepts, what it returns or changes, how it reports failure, and where execution must stop for review. Escalate when authorization, data ownership, target scope, vendor contract, or safe recovery remains uncertain.

09

Recap Before Practice and Prove

Start with function definition. Keep one responsibility in each function and add a short contract. Verify that the function definition result matches the documented input and expected state.

Keep function arguments explicit. Use keyword arguments when they make call intent clearer. Respect this boundary: mutable default values can persist between calls..

Use returned results as a separate decision. Return data instead of mixing calculation with display. Preserve the exact input and output.

Before expanding the script, review modules and imports. Import the module and access named members explicitly. Stop when import-time code can create unexpected side effects..

Finish with main guard. Place command-line execution under the guard and keep reusable functions outside it. Record the final result, failure behavior, cleanup, and reproducible next step.

NEXT STEP

Turn reading into recall

Practice the concepts without a timer, with coaching and retry available after every answer.

Open guided practice