How much does zuzu.codes cost?

The starter track is free — read all lessons and practice for free. Full access to every track (current and future) is $14.99/month. Cancel anytime.

How long does each track take?

Each track is designed as a 30-day challenge — one lesson per day, about 15 minutes each. Go at your own pace, but the structure is built around daily consistency.

What's the lesson format?

Each lesson is a student-teacher dialogue with code examples, followed by a hands-on code challenge in an in-browser editor. You read, you understand, then you write real code.

Do I need prior coding experience?

Our beginner track starts from absolute zero — no prior experience needed. Advanced tracks build on earlier ones, and the platform tells you exactly where to start.

How is zuzu.codes different from freeCodeCamp or Codecademy?

zuzu.codes uses a structured 30-day track format with dialogue-based teaching, an in-browser code editor, and gamification (XP, streaks, progress tracking). The format builds genuine understanding through daily practice.

Privacy Terms

Day 19 · ~12 min●

Every Python file you've written so far has been a single script. When the file gets to 500+ lines you split it. The split unit is a module: one .py file is one module.

python

# models.py
def double(n):
    return n * 2

# main.py
from models import double
print(double(5))    # 10

And import models vs from models import double — what's the difference?

Both work. import models brings the module in as a single name; you call models.double(5). from models import double brings the function in directly; you call double(5). The latter is shorter at the call site but pollutes the namespace more (every from x import * is a footgun).

And a package — that's a directory of modules?

Right. A package is a directory containing an __init__.py file (which can be empty) plus one or more .py modules. The __init__.py runs when you import the package — typically just to expose its main symbols:

mini/
    __init__.py
    models.py
    helpers.py

python

# mini/__init__.py
from .models import Item    # exposes mini.Item at the top level

# user code
from mini import Item

So packages are just folders with that special file?

That's the gist. In Python 3.3+ you can also have namespace packages without an __init__.py, but for a small library the explicit __init__.py is clearer.

Today's exercise — we don't actually have a real filesystem in the browser. How do we test this?

We use sys.modules — Python's in-memory cache of imported modules. We register a fake module by hand, then import it. Same mechanic as a real from x import y — just bypassing the file lookup step.

Modules — one file, one module

A Python module is just a .py file. The module's name is the filename without .py.

python

# models.py
def double(n):
    return n * 2

class Item:
    def __init__(self, name, value):
        self.name = name
        self.value = value

Three ways to import

python

# 1. Whole module
import models
result = models.double(5)

# 2. Specific names
from models import double, Item
result = double(5)

# 3. Aliased
import models as m
result = m.double(5)

`from x import *` — almost never

python

from models import *    # imports every public name — bad in real code

Readability suffers — you can't tell where double came from. Use it only in interactive sessions, never in production modules.

Packages — directories with `init.py`

mini/                ← package directory
    __init__.py      ← marks it as a package; runs on import
    models.py        ← submodule
    helpers.py       ← submodule

`init.py` runs on import

When you import mini (or from mini import x), Python runs mini/__init__.py first. Common content:

python

# mini/__init__.py
from .models import Item, double    # "." = same package
from .helpers import format_item

__all__ = ["Item", "double", "format_item"]    # what `from mini import *` exposes

This lets users from mini import Item instead of from mini.models import Item — flatter import surface.

Relative vs absolute imports inside a package

python

# mini/models.py
from .helpers import format_item    # relative — same package

# vs

from mini.helpers import format_item    # absolute — by full path

Within a package, relative (from .x) is conventional — it makes refactoring (renaming the package) easier.

Subpackages

A package can contain another package:

mini/
    __init__.py
    models.py
    tests/
        __init__.py
        test_models.py

from mini.tests.test_models import TestItem works the same way — chain the dots.

In-memory module trick (for this exercise)

In a real project the module lives on disk. In Pyodide we don't have a writable filesystem here. The standard trick:

python

import sys, types

m = types.ModuleType("models")
m.double = lambda n: n * 2
sys.modules["models"] = m

from models import double
print(double(5))    # 10

We build a ModuleType object, attach functions/classes to it, and register it in sys.modules. After that, import models and from models import x work normally — because that's exactly what they look up.

