Skip to content
7 MIN LESSON · COMPUTER SCIENCE

Class 11 Functions and Modules: Complete Concepts and Practice

Computer Science — Decomposition and function categories, Definition, calls and execution flow, Arguments, defaults and interfaces, Returning results versus displaying them, Scope and lifetime of local names, Mutable arguments and side effects, Imports and the math module, Randomness, statistics and dependable tests.

Big picture

A function packages a task behind a name and a clear interface. Instead of rewriting the same fee calculation for every student, a program can call one function with different inputs. A module groups related definitions so programs can reuse them without repeating their implementation.

This chapter covers built-in functions, user-defined functions and standard modules at introductory level. Treat the more detailed function material as a bridge to later programming: the central habits are choosing inputs, returning useful results and checking which names are visible where.

Learning goals

  • Distinguish built-in, user-defined and module functions.

  • Define clear parameters and use positional or keyword arguments.

  • Separate returned values from printed output.

  • Trace local scope and mutable-argument effects.

  • Use standard modules with suitable tests.

Core ideas

1. Decomposition and function categories

Decomposition divides a larger problem into smaller responsibilities. A result-processing program might separate data entry, validation, calculation and display. Each function should have a purpose that can be explained in a short sentence. This makes isolated testing easier and reduces duplicated logic.

A built-in function is available without importing a module, such as len, abs and round. A user-defined function is written by the programmer using def. A module function is obtained from an imported module, such as math.sqrt. These categories describe how functionality is supplied, not whether a function is important or fast. Before calling any function, know its accepted arguments, return value and possible errors. A descriptive name is useful only when the behaviour actually matches that name.

2. Definition, calls and execution flow

A function definition starts with def, a name, parentheses and a colon, followed by an indented body. Defining a function binds its name; the body runs when the function is called. Parentheses in a call distinguish invoking the function from merely referring to its object.

A parameter represents a value supplied by the caller. For a rectangle-area function, length and breadth are parameters; concrete measurements provided at a call are arguments. The caller pauses while the function executes and resumes when it returns. Write a simple call immediately after a definition during testing so that an unused, untested function is not mistaken for a working solution. A function can be correct in isolation but called with arguments in the wrong order.

3. Arguments, defaults and interfaces

Positional arguments bind by their order; keyword arguments bind by parameter name. Defaults provide a value when an optional argument is omitted. Define required parameters before ordinary defaulted parameters, and place positional arguments before keyword arguments in a normal call.

For a delivery calculation, a default charge can express a usual policy while still allowing a caller to supply another value. Do not use a mutable list as an unexplained default container because that object can persist across calls. A clear interface states units and assumptions: distance in kilometres is not interchangeable with metres. Functions should not quietly reinterpret an argument merely because a different interpretation makes the sample output convenient. Document which inputs are permitted and test the boundary of that permitted domain.

4. Returning results versus displaying them

return sends a value to the caller and ends that invocation. A function can compute a result without printing it, allowing another function to use it. print displays information but is not a substitute for returning a result. A function that reaches its end without an explicit returned value returns None.

def bill(quantity, price, discount=0):
    subtotal = quantity * price
    return subtotal - discount

amount = bill(6, 25, discount=10)
print(amount)
print(bill(price=25, quantity=2))

Output:

140
50

The first subtotal is 6 × 25 = 150 and the discount gives ₹140. In the second call, keyword order differs from parameter order, but names bind correctly and the default discount is zero. Returning the bill makes it usable for later totals.

5. Scope and lifetime of local names

Scope determines where a name can be resolved. A parameter and a name assigned inside a function are normally local to that invocation. A global name belongs to the module. Assigning a local name with the same spelling does not automatically rebind the global one.

rate = 5
def adjusted(value):
    rate = 2
    return value * rate
print(adjusted(9), rate)

Output:

18 5

The local rate affects the multiplication, while the module rate remains five. The global statement can explicitly change binding behaviour, but returning a value is often clearer than modifying a global as a hidden side effect. Different calls have distinct local bindings, so do not assume a local counter automatically remembers its previous value between invocations.

6. Mutable arguments and side effects

Python passes references to objects by assignment to parameter names. Rebinding a parameter does not rebind the caller's variable, but mutating a shared list can change what the caller sees. This distinction is more precise than saying everything is copied or everything is changed.

def add_bonus(values):
    values.append(4)
    values = [99]
    return values
marks = [7, 8]
result = add_bonus(marks)
print(marks, result)

Output:

[7, 8, 4] [99]

Appending changes the shared object. The later assignment creates a new local binding, so the caller still sees the original list with the appended item. Such a visible mutation is a side effect. State side effects explicitly so a caller can use the function safely.

7. Imports and the math module

A module is a reusable unit of Python definitions, commonly stored in a file. import math makes the module name available, and math.sqrt qualifies the function with its module. from math import sqrt imports that selected name directly. An alias such as import math as m changes the local name used to refer to the module.

import math
print(math.sqrt(81))
print(math.ceil(4.2), math.floor(4.2))
print(math.fabs(-7))

Output:

9.0
5 4
7.0

ceil returns the smallest integer not below the value, while floor returns the greatest integer not above it. Their difference matters especially for negatives. Avoid naming a script math.py when trying to import the standard module, because a local file can interfere with module resolution. Import only what the program needs and use clear qualification.

8. Randomness, statistics and dependable tests

The random module supplies pseudorandom operations useful for simulations. randint(a, b) includes both endpoints, while randrange follows range-style stop exclusion. A random result should not be presented as a guaranteed fixed output. A fixed seed can help reproduce a test sequence within a suitable environment, but deterministic assertions should check the intended property rather than guess a draw.

The statistics module provides mean, median and mode-related functionality. Choose the statistic that answers the question; an average alone does not describe spread. For tests, use small known inputs, omitted defaults, keyword calls and invalid-domain cases. Check both the returned value and any changed argument. A function that prints the expected number but returns None has failed a contract that requires a usable numeric return value.

A reliable approach to questions

  1. Read the command word before choosing an answer. A definition needs the distinguishing feature; a comparison needs matching criteria on both sides; an application needs a reason linked to the situation.

  2. Extract the supplied evidence and assumptions. Keep a small working table rather than relying on memory. If information is absent, state the limit instead of inventing a value or claiming certainty.

  3. Work through the relevant rule one step at a time. For a program, record the changing state; for a scenario, connect the requirement to the feature that meets it. Explain why the closest alternative fails.

  4. Check the result against the original question, including boundary cases, units and wording. Present a concise final answer followed by enough reasoning for another student to reproduce your conclusion.

Connections that matter

  • Collections explain mutation of arguments and shared objects.

  • Control flow determines which return statement executes.

  • Data projects use reusable functions to separate cleaning from analysis.

Common mistakes

  • Expecting a definition to execute its body: it runs on a call.

  • Treating print as return: display and returned data are different.

  • Assuming local assignment changes a global: scope controls binding.

  • Expecting a fixed random output: test the permitted range or property.

Revision checklist

  • I can distinguish built-in, user-defined and module functions.

  • I can define clear parameters and use positional or keyword arguments.

  • I can separate returned values from printed output.

  • I can trace local scope and mutable-argument effects.

  • I can use standard modules with suitable tests.

Practise this topic →

Discussion

Sign in to join the discussion.

Sign in

No comments yet. Be the first to share your thoughts.