Forem: Vivis Dev

Understanding Python dataclasses and how fields determine equality and hashing.

Vivis Dev — Wed, 24 Sep 2025 12:01:00 +0000

In monasteries bowls are often used for meditation rituals. Some are empty, others hold offerings: coins, water, and small tokens of care. In Python, dataclasses behave much like these bowls.

Each dataclass instance is a bowl; the data it carries are the offerings inside. How Python evaluates equality and hashing depends on both the contents and the form of the bowl itself.

Part 1: What is a Dataclass?

Dataclasses, introduced in Python 3.7, are a convenience feature. They save you from writing boilerplate code when you need simple classes that hold data.

For example, without dataclasses you might write:

And with a dataclass it becomes:

Python automatically creates the __init__, __eq__, and __repr__ functions for you when you use the dataclass decorator.

Part 2: The Empty Bowl

Consider a bowl with no marked offerings:

Although values are assigned on the class, there are no annotated fields. When Python evaluates this bowl:

Only attributes declared with annotations are considered the recognized contents of the bowl, contributing to equality and hash calculations. Adding type annotations transforms the bowl:

Now the offerings are acknowledged, and hashing reflects their presence. Two bowls with identical annotated fields are equal, and their hashes correspond to their contents.

Part 2: Comparing Different Bowls

Next, imagine two bowls, each holding the same offerings:

The bowls may contain identical coins and water, yet they differ in form. Python compares both the contents and the type of the object:

Equality requires both the offerings and the vessel to match. Hashing, on the other hand, considers only the annotated fields.

Part 3: Fields vs Class Variables

The distinction between annotated fields and class variables is crucial. Only annotated fields are considered offerings within the bowl. Class variables exist on the outside: they do not contribute to equality or hashing.

Part 4: Mutable vs Frozen Dataclasses

You may have noticed that we are delcaring classes with frozen=True.Dataclasses can be created mutable or frozen :

Mutable dataclasses allow their contents to change after creation. This is the default.
Frozen dataclasses make the contents immutable, like sealing the offerings inside a bowl.

Frozenness also affects hashability. Only frozen dataclasses are hashable by default, because mutable bowls could change after being placed in a set or used as dict keys.

In Koan 8 we learnt that the hashability of a class is determined by the implementation of the __hash__function. When a dataclass is declared frozen, Python automatically creates a __hash__function for you.

Part 5: Default Values and Factories

Default values make bowls easier to create without specifying every offering:

For mutable fields like lists or dictionaries, a default factory is necessary. Using a default argument with a mutable object can lead to shared state between instances:

This is because default arguments are evaluated once at definition time, not execution time, as we learnt in Koan 3.

Instead, a default_factory creates a new object for each instance :

Now each bowl has its own independent list of offerings. Python calls the factory function at the time the instance is created, ensuring the contents of each bowl remain separate.

This distinction prevents subtle bugs and preserves the integrity of each bowl’s contents.

Offering the Bowl

A bowl without marked offerings is indistinguishable from another empty bowl of the same type. Two bowls may contain identical offerings, yet remain separate if their forms differ. Hashing depends only on the contents, while equality considers both the contents and the form.

Through careful attention to fields, mutability, defaults, and the auto-generated methods, dataclasses provide a simple, predictable structure for Python data objects.

Python Koans | Vivis Dev | Substack

Python lessons wrapped in koans. Small puzzles, deep truths. Not your usual tutorial thread. Click to read Python Koans, by Vivis Dev, a Substack publication with hundreds of subscribers.

pythonkoans.substack.com

Exploring the dangerous power of unquoted Python strings, and how they caused CVE-2024-9287

Vivis Dev — Sat, 20 Sep 2025 13:26:00 +0000

The Peril of Unquoted Arguments

We often have the need to run commands in _*shells1 *_using Python. Subprocess is a cross-platform2 python module which helps you do this.

Shells commands are separated by command delimiters (such as ‘;’ ‘&&’ ‘||’ and ‘\n’ in POSIX3). Argument delimiters on the other hand define how a single command’s arguments are split. On POSIX-compliant systems the IFS4environment variable defines the characters used to split arguments. By default, IFS is set to split on spaces, newlines and tabs.

When a path or argument to a command contains a space, the shell does not see a single continuous entity. It sees two distinct things. A single path has become two arguments.

Let us begin with a simple example.

Part 1: The Space as a Separator

Consider the creation of a directory with a space in its name.

When we use the os module it understands the path as a single string because it does not involve the shell's interpretation. The directory is created as intended with a space in its name.

Now let us use the subprocess module with the shell=True flag. This flag instructs Python to pass our command to the shell for execution as a single string.

When this code runs, the shell sees the command as mkdir my new path. The shell interprets this as a command to create a directory named my a second directory named new and a third named path. The single path becomes three paths.

Part 2: The Command Injection

The danger is not only in misinterpretation but also in malicious injection.

Consider if the path came from an external source such as a user defined argument for example.

The shell sees mkdir my; rm -rf /. The semicolon is a command separator in the shell. The shell will first execute mkdir my and then it will execute rm -rf / which deletes the root directory.

The unquoted path has allowed the user to inject a new command. This is a profound and dangerous failure of boundary. A simple space or semicolon can shatter the integrity of the system.

Part 3: The Principle of Quoting

To prevent this we must use quoting. Quoting places a protective barrier around the string telling the shell to treat it as a single unit regardless of its contents.

The shell now sees mkdir "my; rm -rf /". The entire string is treated as a single argument for mkdir. No new directories are created. No commands are executed. The semicolon is rendered harmless a mere character within the string.

Part 4: The Path of Wisdom

The wise path is the one that avoids the shell entirely when not needed. Most linters (like ruff) will detect this for you.

Here we pass a list of arguments to subprocess.run. Python does not pass a single string to the shell. Instead it executes mkdir directly as a separate process and passes user_input as its first argument. The shell is never involved and the risk is eliminated.

This is the preferred way. It is clean and safe.

Part 5: A Real-World Command Injection (CVE-2024-9287)

Command Injection is not just a theoretical problem. Last year, a high severity vulnerability was found to affect all Python versions <= 3.13:

A vulnerability has been found in the CPython venv\ module and CLI where path names provided when creating a virtual environment were not quoted properly, allowing the creator to inject commands into virtual environment "activation" scripts (ie "source venv/bin/activate"). This means that attacker-controlled virtual environments are able to run commands when the virtual environment is activated. Virtual environments which are not created by an attacker or which aren't activated before being used (ie "./venv/bin/python") are not affected.

Previously, when a virtual environment was created, the activation scripts (activate, activate.bat, etc.) would use the environment name provided by the user to construct the venv path without enclosing it in quotation marks.