Real-world: skip the types.ModuleType step, just write models.py. The mental model is the same.

Sign up to practice

Create a free account to get started. Paid plans unlock all tracks.

or

Day 19 · ~12 min●

Every Python file you've written so far has been a single script. When the file gets to 500+ lines you split it. The split unit is a module: one .py file is one module.

python

# models.py
def double(n):
    return n * 2

# main.py
from models import double
print(double(5))    # 10

And import models vs from models import double — what's the difference?

Both work. import models brings the module in as a single name; you call models.double(5). from models import double brings the function in directly; you call double(5). The latter is shorter at the call site but pollutes the namespace more (every from x import * is a footgun).

And a package — that's a directory of modules?

Right. A package is a directory containing an __init__.py file (which can be empty) plus one or more .py modules. The __init__.py runs when you import the package — typically just to expose its main symbols:

mini/
    __init__.py
    models.py
    helpers.py

python

# mini/__init__.py
from .models import Item    # exposes mini.Item at the top level

# user code
from mini import Item

So packages are just folders with that special file?

That's the gist. In Python 3.3+ you can also have namespace packages without an __init__.py, but for a small library the explicit __init__.py is clearer.

Today's exercise — we don't actually have a real filesystem in the browser. How do we test this?

We use sys.modules — Python's in-memory cache of imported modules. We register a fake module by hand, then import it. Same mechanic as a real from x import y — just bypassing the file lookup step.

Modules — one file, one module

A Python module is just a .py file. The module's name is the filename without .py.

python

# models.py
def double(n):
    return n * 2

class Item:
    def __init__(self, name, value):
        self.name = name
        self.value = value

Three ways to import

python

# 1. Whole module
import models
result = models.double(5)

# 2. Specific names
from models import double, Item
result = double(5)

# 3. Aliased
import models as m
result = m.double(5)

`from x import *` — almost never

python

from models import *    # imports every public name — bad in real code

Readability suffers — you can't tell where double came from. Use it only in interactive sessions, never in production modules.

Packages — directories with `init.py`

mini/                ← package directory
    __init__.py      ← marks it as a package; runs on import
    models.py        ← submodule
    helpers.py       ← submodule

`init.py` runs on import

When you import mini (or from mini import x), Python runs mini/__init__.py first. Common content:

python

# mini/__init__.py
from .models import Item, double    # "." = same package
from .helpers import format_item

__all__ = ["Item", "double", "format_item"]    # what `from mini import *` exposes

This lets users from mini import Item instead of from mini.models import Item — flatter import surface.

Relative vs absolute imports inside a package

python

# mini/models.py
from .helpers import format_item    # relative — same package

# vs

from mini.helpers import format_item    # absolute — by full path

Within a package, relative (from .x) is conventional — it makes refactoring (renaming the package) easier.

Subpackages

A package can contain another package:

mini/
    __init__.py
    models.py
    tests/
        __init__.py
        test_models.py

from mini.tests.test_models import TestItem works the same way — chain the dots.

In-memory module trick (for this exercise)

In a real project the module lives on disk. In Pyodide we don't have a writable filesystem here. The standard trick:

python

import sys, types

m = types.ModuleType("models")
m.double = lambda n: n * 2
sys.modules["models"] = m

from models import double
print(double(5))    # 10

We build a ModuleType object, attach functions/classes to it, and register it in sys.modules. After that, import models and from models import x work normally — because that's exactly what they look up.

Real-world: skip the types.ModuleType step, just write models.py. The mental model is the same.

Sign up to practice

Create a free account to get started. Paid plans unlock all tracks.

or

Modules — one file, one module

Three ways to import

from x import * — almost never

Packages — directories with __init__.py

__init__.py runs on import

Relative vs absolute imports inside a package

Subpackages

In-memory module trick (for this exercise)

Sign up to practice

Modules — one file, one module

Three ways to import

from x import * — almost never

Packages — directories with __init__.py

__init__.py runs on import

Relative vs absolute imports inside a package

Subpackages

In-memory module trick (for this exercise)

Sign up to practice

`from x import *` — almost never

Packages — directories with `init.py`

`init.py` runs on import

`from x import *` — almost never

Packages — directories with `init.py`

`init.py` runs on import