For example, a name like my test venv would be written into the script as /home/user/my test venv. An attacker could craft a virtual environment name like my-venv-with-space-and-command; malicious_command which would be interpreted by the shell as a path followed by an additional command to execute.

The fix5 (see summarized code below) was to ensure that all paths written into the venv activation scripts are properly quoted using the shlex module. The fix uses shlex.quote to ensure that any special characters or spaces in the path are escaped or enclosed in single quotes. This prevents the shell from misinterpreting the path as separate arguments or commands.

Forging the Blade

The Master Blacksmith’s lesson was simple. Just as a piece of metal may appear to be a single piece of steel, but splits into shards when struck by a hammer; unquoted command strings are split into different arguments or commands by the shell.

When constructing commands in Python:

Avoid shell=True and use subprocess.run([…]) instead
If you must use subprocess with shell=True, quote the command string
When constructing shell commands outside of subprocess, use shlex to avoid command injection from untrusted input.

The blacksmith does not strike a piece of steel without thought. So too should the developer not pass a path to the shell without care.

Thanks for reading Python Koans! If you enjoyed this post, share it with your friends :)

Python Koans | Vivis Dev | Substack

Python lessons wrapped in koans. Small puzzles, deep truths. Not your usual tutorial thread. Click to read Python Koans, by Vivis Dev, a Substack publication with hundreds of subscribers.

pythonkoans.substack.com

A shell _is a program that provides an interface between the user and the operating system (OS). It’s called a _“shell” because it surrounds the kernel (the “core”) and lets you interact with it. The shell takes commands (from your keyboard, a script, or another program), interprets them, and asks the OS to run the corresponding programs or built-in functions.

The subprocess module is available on all platforms except mobile (i.e. Android, iOS) and webassembly (i.e. WASI).

POSIX is an IEEE standard (IEEE 1003) defining a common API and shell behavior for Unix-like systems. It ensures that programs and scripts written on one POSIX-compliant system will work on another.

IFS can be made to split on other characters by changing it’s value before running a command. For example: IFS=, read a b c <<< "one,two,three"; echo "$a | $b | $c" will split the comma-delimited string into the three variables a, b and c.

Because the issue affected all versions of Python, a patch was created for all 3.x versions. The commit diff for Python 3.12 can be found here.

Understanding how Python's list comprehensions work under the hood

Vivis Dev — Sat, 20 Sep 2025 13:23:00 +0000

List Comprehensions

List comprehensions are one of the most popular features in Python, and it allows us to write idiomatic (or Pythonic) code.

But, as the student discovered, although the end result may be the same in the above example, the process it took to arrive at the solution is very different.

In fact, in Python 3.12, the process used to implement list comprehension changed significantly.

Let us begin at the river.

Part 1: The Inner World of the For Loop

In Koan 4 we learnt that Python has 4 scopes (Local, Enclosing, Global and Builtin). However, there is also another “hidden” scope. Consider this loop:

The loop above reassigns the value of x in the enclosing scope. After the loop runs, x is no longer 10. Its value is now 2. The loop's variable x "leaked" into the surrounding code.

Now consider the same code implemented as a list comprehension:

This code prints 10. The x in the comprehension is a new x. It does not touch the outer x. The list comprehension creates its own hidden scope.

Part 2: Peering into the water

But how does Python ensure that list comprehension has a distinct scope? To observe what is happening, we must first gather some tools to help us peek inside the code.

When you run a Python script, the CPython interpreter performs two main steps:

Compilation: The source code (the .py file you wrote) is compiled into a stream of bytecode instructions. This bytecode is cached into a .pyc file (pyc stands for "Python Compiled").
Execution: The CPython virtual machine (a program written in C) reads and executes the bytecode instructions one by one. If the source file has changed, the bytecode is re-created, and if not, the cached .pyc file is run directly

Inspecting the bytecode can inform us about how the program is run by the interpreter. However, the bytecode is stored in an efficient binary format that is not human readable.

To help us, we can use two functions:

compile() to compile a python source code string into a code object (also known as bytecode), with the following arguments:

* _**filename**_ : the filename from which the source code was read. If we are using the REPL, then it can be any string.

* _**mode**_ : use “exec” for multi-line statements, “eval” for single line statements, and “single” for single line interactive statements.

dis.dis to disassemble the bytecode and print it in a readable format

The output of dis.dis typically consists of several columns:

Line Number: This is the line number from the original Python source code. Note that a single line of Python code can compile into many bytecode instructions.
Offset: This is the byte offset of the instruction within the bytecode stream. It's used by jump instructions to navigate the code.
Instruction: This is the name of the bytecode instruction (e.g., LOAD_CONST, CALL_FUNCTION, RETURN_VALUE).
Argument: This is a value or a reference used by the instruction. It might be an index into a table of constants, variables, or names.
Argument Mnemonic: This provides a human-readable name for the argument, making it easier to understand what the instruction is doing (e.g., (range), (3), (None)).

We now have all the tools we need to peek inside the list comprehension, and to investigate why Python < 3.12 and Python >= 3.12, behave so differently.

Until next time, may your stillness reveal the unseen flow.

Continue to Part 2

Thanks for reading Python Koans! If you enjoyed this post, feel free to share it.

Python Koans | Vivis Dev | Substack

Python lessons wrapped in koans. Small puzzles, deep truths. Not your usual tutorial thread. Click to read Python Koans, by Vivis Dev, a Substack publication with hundreds of subscribers.

pythonkoans.substack.com

Exploring chained operations and order of evaluation in python expressions

Vivis Dev — Sat, 20 Sep 2025 13:21:00 +0000

The Hidden Teaching: The Flow of Assignment

Just as a master potter knows that some steps must precede others regardless of the order they're written, a seasoned Python developer understands that a seemingly simple assignment is not a singular event. It's a flow. The value does not flow from left to right; it flows from right to left.

Part 1: Assignment Chains

Consider a chain of assignments:

This may appear to assign x + 2to x, y, and z simultaneously. But Python does not work that way. It evaluates this expression from right to left.

The expression x + 2 is evaluated. The value 12 is assigned to the variable z.
This assignment itself returns the value that was assigned, which is 12.
This returned value 12 is then assigned to y.
This new assignment also returns the value 12, which is then assigned to x.

The operation is sequential. The rightmost value is the source and it moves leftward like water flowing down a stream. This is true for all assignment operators.

Part 2: Identity and Comparisons

Consider the following assignment chain:

list2 = list3 = list1 = [1,2,3]

On the surface, this appears simple. But because assignment chains are right-to-left, they create a single list object [1,2,3] and assign a reference to that same object to list1, then to list3, and finally to list2.

This is not a copy. It's a shared reference.

Modifying one of these variables will affect all others. We can confirm this by checking the identity of the objects using the id()function.

Part 3: Comparison Chains

The same principle applies to chained comparison operators such as <, > and ==.

1 < x < 10

However, unlike the assignment operator, a comparison chain is not evaluated from right to left. The interpreter performs a series of distinct comparisons and joins them with an implicit and operator.

The expression 1 < x < 10 is not shorthand for a single operation. It is shorthand for two separate operations:

(1 < x) and (x < 10)

This is an important distinction. The value of x is only evaluated once. The interpreter is smart enough to perform the minimal number of checks. If 1 < x is False, the expression x < 10 is not evaluated at all because the entire and expression will be False. This is known as short-circuiting and **** you can use this to your advantage when writing logical expressions:

(high_probability_of_being_false) and (low_probability_of_being_false)

If you write the expression with the higher likelihood of being False first, then you avoid the second expression from being executed. This is something you might have to consider when writing performance sensitive code.

Part 4: Chained Comparisons with Side Effects

What about chained comparisons containing functions with side effects? While Python evaluates a < b < c as (a < b) and (b < c), what happens if b is the result of a function call? Consider the following example:

The output will be Getting B's value... followed by The truth holds. The function get_val_b is called once and its returned value 5 is used for both 1 < 5 and 5 < 10.

The comparison is evaluated as a logical and, but the function call that produces the shared value for both comparisons is only executed once.

Firing the pot

The master potter’s lesson was simple. The order in which instructions are given are not the order in which they must be executed. In Python, chained instructions are executed according to the following rules:

Assignment chains are a sequential flow of value from right to left.
Comparison chains are a logical union of individual comparisons.

When you chain operators you are not simply performing a single operation. You are creating a silent understanding of how values will flow and how logic will be judged.

If you enjoyed reading this post, consider sharing it with your friends!

Python Koans | Vivis Dev | Substack

Python lessons wrapped in koans. Small puzzles, deep truths. Not your usual tutorial thread. Click to read Python Koans, by Vivis Dev, a Substack publication with hundreds of subscribers.

pythonkoans.substack.com

Understanding Python’s rules for hashing

Vivis Dev — Sat, 20 Sep 2025 13:08:00 +0000

When we speak of hashing in Python, we are entering a realm where identity, equality, and performance converge. In Koan 1, we learnt the difference between Identity and Equality. Hashing in Python uses equality rather than identity. It promises that two objects that are equal will share the same mark.

But the promise is not perfect.

The koan shows us two NaNs ("Not a Number"). They cannot be equal to each other, by mathematical rule. Yet their hashes are equal. How can two things be marked the same, yet not be the same?

Let us examine the seals carefully.

Part 1: What is a Hash?

A hash is a value produced by a function designed to uniquely represent an object. In Python, the built-in hash() function returns an integer, and it is used by dictionaries and sets to test membership. When you do:

Python does not search through all the keys each time. Instead, it computes a hash of "key", uses it to jump to the right location in memory, and then checks equality to confirm.

So the rule is:

Ifa == b, thenhash(a) == hash(b).
But the reverse is not guaranteed: ifhash(a) == hash(b),aandbmay not be equal.

The first rule is what allows dictionaries and sets to function correctly.

Part 2: The Strange Case of NaN

Mathematically, NaN is defined so that:

float('nan') == float('nan')  # False

float accepts the strings “nan” and “inf” with an optional prefix “+” or “-” for Not a Number (NaN) and positive or negative infinity. (from Python Docs)

This is deliberate: NaN is not equal to anything, not even itself.

Yet Python ensures:

hash(float('nan')) == hash(float('nan'))

Why? Because hash-based collections require a consistent contract: objects that are equal must share the same hash, but Python does not forbid unequal objects from sharing a hash.

Part 3: Hashing and Equality in User-Defined Classes

When you define your own class, you may decide what equality and hashing mean.

Now two scrolls with the same text are considered equal, and they share the same hash:

If you override __eq__ but forget to also override __hash__, Python will often make your object unhashable :

If you define them inconsistently like returning different hashes for equal objects, your code may behave strangely or inefficiently.

These are the guidelines for implementation from the python docs:

If a class does not define an __eq__() method it should not define a __hash__() operation either

if it defines __eq__() but not __hash__(), its instances will not be usable as items in hashable collections.

If a class defines mutable objects and implements an __eq__() method, it should not implement __hash__(), since the implementation of hashable collections requires that a key’s hash value is immutable (if the object’s hash value changes, it will be in the wrong hash bucket).

Part 4: Other Gotchas

4.1 Equality Across Types

Python strives for consistency across related types:

print(1 == 1.0)      # True
print(hash(1) == hash(1.0))  # True

Despite being different types, the value of 1 and 1.0 are equal, so their hashes are also equal.

d = {1: "integer"}
d[1.0]   # "integer"

At first glance this is elegant, but it means different numeric types may collapse into the same bucket, even if their meanings diverge in your domain. In scientific or financial code, this subtle equality can introduce surprising behaviour if you intended to distinguish int from float.

4.2 Immutable vs Mutable

Hashes are meant to be stable. If the contents of an object could change after being placed in a dictionary or set, the mapping would fall apart.

This is why:

Immutable containers (like tuples) are hashable — but only if all their contents are hashable.
Mutable containers (like lists and dicts) are not hashable.

hash((1, 2, (3, 4)))  # Works
hash((1, [2, 3]))     # TypeError

The error is not arbitrary. It protects you from placing an unstable key into a dictionary. Imagine changing the list inside a tuple after it has been used as a key — the hash would no longer reflect the object’s state.

The Final Seal

The novice saw two NaNs and said: "The seals are the same, so the things must be the same." The master corrected him: "The ink is the same, but the seal is broken."

Hashing is a symbol, not a proof. Equality and hashing may touch, but they are not bound. To see clearly, we must hold both the symbol, and the substance it points to.

Thanks for reading Python Koans! If you enjoyed this post, consider sharing with your friends or subscribing below:

Python Koans | Vivis Dev | Substack

Python lessons wrapped in koans. Small puzzles, deep truths. Not your usual tutorial thread. Click to read Python Koans, by Vivis Dev, a Substack publication with hundreds of subscribers.

pythonkoans.substack.com

Navigating Python's import system and namespace packages

Vivis Dev — Sat, 20 Sep 2025 12:56:00 +0000

The Hidden Teaching: The Nature of the Path

The student believes that a village must be a single, bounded place. But the master knows that a village can be a concept , defined by its connections and the paths that lead to it.

Thanks for reading Python Koans! If you enjoyed this post, consider sharing with your friends or subscribing below:

Python Koans | Vivis Dev | Substack

Python lessons wrapped in koans. Small puzzles, deep truths. Not your usual tutorial thread. Click to read Python Koans, by Vivis Dev, a Substack publication with hundreds of subscribers.

pythonkoans.substack.com

In Python, the import system follows a similar principle. You may think of packages as walled villages with a clear boundary. Yet the true nature of the path (sys.path) allows for the creation of unburdened villages: namespace packages, where a single logical package is assembled from components scattered across the filesystem.

Part 1: The Walled Village and the Path

The Python interpreter, when asked to import a package, follows a simple rule: it searches along a predefined path. This path, known as sys.path, is a list of directories.

A traditional package , or a "walled village," is a directory containing an __init__.py file. This file marks the directory as a package and provides its clear boundary. When you import this package, Python finds the directory on its path and all its contents are then accessible.

Consider a simple structure:

To use this, the directory containing my_village must be on sys.path. If you run Python from the directory above my_village, it is on the path by default.

The __init__.py is the village gate; it tells the interpreter, "This is the start of the journey."

Part 2: The Unseen Path and the Root of Confusion

The monk's confusion was not about the village itself, but about the assumption of a single starting point. The same confusion arises when a package is not directly on the path.

Consider the following:

If you run Python from a location that contains both project1 and project2, the my_village directories are not directly on sys.path. The path only contains the top-level directory.

The interpreter's path is not a tangled vine that seeks out all nested directories. It is a straight road, and it only knows about project1 and project2. It does not know to look inside them for other packages.

Part 3: The Unburdened Village: A Shared Destination

The solution lies in understanding the path as a shared space. A namespace package is created when multiple directories with the same name, but without an__init__.pyfile , are all placed on sys.path.

By adding the parent directories (project1 and project2) to the path, you instruct Python to consider them as valid starting points for imports.

The interpreter first looks on the path, finds project1, and sees a my_village directory inside. It then continues its search, finds project2, and sees another my_village directory. It then merges these two directories into a single logical package, the "unburdened village."

Part 4: The Path of the Confused Traveller

What if one part of the village has a wall and the other does not?

Consider if project1's my_village directory contains an __init__.py file, but project2's does not.

In this scenario, my_village is no longer a namespace package. Python's import system will find the first my_village directory on its search path (sys.path) that contains an __init__.py file, and it will treat that directory as the entire package.

When you run import my_village.temple, the interpreter will find the my_village directory in project1, but it will not continue to search for other my_village directories. It will only look for temple.py inside project1/my_village. The file will not be found, and you will get a ModuleNotFoundError.

The presence of the __init__.py file effectively "closes the gate" on the search for other parts of the package, turning it back into a traditional, "walled" package.

Part 5: The Power of the Unburdened Village

Why would one choose to build a village without walls?

Extensibility : Frameworks like pytest and zope use this pattern. The core library defines a namespace, for example my_app.plugins. Developers can then create their own packages, like my_app.plugins.my_feature, and the core application will automatically find and load them without any modification to the main codebase.
Decomposition : A large project can be broken into smaller, independent libraries that are developed and versioned separately but still function as a single logical package.
Modularity : It allows for a more distributed and modular architecture, where a project's components can be managed and installed from different locations.

Leaving the Village

The master's reply was a lesson in perspective. The village is not the directory itself but the concept of a shared space. The path is not a single location but a collection of all the roads one can travel.

Your confusion, like the monk's, arose from seeking a single physical truth. But Python's import system, like the master’s village, shows us that meaning can be constructed from disparate parts as long as you follow the right path.

Thanks for reading Python Koans! If you enjoyed this post, consider sharing with your friends or subscribing below:

Python Koans | Vivis Dev | Substack

Python lessons wrapped in koans. Small puzzles, deep truths. Not your usual tutorial thread. Click to read Python Koans, by Vivis Dev, a Substack publication with hundreds of subscribers.

pythonkoans.substack.com

Exploring how functions in Python are treated as first-class citizens, and the untapped potential they hold.

Vivis Dev — Sat, 20 Sep 2025 12:48:00 +0000

Functions as First-Class Citizens in Python

In Python, a function is much like a harp. An object that holds potential, a set of instructions waiting to be invoked and produce a harmonious result. This design choice makes functions "first-class citizens ," opening up a world of elegant and powerful programming paradigms.

Let's begin with this fundamental understanding.

Part 1: The Harp’s Existence

What does it mean for a function to be a "first-class citizen"? It means that functions can be:

Assigned to variables.
Passed as arguments to other functions.
Returned as values from other functions.
Stored in data structures (lists, dictionaries, etc.).

This is distinct from languages where functions are merely blocks of code that can be called, but not manipulated like other data.

Consider a simple instruction for making music with our harp:

def play_note(note):
    return f"The harp plays the note: {note}"

In Python, play_note isn't just a command; it's an object. You can prove this by assigning it to another variable, much like one might refer to the harp by a different name in an orchestra:

my_instrument = play_note
print(my_instrument("C major"))

Here, my_instrument now refers to the same function object as play_note. The harp exists, and we have a way to access its potential for sound, even if no note has yet been played.

Part 2: Passing the Harp to the Musician (Higher-Order Functions)

One of the most powerful implications of functions being first-class is the ability to pass them as arguments to other functions. Functions that accept other functions as arguments are known as "higher-order functions." This is akin to handing our harp to a skilled musician, trusting them to play its strings when the moment is right.

A common example is the map() function, which applies a given function to all items in an input list and returns an iterator. Let's imagine we have a sequence of musical ideas, and we want to apply a transformation to each using our harp's capabilities:

def harmonize_note(x):
    return f"{x} with harmony"

melody_notes = ["C", "G", "Am", "F"]
harmonized_melody = list(map(harmonize_note, melody_notes))
print(harmonized_melody)

Here, harmonize_note is passed as an argument to map. map doesn't know what harmonize_note does, only that it's a callable object it can apply to each element. It simply knows how to take a series of musical ideas and apply the "play and harmonize" instruction to each.

Part 3: The Unnamed Chord (Lambdas)

For simple, one-off musical expressions, Python offers "lambda expressions." These are small, anonymous functions that can be defined in a single line. They are particularly useful when you need a function object for a short period, often as an argument to a higher-order function, like a quick flourish instead of a formal composition.

Our koan's core, lambda x: x + 1, is an example of an anonymous function. It exists, it holds potential, but it doesn't have a formal name.

# Using a lambda with map to transpose notes:
base_frequencies = [440, 494, 523] # A4, B4, C5 frequencies
transposed_frequencies = list(map(lambda freq: freq + 50, base_frequencies))
print(transposed_frequencies)

Lambdas are succinct and often improve readability for simple operations, avoiding the need to define a full def function for a trivial task. They are like a quickly improvised chord on the harp.

Part 4: Plucking the String Immediately (Immediate Invocation)

Just as we can assign a lambda to a variable and then play it, we can also play it immediately after it's defined.

Consider our simple lambda from the koan:

lambda x: x + 1

This defines a function object. It is the silent harp string. To make it produce a result, we need to "pluck" it by providing an argument. We typically do this by assigning it to a variable first, then calling that variable:

increment_frequency = lambda x: x + 1
result = increment_frequency(10)
print(result)

However, because the lambda expression itself evaluates to a function object, you can immediately apply arguments to it, just like you would with any other function reference.

The koan's code demonstrates this:

(lambda x: x + 1)(10)

Here, (lambda x: x + 1) creates the anonymous function object (the harp string), and (10) immediately calls that function with the argument 10 (plucks the string). The parentheses around the lambda expression are crucial here to ensure the lambda is fully defined before the invocation operator () attempts to call it. Without them, Python would expect a function name to call.

This pattern, sometimes seen as an Immediately Invoked Function Expression (IIFE), is less common in everyday Python than in JavaScript, but it is perfectly valid and can be seen in specialized contexts, often for creating self-contained scopes or for quick, single-use computations without cluttering the namespace.

Closing the Circle

The silent harp holds all its potential for music within. Only when a string is plucked does its melody emerge. And sometimes, the note is played the very moment the string is tied.

In Python, functions are not just commands; they are entities with identity, capable of being manipulated, stored, and passed around like any other piece of data.

Thanks for reading Python Koans! If you enjoyed this post, consider sharing with your friends or subscribing below:

Python Koans | Vivis Dev | Substack

Python lessons wrapped in koans. Small puzzles, deep truths. Not your usual tutorial thread. Click to read Python Koans, by Vivis Dev, a Substack publication with hundreds of subscribers.

pythonkoans.substack.com

Understanding Late Binding in Python Closures

Vivis Dev — Sat, 20 Sep 2025 12:48:00 +0000

In Python, a function is more than a list of commands, as we learnt in Koan 5. When a function is defined inside another, it becomes a closure , a small piece of code that remembers its parent's environment. This memory is powerful, but it's not a picture of the past. It's more like a window. It shows you the world as it is right now , not as it was when the window was first opened. This phenomenon is known as late binding.

Let's begin by observing the simplest expression of a closure.

Here, execute_commission is the closure. It remembers the item variable from its parent function, make_commission. When we call draw_sun(), it returns "sun" as expected. The closure has a clear, singular memory of its purpose.

Part 2: The Master's Three Commands

Now, let's observe the lazy calligrapher's technique, as described in the koan. He waits until all instructions have been given before beginning his work.

One might expect the output to be "sun," "moon," and then "cloud." However, the code will print "cloud" three times.

This is the very essence of late binding. The execute_commission function doesn't capture the value of instruction at the time it's created. Instead, it holds a reference to the variable instruction itself. By the time we finally get around to executing the first function in the list, the for loop has already completed, and the variable instruction has a final value: "cloud."

All three closures refer to the same single instruction variable in the outer scope, which has finished its journey.

Part 3: The Diligent Calligrapher

To correct this behavior, we need a way for each closure to capture its own unique copy of the instruction at the moment it's created. We must teach the calligrapher to be diligent and remember each command individually.

One method to achieve this is by using a default argument. As we learnt in Koan 3, default arguments are evaluated once, at the time the function is defined. We can modify our make_commissions function to use this technique.

This time, the output is as we first intended. By setting the default argument item=instruction, we force Python to evaluate instruction and bind its current value to the item parameter for each new function. Each closure now holds its own unique copy of the instruction, rather than sharing a single reference.

Part 4: The Anonymous Calligrapher

This principle of late binding also applies to lambda functions. As we learnt in Koan 5, lambdas are simply anonymous functions. The "lazy calligrapher" effect is very common when lambdas are created in a loop.

Here is the original problem, written with a lambda:

Just like with the def-defined function, this will also return "cloud," because the lambda closes over the instruction variable, not its value.

To correct this, we use a default argument for the lambda function:

We can make this more concise and pythonic by using list comprehension to create all the commissions in a single stroke.

Part 5: The Master's Scrupulous Note

What if we could not use a default argument? Is there another way to force the calligrapher to capture the instruction immediately? The solution lies in creating a new scope for each instruction, forcing each closure to "listen" to a unique voice.

We can achieve this by creating a factory function that takes the instruction as an argument, thus creating a new, isolated environment for each closure.

This code also yields the correct output. On each iteration of the loop, we call create_executor(instruction). This function is given the current value of instruction. It then creates a new closure, execute_commission, which closes over item. Because item is a local variable within create_executor, its value is isolated from the outer loop's changes (as we learnt in Koan 4 about Python’s LEGB rule). Each call to create_executor creates a new, private memory for the closure it returns. It is as if the master wrote a small, specific note for each drawing, which the calligrapher could not forget.

Part 6: The Customized Brush

There are other, more concise or functional ways to achieve the same result. The choice of method often comes down to the clarity and style you prefer. We can use functools.partial to "pre-bind" the argument to a function. This is like preparing a special brush for each task, with the instruction already etched into its handle.

The Final Brushstroke

The Master's teaching was simple: the calligrapher did not remember what was once said, only the command that was last spoken when the drawing finally began.

In your code, your functions are like the forgetful calligrapher. The closure does not remember the values the variable held when it was created, only the last value is recalled when the function is run.

Thanks for reading Python Koans! If you enjoyed this post, consider sharing with your friends or subscribing below:

Python Koans | Vivis Dev | Substack

Python lessons wrapped in koans. Small puzzles, deep truths. Not your usual tutorial thread. Click to read Python Koans, by Vivis Dev, a Substack publication with hundreds of subscribers.

pythonkoans.substack.com

Understanding Python’s LEGB rule, closures, and why variables sometimes behave like shadows.

Vivis Dev — Sat, 20 Sep 2025 12:48:00 +0000

Variable Scope and the Shadows They Cast

In Python, variables are not always where they appear to be.

When a function runs, it carries with it not just its own code, but the shadow of names it has seen, names that belong to outer scopes.

To understand this, we must learn to see how Python resolves names.

Let us begin simply.

Part 1: The Local Glow

The simplest form of scope is the local scope. When you define a variable inside a function, it exists only within that function's execution.

def greet():
    message = "Hello, world!"
    print(message)

greet()
print(message)  # This would cause an error: NameError

Here, message is born and dies within the greet function. It's like a lamp lit only inside a small room; its light doesn't extend beyond the doorway.

Part 2: The Enclosing Room

Now, let's open another door. Python has a concept called enclosing scope. This applies to nested functions. If a variable isn't found in the immediate local scope, Python looks outwards to any enclosing functions.

Consider this:

def outer_function():
    outer_message = "From the outer room."

    def inner_function():
        print(outer_message)

    inner_function()

outer_function()

When inner_function is called, it first looks for outer_message within its own scope. It doesn't find it. So, it looks in the scope of outer_function, where outer_message resides. This works. The inner function can see the variables of its enclosing function, like seeing the light of a lamp in an adjacent room through an open door.

Part 3: The Global Stage

Beyond local and enclosing scopes, there is the global scope. Variables defined at the top level of a script or module are global. They can be accessed from anywhere within that module.

global_message = "From the wide world."

def display_global():
    print(global_message)

display_global()

Here, display_global can access global_message because it's in the global scope. This is like the sun's light, visible from every room.

Part 4: The Built-in Universe

Finally, there's the built-in scope. This contains all the names that Python pre-defines, such as print, len, str, True, False, and None. These are always available.

The order in which Python searches for names is known as the LEGB rule:

L ocal (current function)
E nclosing function locals (from inner to outer enclosing functions)
G lobal (top-level of the module)
B uilt-in (Python's pre-defined names)

Python stops at the first place it finds the name.

Part 5: When Shadows Deceive - Variable Binding

The true complexity arises when you assign to a variable within a deeper scope. When Python encounters an assignment statement, it assumes you intend to create or modify a variable in the current scope, unless explicitly told otherwise.

Let's revisit our koan's example:

shadow = 10  # Global shadow

def outer_lamp():
    shadow = 20  # This 'shadow' is local to outer_lamp()
    def inner_lamp():
        print(shadow)  # This 'shadow' refers to outer_lamp()'s shadow
    return inner_lamp

lamp = outer_lamp()
lamp() # Output: 20

Here's the crucial part:

shadow = 10 establishes a global shadow.
Inside outer_lamp(), shadow = 20 creates a new , local variable within outer_lamp's scope. This shadow is entirely separate from the global shadow. It does not modify the global shadow.
Inside inner_lamp(), when print(shadow) is called, Python searches for shadow using the LEGB rule. It finds shadow = 20 in its enclosing scope (outer_lamp), and that's the shadow it uses.

The lamp() call, which executes inner_lamp(), thus prints 20. The global shadow (which remains 10) is untouched, and the shadow in outer_lamp() casts its own shadow, independent of the global lamp.

Part 6: The Illusion of Locality

Now, a subtle twist:

shadow = "global"

def inner():
    print(shadow)
    shadow = "local"

inner()

What happens here?

Python raises an error:

UnboundLocalError: cannot access local variable 'shadow' before assignment

Why?

Because Python sees the assignment shadow = "local" and assumes that shadow must be local to inner. It does not look outside anymore. So when you try to read shadow before assigning it, Python is confused. There is a local shadow, but it has no value yet.

In Python, any assignment to a variable within a function makes that variable local to that function , unless explicitly declared otherwise.

This leads us to the next teaching.

Part 7: Declaring Intent – `global` and `nonlocal`

If we wish to use or modify a variable from an outer scope, we must declare our intent.

Using global:

shadow = 5

def modify():
    global shadow
    shadow = 10

modify()
print(shadow)  # 10

Here, global shadow tells Python: “I mean the shadow from the module’s top level.”

When working with nested functions, and using nonlocal:

def outer():
    shadow = 5
    def inner():
        nonlocal shadow
        shadow = 10
    inner()
    print(shadow)

outer()  # 10

Without nonlocal, the assignment would create a new local shadow inside inner.

With it, Python understands: use the variable from the enclosing function.

Extinguishing The Lamp

The Master's second lamp illuminated the truth: each lamp casts its own shadow. Similarly, in Python, each scope can define its own variables, creating distinct 'lamps' of variables. Without explicit instruction (like nonlocal or global), an assignment always defaults to the current, innermost scope, safeguarding higher-level variables from unintended modification.

Understanding scope is not just about avoiding errors; it's about designing clear, predictable, and maintainable code. It's about knowing where your variables truly reside, and how their light extends, or does not extend, into the surrounding code.

If you enjoyed this post, consider subscribing or sharing it with your friends:

Python Koans | Vivis Dev | Substack

Python lessons wrapped in koans. Small puzzles, deep truths. Not your usual tutorial thread. Click to read Python Koans, by Vivis Dev, a Substack publication with hundreds of subscribers.

pythonkoans.substack.com

Understanding how Python evaluates default arguments and why mutable defaults can carry unintended memory

Vivis Dev — Sat, 20 Sep 2025 12:47:00 +0000

Mutable Default Arguments and the Echoes of the Past

In Python, a function is not just a block of code, it is an object, alive with memory. And sometimes, that memory is louder than you expect.

We expect that every time we call ring(), it will create a new list and append "clang". But instead, each call remembers the last. Why?

Part 1: When Are Defaults Evaluated?

In Python, default arguments are evaluated only once — at the time the function is defined, not each time it is called.

So in:

def ring(bell=[]):

Python creates a new empty list once and binds it to the bell parameter’s default. All future calls to ring() without a bell argument will use that same list.

Thus:

first = ring()
second = ring()
third = ring()

print(first is second is third)  # True

They are all the same object.

This behavior often surprises beginners. It feels as if Python is remembering things it should forget. But it is not magic. It is memory: persistent, and shared.

Part 2: Mutable vs Immutable Defaults: A Gentle Contrast

The issue arises only with mutable default values, like lists or dictionaries. What if we used an immutable default, such as a tuple?

Consider:

def ring(bell=()):
   bell += ("clang",)
   return bell

What do you expect?

ring() # ('clang',)
ring() # ('clang',)
ring() # ('clang',)

Each call gives us a fresh result. There is no accumulation. No echo.

Why?

Because tuples are immutable. The += operator cannot modify the existing tuple. Instead, it creates a new one. In Python, the id()function gives you the memory address of an object. You can use this to test if the objects are the same, but beware of the CPython caching (also known as interning) we learnt about last week. To avoid CPython interning, we need to assign the result to a new object:

import time

def ring(bell=()):
    bell += (str(time.time()),)
    return bell

sound1 = ring(); print(id(sound1)) # 135080430662176
sound2 = ring(); print(id(sound2)) # 135080430179360
sound3 = ring(); print(id(sound3)) # 135080430181856

Each time, Python builds a new object and returns it. The original default remains untouched.

This is why only mutable default arguments pose a problem. It is not the default itself that is dangerous, it is the possibility of mutation.

When an object can change, and you reuse that object across calls, you risk unintended persistence.

Part 3: The Right Way: Use `None` as a Sentinel

The conventional solution is this:

def ring(bell=None):
    if bell is None:
        bell = []
    bell.append("clang")
    return bell

Now:

ring() # ['clang']
ring() # ['clang']

Each call receives a fresh list.

Why use None?

Because None is immutable and unique. It makes an excellent sentinel, a marker that tells us, “No argument was provided.”

If you use this pattern, your functions will behave predictably. The echoes will fade when they should.

Part 4: When Might You Use Mutable Defaults?

There are rare times when shared mutable state is intended. For example, a function that memoizes its own results:

def factorial(n, cache={0: 1}):
    if n not in cache:
       cache[n] = n * factorial(n - 1)
    return cache[n]

Here, the default dictionary acts as a persistent memory. But this is a deliberate choice, not an accident.

If you do this, document it clearly. Most of the time, such patterns are better handled with decorators or external caches.

Shared state is not inherently wrong, but it must be a conscious design, not an accidental side effect.

Best Practices: The Bellmaker’s Notes

Avoid using mutable objects like lists or dicts as default arguments.

They persist across calls and can lead to surprising behavior.
UseNoneas a default when you want a fresh object each time.

Inside the function, create a new object only when needed.
Immutable defaults (likeNone,0,'', or()) are always safe.

Operations like += on them return new objects, leaving the default unchanged.
If you mustuse a mutable default, document the behavior clearly.

Treat it as shared state and ensure your design requires it.
When debugging, useid()or logging to confirm whether the same object is reused, but beware of interning which can mislead you.

If your function “remembers” things, ask yourself: “Did I mean to ring the same bell again?”

Closing the Circle

The novice asked, “Why does the bell grow louder each time I call for it?”

The master replied,

“Because you never asked for a new bell.”

In Python, if a default argument is mutable, it will grow, echo, and persist across calls.

To write clean Python is to know which bells echo, and when to ring a fresh one.

Thanks for reading Python Koans! If you enjoyed this post, consider sharing with your friends or subscribing below:

Python Koans | Vivis Dev | Substack

Python lessons wrapped in koans. Small puzzles, deep truths. Not your usual tutorial thread. Click to read Python Koans, by Vivis Dev, a Substack publication with hundreds of subscribers.

pythonkoans.substack.com

Understanding the difference between identity and equality, and why it matters more than it seems.

Vivis Dev — Sat, 20 Sep 2025 12:46:00 +0000

"is" vs. "==": The Subtle Art of Identity and Equality in Python

When learning Python, it's common to encounter subtle distinctions that don’t make much sense at first. One of these is the difference between is and ==. At a glance, they both seem to answer the same question: "Are these things the same?" But in truth, they answer very different questions.

Let us begin at the beginning.

Part 1: The Two Questions

Python allows you to ask:

Do these two values have the same contents?

You use == to ask this question.
Do these two values refer to the same objectin memory?

You use is to ask this question.

In simple terms:

== asks, "Do they look the same?"
is asks, "Are they the same being?"

Let’s look at a few examples:

a = [1, 2, 3]
b = [1, 2, 3]

print(a == b) # True (same contents)
print(a is b) # False (different objects)

At first, this might feel strange. If they’re both [1, 2, 3], why wouldn’t they be the same?

Because Python has created two separate lists in memory. They hold the same values, but they are not the same object. Like two scrolls with identical text, one copied from the other. If you edit one, the other remains unchanged.

This is the heart of the difference between equality and identity.

Part 2: Why Use `is` At All?

Why not always use ==?

The is operator is not about equality of content, it is about identity. There are cases where identity matters deeply. One of them is checking for a sentinel object, such as None.

if user_input is None:
    print("No input provided.")

Here, you're not asking "Does the input look like None?" , but "Is the input literally the None object?"

This distinction ensures clarity and precision when writing code that interacts with unique markers or singleton objects.

Part 3: The Subtle Trap of Immutable Types

Now let’s tread into trickier ground. The behavior of immutable types , such as integers, strings, and tuples.

Consider:

a = 1000
b = 1000

print(a == b) # True 
print(a is b) # False (on most systems)

But then:

x = 5
y = 5

print(x == y) # True 
print(x is y) # True

Why the inconsistency?

This is due to an implementation detail of CPython (the most widely used Python interpreter). For performance, CPython caches small integers and some strings. So small values may end up pointing to the same object. But this is not something you should rely on. It's a quirk, not a guarantee.

In other words: the student sees that 1 is 1, and assumes the same for 1000 is 1000. But the truth changes subtly with scale, like mist lifting to reveal two paths instead of one.

Part 4: Containers and Identity

Let’s go a step deeper. What about empty containers?

print([] == []) # True - same contents (both empty)
print([] is []) # False - distinct list objects

Python creates a new list each time you write []. They are separate, though they appear the same. Like the student’s scrolls, word-for-word identical, yet changes to one do not touch the other.

And tuples?

print( () == () ) # True 
print( () is () ) # True (usually)

Here again, we encounter CPython’s caching. Because () is immutable and common, Python may reuse the same object. But this behavior is not mandated by the Python language specification, it is an implementation detail.

From Python 3.8 onwards, certain comparisons like () is () even raise a SyntaxWarning , gently nudging the student to rethink their assumption.

Best Practices

Use== when comparing values.

You’re asking, do these two things hold the same meaning or content?
Useis when checking for identity, especially for singletons like None, True, False, or a sentinel object you define.
Avoid usingiswith literals or immutable values , unless you have a specific reason to care about identity, and even then, document that reason.

Final Reflection

The master’s lesson was simple:

Two scrolls may appear the same. But when you change one, the truth of their separation is revealed.

In Python, == and is teach us to look beneath the surface. Equality is about appearance. Identity is about essence. And understanding this difference is not just a technical detail, it is a practice in seeing things as they truly are.

Thanks for reading Python Koans! If you enjoyed this post, consider sharing with your friends or subscribing below:

Python Koans | Vivis Dev | Substack

Python lessons wrapped in koans. Small puzzles, deep truths. Not your usual tutorial thread. Click to read Python Koans, by Vivis Dev, a Substack publication with hundreds of subscribers.

pythonkoans.substack.com

Understanding truthiness, falsiness, and the quiet meaning of emptiness in Python

Vivis Dev — Thu, 11 Sep 2025 23:46:50 +0000

The Hidden Teaching: `bool` and the Design of Truth

In Python, truth is not a binary of True and False. It is a reflection of meaning. Python asks, “In the context of logic, what does this object say about itself?”

To control how an object behaves in a boolean context, such as in an if statement, you may define the __bool__ method.

Let us begin again.

Part 1: The Interpreter’s Question

When Python evaluates an object in a boolean context like:

if some_object: 
    ...

It performs this sequence:

Call some_object.__bool__(), if defined.
If not defined, fall back to some_object.__len__():
- If length is 0, treat as False.
- Otherwise, treat as True.
If neither are defined, default to True

Thus, even a custom class can define its own measure of truth.

Part 2: Writing Our Own Truth

Let us construct a simple object: a container of wisdom.

class Scroll:
    def __init__(self, text):
        self.text = text

Now, let us observe its truth:

s = Scroll("Do not seek the truth, only cease to cherish opinions.")

if s:
    print("The scroll speaks.")
else:
    print("The scroll is silent.")

This will always print "The scroll speaks.", because Scroll has no __bool__ or __len__. Python defaults to treating all objects as True unless told otherwise.

Now, let us give it a voice of truth:

class Scroll:
    def __init__(self, text):
        self.text = text

    def __bool__(self):
        return bool(self.text.strip())

Now, observe:

Scroll(" ") # Behaves like False
Scroll("Peace") # Behaves like True

We have taught our object how to express its presence.

Part 3: Falling Back on `len`

If __bool__ is not defined, Python looks for __len__.

class WisdomBasket:
    def __init__(self):
        self.sayings = []

    def __len__(self):
        return len(self.sayings)

Now:

basket = WisdomBasket()
if basket:
    print("There is wisdom.")
else:
    print("The basket is empty.")

This is useful when your object represents a collection, and truth is tied to its contents.

Part 4: Truth as a Design Decision

Why does this matter?

Because in real-world code, truthiness is often meaning. Consider:

if response:
    ...

What should response mean?

Did the HTTP request succeed?
Did the response body contain useful data?
Was the status 200?

You decide what __bool__ should convey.

When designing APIs, internal libraries, or user-defined classes, a clear definition of truth can reduce boilerplate and make intent self-evident.

Part 5: A Caution on Ambiguity

Truthiness should be unambiguous and intuitive.

If your object represents a configuration, a request, or a resource, consider what it means to be “truthy.” Avoid cleverness that makes the logic obscure:

if config:
    # What does this mean?

Better to document, or avoid using truthiness altogether if the semantics are unclear.

Closing the Circle

The master did not say, "The empty list is False."
He said, "Not false. Only empty."

In Python, truth is not fixed. It is a shadow cast by your design. You may choose how your objects reflect light, or the absence of it.

If you enjoyed this post, consider subscribing or sharing it with your friends:

Python Koans | Vivis Dev | Substack

Python lessons wrapped in koans. Small puzzles, deep truths. Not your usual tutorial thread. Click to read Python Koans, by Vivis Dev, a Substack publication with hundreds of subscribers.

pythonkoans.substack.com

Forem: Vivis Dev

Understanding Python dataclasses and how fields determine equality and hashing.

Part 1: What is a Dataclass?

Part 2: The Empty Bowl

Part 2: Comparing Different Bowls

Part 3: Fields vs Class Variables

Part 4: Mutable vs Frozen Dataclasses

Part 5: Default Values and Factories

Offering the Bowl

Exploring the dangerous power of unquoted Python strings, and how they caused CVE-2024-9287

The Peril of Unquoted Arguments

Part 1: The Space as a Separator

Part 2: The Command Injection

Part 3: The Principle of Quoting

Part 4: The Path of Wisdom

Part 5: A Real-World Command Injection (CVE-2024-9287)

Forging the Blade

Understanding how Python's list comprehensions work under the hood

List Comprehensions

Part 1: The Inner World of the For Loop

Part 2: Peering into the water

Exploring chained operations and order of evaluation in python expressions

The Hidden Teaching: The Flow of Assignment

Part 1: Assignment Chains

Part 2: Identity and Comparisons

Part 3: Comparison Chains

Part 4: Chained Comparisons with Side Effects

Firing the pot

Understanding Python’s rules for hashing

Part 1: What is a Hash?

Part 2: The Strange Case of NaN

Part 3: Hashing and Equality in User-Defined Classes

Part 4: Other Gotchas

4.1 Equality Across Types

4.2 Immutable vs Mutable

The Final Seal

Navigating Python's import system and namespace packages

The Hidden Teaching: The Nature of the Path

Part 1: The Walled Village and the Path

Part 2: The Unseen Path and the Root of Confusion

Part 3: The Unburdened Village: A Shared Destination

Part 4: The Path of the Confused Traveller

Part 5: The Power of the Unburdened Village

Leaving the Village

Exploring how functions in Python are treated as first-class citizens, and the untapped potential they hold.

Functions as First-Class Citizens in Python

Part 1: The Harp’s Existence

Part 2: Passing the Harp to the Musician (Higher-Order Functions)

Part 3: The Unnamed Chord (Lambdas)

Part 4: Plucking the String Immediately (Immediate Invocation)

Closing the Circle

Understanding Late Binding in Python Closures

Part 2: The Master's Three Commands

Part 3: The Diligent Calligrapher

Part 4: The Anonymous Calligrapher

Part 5: The Master's Scrupulous Note

Part 6: The Customized Brush

The Final Brushstroke

Understanding Python’s LEGB rule, closures, and why variables sometimes behave like shadows.

Variable Scope and the Shadows They Cast

Part 1: The Local Glow

Part 2: The Enclosing Room

Part 3: The Global Stage

Part 4: The Built-in Universe

Part 5: When Shadows Deceive - Variable Binding

Part 6: The Illusion of Locality

Part 7: Declaring Intent – global and nonlocal

Extinguishing The Lamp

Understanding how Python evaluates default arguments and why mutable defaults can carry unintended memory

Mutable Default Arguments and the Echoes of the Past

Part 1: When Are Defaults Evaluated?

Part 2: Mutable vs Immutable Defaults: A Gentle Contrast

Part 3: The Right Way: Use None as a Sentinel

Part 4: When Might You Use Mutable Defaults?

Best Practices: The Bellmaker’s Notes

Closing the Circle

Understanding the difference between identity and equality, and why it matters more than it seems.

"is" vs. "==": The Subtle Art of Identity and Equality in Python

Part 1: The Two Questions

Part 2: Why Use is At All?

Part 7: Declaring Intent – `global` and `nonlocal`

Part 3: The Right Way: Use `None` as a Sentinel

Part 2: Why Use `is` At All?

The Hidden Teaching: `bool` and the Design of Truth

Part 3: Falling Back on `len`