DEV Community: Yehan Wasura

I Turned an EXE Into Music (and it actually tells you something)

Yehan Wasura — Sun, 11 Jan 2026 04:58:15 +0000

Executable Animator: sonify “machine-code-ish” byte patterns into a WAV, generate a visual fingerprint PNG, and watch it pulse in real time

I was staring at a binary file the way you stare at a wall of rain.

If you are into this kind of things, like reverse engineering and whatnot, you know the vibe:

Hex dump looks like… hex dump, disassembler is loud, and your brain is even louder. And you are thinking: “There has to be a more sensory way to feel the structure. ”

So I did what any reasonable person does when bored and curious. I made a tool that turns any binary (EXE / DLL / SO / OBJ / firmware dump / random blob) into:

a WAV you can literally listen to
a PNG “dashboard” that looks like a “fingerprint”
a live visualizer (oscilloscope / spectrum bars / radial pulse) while it plays

This project is Executable Animator (https://github.com/RezSat/executable-animator)

What this is (and what it isn’t)

This doesn’t “ understand assembly ”. It doesn’t emulate code or even decompile.

It does something simpler and surprisingly useful:

Treat the binary as a stream of bytes, slide a window over it, extract rolling “texture” features and map them into sound and visuals.

If you have ever looked at entropy graphs of packed malware vs normal code… yeah. Same energy.

But now you can hear it.

The core idea: “Byte Texture” in small windows

The worker (main.py) reads the file as raw bytes and summarizes it chunk by chunk.

Then it extracts a few features per window:

Shannon Entropy ( 0-8 bits for byte distribution): High entropy often correlates with compressed/encrypted/packed regions. Low entropy often correlates with padding/repeated/patterns/structured data
Mean Byte Value (0–255)
Standard Deviation (how “spread out” the bytes are)
Nibble Histogram (distribution of half-bytes 0–15, this is weirdly good at revealing “instruction/padding vibes”)

That’s it. No ML. No magic. Just “what does this region feel like statistically?”

Turning those features into sound (aka: I made bytes sing)

Each window becomes a short synthesized note. Then notes are concatenated into a full track.

Here’s the mapping (straight from the code logic):

Pitch — mean byte value (then quantized to a pleasant scale)
Amplitude — entropy (more complex region makes it louder)
Brightness — standard deviation (more spread gives brighter tone)

To avoid a random mix of MIDI data, pitches are quantized into a major pentatonic-ish scale (I mean, our ears deserve rights).

And the synth itself is an FM-ish tone: brightness increases the modulation index, so high-variance regions literally get more harmonics.

# pitch from mean (0..255)
midi = midi_low + (midi_high - midi_low) * (mean / 255.0)
midi_q = quantize_to_scale(midi, scale)

# amp from entropy (0..8)
amp = 0.08 + 0.35 * (clip(entropy, 0..8) / 8.0)

# brightness from std
bright = clip(std / 90.0, 0..1)

(You can tweak window size, stride, note duration, MIDI range… and completely change the “instrument.”)

The PNG “fingerprint” dashboard

Alongside the audio, this will also generate a PNG with multiple panels:

Byte Image (grayscale hexdump as image)
Entropy over time (and pitch overlay)
Byte histogram
Nibble distribution heatmap over time

PNG dashboard output for sample binary file

This lets you visually correlate what you’re hearing.

Why did the song suddenly get loud and bright here? Look at the entropy spike and nibble chaos. That section is probably not boring padding anymore.

If you’re writing malware analysis notes or reversing firmware, this is a fun “first glance” artifact to attach.

The GUI: because CLI is cool, but watching and clicking is fun

Code is in the gui.py.

GUI of the program with visual preset set to Oscilloscope

This wraps the worker and gives you:

File picker + Generate
Play/ Stop/ Loop
Visualizer presents: Oscilloscope, Spectrum Bars, Radial Pulse
Zoom + pan PNG preview (with smooth scaling)

Under the hood, the GUI literally runs the worker as a subprocess with arguments (so you can test configs without editing the code like a caveperson).

How to try it

Clone the repo: https://github.com/RezSat/executable-animator.git

(Recommended) Run the GUI: python gui.py

Pick a binary. Generate. Hit Play. Boom.

Or run the worker directly (CLI)

python main.py /path/to/file.exe -o out
#writes out.wave and out.png

For big files, increase window/stride so you don’t accidentally compose a 47 minute symphony from a DLL.

More parameters are discussed in the README, visit the GitHub Repo and find them.

Fun experiments (try these if you want your brain to do the “Oh??” thing)

Compare a normal executable vs a packed one (entropy often screams)
Feed a PNG or ZIP and notice how the “texture” changes
Feed firmware dumps — you sometimes get very distinct rhythmic regions (padding, lookup tables, code blocks)
Try different strides and note durations, you’ll feel the “resolution vs speed” tradeoff immediately

Safety note: this reads bytes; it doesn’t execute the file. Still, don’t go downloading mystery malware just to make a sick beat. Be normal.

Why I built this (really?)

Because binaries aren’t just numbers. They have structure.

And sometimes structure is easier to spot when you’re not staring at it, when you’re hearing it, or watching it pulse (or so I think).

Also, building little tools like this is how I stay sharp. This is the kind of thing I end up making when I’m bored.

If you try it, tell me what weird things you found. Contributions are welcome — if you add or improve anything, feel free to open a PR.

https://github.com/RezSat/executable-animator

The Truth About Python’s Truthiness

Yehan Wasura — Thu, 04 Dec 2025 19:48:16 +0000

Stop writing if name == 'java' or 'html' ; it’s not doing what you think it’s doing.

Within the first glance, it looks like a simple check that sees whether the variable name is either java or html. If you thought, so, then this article is mainly for you.

I found this while scrolling Instagram in a Saturday evening, there was a reel with a challenge similar to below code (sorry, I couldn’t find the original one, so this is my version of it). And looking at the comment section, there were many confused people — hence, this article.

name = 'python'
if name == 'java' or 'html':
    print('correct name')
else:
    print('wrong name')

The output of the above code is correct name.

Now let’s analyze and see why?

Python is not interpreting this as two comparisons, so in your mind the above code should look like this:

(name == 'java') or (name == 'html')

But Python actually parses it as:

(name == 'java') or ('html')

You see the difference? html is a non-empty string and sitting alone there. The whole right side of the or operator is now a non-empty string.

To understand this, run the below code and observe the output:

x = ""
if x:
  print("Case 1")
else:
  print("Case 2")

The output gives you Case 2 because, the IF-condition checks if the string is Empty or Not.

Empty String → False
Non-Empty String → True

Let’s get back to here : (name == 'java') or ('html')

or becomes the operator here that separates the code into left and right parts.

name == 'java' → returns False (because name was 'python')
'html' → returns True (because it's non-empty string)

So the total expression is now look like this: False or True, which we all know with the basic logic gates knowledge is True (or-gate returns True as long as at least one output is True).

This happens because of the single string just sitting there, because Strings in python are considered “truthy”.

What in the world is Truthy?

“ Truthy ” is a term used in Python (and many other programming languages), and it refers to values that are considered True when evaluated in a *Boolean * context.

Make a note that, this is not the same as the Boolean value True.

When these truthy values are used in conditions like if-statements or while-loops , a truthy value will cause the condition to pass.

↓ Just a Fun Fact for Non-native English speakers me:

Other than in the Programming context, word “truthy” has an older, non-technical definition and a more modern common usage as well:

Older : it is used to simply mean truthful or veracious (telling the truth).

Modern Slag/ Colloquialism : The term was famuously popularized in 2005 by U.S. comedian Stephen Colbert. Where “truthiness” (noun) refers to the quality of seeming or being felt to be true, even if it not supported by facts or evidence. (i.e, gut feeling).

The adjective “truthy” is used to describe something that has that quality.

Truthy and Falsy in Python

This is one of those things that seems wrong until you look a bit deeper. In Python, Logical operators don’t force a boolean context unless they _have _to.

They operate on “objects”, not just True or False. In Python, every value has an inherent Boolean nature.

So:

expr1 or expr2

Returns expr1 if it’s truthy, otherwise returns expr2. This is not about correctness or boolean purity. It’s all about evaluating the minimum necessary and then passing the original value up.

That is why this works:

username = input() or "guest"

If you enter nothing, input() returns an empty string(falsy), so “guest” becomes the final value. Super convenient. But the moment you’re doing real comparisons, this same behavior becomes a gremlin waiting to ruin your code (at least in the pre-AI era… you lucky b — well, you get the idea).

Anyway, let's look at what objects are truthy and falsy in python, so you don’t get bamboozled again.

Falsy Values (Exceptions)

The concept of “truthy” is easiest to understand by first knowing the exceptions that are considered as falsy. These are the values that evaluate to False in a Boolean context.

The Boolean False itself.
Zero of any numeric type : ◗ Integer (int) : 0 ◗ Float (float): 0.0 ◗ Complex (complex ): 0j
Empty sequences and collections: ◗ Empty String: "" or '' ◗ Empty List: [] ◗ Empty Tuple: () ◗ Empty Dictionary: {} ◗ Empty Set: set()
The special value ** None**

Truthy Values (Everything Else)

Every value that is NOT one of the falsy values given above is considered truthy.

The Boolean True
Any non-zero number (positive or negative)
Any non-empty sequence or collection (__bool__ or __len__) that makes them falsy.

So, what is the right way to write our original intention?

Well in programming there are different ways to do things, because it all depends on the program you're building, here are some very common ways to do this particular thing.

Repeat the comparison — if you actually wanted to check if name is 'java' or 'html’, you need to repeat the comparison.

if name == 'java' or name == 'html':
  ...

Use in keyword — cleaner way in my opinion, because it reads better and has zero ambiguity, also doesn’t rely on the truthiness magic.

if name in ('java', 'html'):
  ...

Many other languages also support this truthiness/falseness concepts, but some of them do not allow them at all. Here is an extra breakdown of a few selected languages:

Languages where “truthiness / falsiness” is built in (non-boolean values allowed in conditionals)

JavaScript ◗ JS has a defined set of falsy values: false, 0, -0, 0n, "", null, undefined, NaN. Everything else is truthy — numbers (non-zero), non-empty strings, objects, arrays, functions, etc. ◗ Because of this, constructs like if (someString) or if (someObject) work, even if the value isn’t strictly true or false.
Ruby ◗ Ruby’s rule is simpler: only false and nil are falsy. Everything else — even 0, "", empty arrays — is truthy.
PHP ◗ "", "0", 0, 0.0, (), undef → falsy
Perl ◗ "", "0", 0, 0.0, (), undef → falsy
Lua ◗ only false and nil are falsy ◗ everything else → truthy
Shell Scripting (bash, sh) ◗ Commands return exit codes; ◗ 0 = truthy, non-zero = falsy (Completely reversed from typical languages.)

Languages where truthiness is not allowed or is very limited

Java ◗ if ("hello") → compile error ◗ Must use: if (someBooleanExpression)
C / C++ (modern style) ◗ C itself treats 0 as false and non-zero as true — but that’s not real “truthiness,” it’s integer coercion, not object truth value. ◗ Anything that’s not an integer must be explicitly converted. ◗ C++ (modern) is stricter: ◗ You cannot do: if (“abc”) // error in modern compilers
C# ◗ Very strict. if ("text") → compile error
Go ◗ Bans truthiness completely. ◗ You must write:if len(s) > 0 { … } ◗ You cannot do: if s { … } // error
Rust ◗ Same as Go, No truthiness. ◗ You must explicitly compare or convert. if my_vec.is_empty() { … }
Swift ◗ you cannot use arbitrary types in an if condition — the expression must evaluate to a Boolean type. For example, if [] { ... } or if 0 { ... } won’t compile.
TypeScript (in strict mode) ◗ JS has truthiness, but TypeScript tries hard to warn you.

What these language comparison tells us is that,

Not all “truthiness” rules are the same across languages. What counts as falsy in one might be truthy in another.
Even languages with truthiness may treat containers differently. For example, JS considers even empty arrays as [] as truthy.
Type coercion vs strict boolean types: Some languages like C treat (0 vs non-zero) as (false vs true), but that’s integer coercion, not truthiness in the modern sense.

Because of all these nuances and caveats, you can’t assume a universal “ truthiness rule ”, Always check the language spec or docs.

Truthiness isn’t a flaw — it’s one of Python’s most flexible features. But like anything powerful in programming, it can betray you if you don’t fully understand it.

As the quote goes:

‘Great power comes with great responsibilities.’

CPython Object Model and Reference Counting — Trying to make sense of PyObject and PyTypeObject

Yehan Wasura — Fri, 26 Sep 2025 13:21:24 +0000

CPython Object Model and Reference Counting — Trying to make sense of PyObject and PyTypeObject

Before starting, I think I should say that this article is quite long, and take some breaks within sections to understand everything properly and also there are interactive code examples which you should try, especially if you are new to these topics, let me also try to answer the inevitable question:

Why should anyone care about this?

For me, it’s about intellectual satisfaction and academic interest. I simply want to understand my tools better. Python is my go-to language for everything; it’s the language of my life, so knowing it more deeply makes me happy.

For others, or perhaps even for you, there might be different reasons. But if you’ve just stumbled upon this and are wondering why you should care, let me share some insights that might pique your interest:

Write More Performant Python Code: By knowing how objects are allocated and deallocated and how references impact memory, you can write code that is more memory-efficient and avoids unnecessary overhead.
Debug Memory-Related Issues More Effectively: Understanding reference counting is crucial for identifying and resolving memory leaks, excessive memory consumption and unexpected object lifetimes.
Optimize C Extensions for Python: If you’re writing C extensions to improve performance or interact with low-level libraries, a deep understanding of PyObject and reference counting is absolutely essential for correct memory management and avoiding crashes.
Contribute to CPython Development: For those aspiring to contribute to the Python core or develop sophisticated tools that interact deeply with the interpreter, this knowledge is a prerequisite.
Understand Advanced Python Concepts: Many advanced Python features, such as metaclasses, descriptors, and the gcmodule, become much clearer when you grasp the underlying object model.
Make Informed Architectural Decisions: When designing large-scale Python applications, knowing the implications of object creation, immutability, and memory management helps you make better choices for data structures and overall system design.
Enhance Cybersecurity Understanding: This knowledge is crucial for identifying, analyzing, and fixing security vulnerabilities in Python applications and the CPython interpreter itself, especially those related to memory management and object handling. It’s also vital for understanding exploits and malware.

These insights can also be particularly handy for Computer Science students or researchers when learning about programming language implementation as part of their studies.

(Throughout this article, “Python” exclusively denotes the CPython implementation, which is the main-adopted version of the language). All code examples provided are accessible via a single Google Colab instance at https://colab.research.google.com/drive/1RfLUdQbQWDMxonA5Zidn4teNKxfLYQ6d?usp=sharing, requiring no local setup to run and observe the output. This Colab link will also be periodically reminded in each relevant section. Full code examples within the article will link directly to their corresponding GitHub Gists for easy reference.

Also Note that, code snippets that I will use by referencing actual source files are simplified for understanding the core behaviors and structure, the actual implementation might be very different at first glance due to having extra code for optimizations and all.

Now that we have a reason, let’s get started!

1. The Base: PyObject/PyVarObject and Memory Management

A. The Heart of Everything: PyObject/PyVarObject and PyObject_HEAD/PyObject_VAR_HEAD

“Everything is an object in python”, this is not merely a high-level abstraction; it translates directly into the fundamental architecture of its reference implementation, CPython. Every Python object is represented as a C structure, specifically PyObjectbeginning with a standardized header. At minimum, this header includes a reference count and a pointer to the object’s type. In C these are encapsulated by the macros PyObject_HEAD and PyObject_VAR_HEAD. For example, in CPython’s source (in Include/object.h), the core idea is that a fixed-size object’s header is conceptually structured as:

typedef struct _object {
    PyObject_HEAD /* macro expanding to ob_refcnt and ob_type */
} PyObject;

And a variable-sized object:

typedef struct {
    PyObject_VAR_HEAD /* includes ob_refcnt, ob_type, and ob_size */
} PyVarObject;

Specifically, PyObject_HEAD expands to

Py_ssize_t ob_refcnt;
struct _typeobject *ob_type; // Often aliased as PyTypeObject*

This means that, at its most fundamental level, the PyObject structure directly contains:

typedef struct {
    Py_ssize_t ob_refcnt; /* object reference count */
    PyTypeObject* ob_type; /* object type */
} PyObject;

And similarly, PyObject_VAR_HEAD expands to PyObjectHEAD followed by Py_ssize_t ob_size;, making PyVarObject conceptually:

typedef struct {
    Py_ssize_t ob_refcnt; /* object reference count */
    PyTypeObject* ob_type; /* object type */
    Py_ssize_t ob_size; /* number of items in variable part (e.g., list length) */
} PyVarObject;

(Note: While these typedef examples illustrate the fundamental structure after macro expansion, the actual CPython source (e.g., in Include/object.h) achieves this through a more layered approach where PyVarObject embeds a PyObject as its base, and macros like PyObject_HEAD are primarily used when defining other object types to ensure they start with these common fields. But this is fine for our simple understanding purposes.)

This means every Python object has an ob_refcnt (its reference count) and ob_type (pointer to its PyTypeObject). Variable-sized objects (like list or tuples) uses PyObject_VAR_HEAD, which adds a Py_ssize_t ob_size field for its length. Thus, the memory layout of an object always begins with these fields, and the order of this layout is fixed; first ob_refcnt, then the ob_type pointer, followed by ob_size(if variable-sized), and then any instance-specific fields. CPython internally aligns these fields according to the platform’s Application Binary Interface (ABI).

It is important to note that while all Python objects conceptually begin with this structure, nothing is explicitly declared as a PyObject. Instead, any pointer to a Python object can be safely cast to a PyObject *, giving a consistent interface to the most fundamental object properties.

For stability across Python versions and to ensure binary compatibility for C extensions, direct member access to ob_refcnt, ob_type or ob_size is strongly discouraged. CPython provides specific macros like Py_REFCNT(obj), Py_TYPE(obj), and Py_SIZE(obj)for this purpose. The use of these macros is a critical mechanism to maintain ABI stability, ensuring that even if the internal layout of these core structures changes in future CPython versions, existing C extensions do not require recompilation (pretty sick heh). This fosters a stable and evolving ecosystem.

B. Core Memory Management: Reference Counting

CPython’s primary memory-management strategy is reference counting.

The ob_refcnt field (Py_ssize_t), in which the reference counting heavily relies on, is a counter that tracks the number of " strong" references pointing to the object.

The CPython API distinguishes between “ strong ” (or “ owned ”) and “ borrowed ” references. A “ strong ” reference implies that the holder is responsible for decrementing the object’s reference count when the reference is no longer required. Functions that return “ new references ” provide strong references. In contrast, a “ borrowed ” reference signifies that the holder does not own the reference and, critically, should not decrement its count. These are typically temporary views into an object.

When a new reference to an object is created, its ob_refcnt must be incremented (Py_INCREF); when a reference is released, it must be decremented (Py_DECREF). The CPython runtime exposes macros and functions for this:

Py_INCREF(op): Increment op->ob_refcnt.
Py_DECREF(op): Decrement op->ob_refcnt; if the count becomes zero, it triggers the object's deallocation process.
Py_XINCREF(op) / Py_XDECREF(op): Like the above, but first checks if op is not NULL, avoiding null-pointer dereferences.

In the source, these are defined as below (simplified for clarity, as the actual code includes debug accounting macros) :

#define Py_INCREF(op) (((PyObject*)(op))->ob_refcnt++)
#define Py_DECREF(op) do { \
    if (--((PyObject*)(op))->ob_refcnt != 0) \
        ; /* still live */ \
    else \
        _Py_Dealloc((PyObject*)(op)); \
} while (0)

Thus, when Py_DECREF drops the reference count to zero, it invokes _Py_Dealloc, which in turn calls the object’s tp_dealloc function. As the C API documentation notes, "Once the last strong reference is released… the object’s type’s deallocation function (which must not be NULL) is invoked."

Because forgetting to update reference counts causes leaks (if too few decrements) or crashes (if too many and the object gets freed prematurely), the rule is: every code path that creates or holds a reference must ensure a matching INCREF / DECREF . For example, when assigning an object to a new holder, one might do Py_INCREF(obj); holder->attr = obj;. Python’s C-API docs advise always wrapping pointer assignments with these macros. In code, a safer pattern when setting fields in a tp_dealloc or tp_clear function is to use Py_CLEAR , which does a safe null-checked DECREF:

#define Py_CLEAR(op) do { \
    if ((op) != NULL) { \
        PyObject *_tmp = (PyObject*)(op); \
        (op) = NULL; \
        Py_DECREF(_tmp); \
    } \
} while(0)

This is recommended to avoid subtle bugs, such as if the deallocation triggered new code that re-accessed the pointer. It is essential to use Py_INCREF and Py_DECREF (or their X variants) rather than manipulating ob_refcnt directly, as these macros handle crucial nuances like debug hooks and immortal objects, ensuring correctness. The "X" variants (Py_XINCREF / Py_XDECREF) simply do nothing if passed a NULL, avoiding the need for explicit null checks before calling them. Python’s C API docs summarize their role: "Py_INCREF indicates taking a new strong reference… Py_DECREF releases a strong reference. When done using the object, release it by calling Py_DECREF."

The embedding of ob_refcnt directly within the PyObject header is a deliberate architectural choice. This physical proximity ensures that reference count operations are highly efficient, enabling the prompt release of memory as soon as an object is no longer referenced. This design prioritizes immediate resource cleanup for the vast majority of objects. For C extension developers, correctly managing this count is paramount to prevent insidious memory leaks or catastrophic use-after-free errors.

2. The Link to Behavior: “ob_type“ and the “PyTypeObject” Blueprint

The behavior and layout of an object’s data come from its type object. Every type in CPython is represented by a PyTypeObject structure. This structure begins with PyObject_VAR_HEAD so type objects themselves are full python objects, and yes type is an instance of itself (I know, it’s pretty Ziggazagga, yeah I don’t think that’s a word.)

So, as discussed in 1-A, PyObject_HEAD has this ob_type field, which is the link or the pointer to that object’s type information. Yes, now you understand why I used that word up there.

A. The Link to Type Information

The ob_type field (PyTypeObject*) is a pointer to the object’s type object. This pointer is the basically how the CPython achieves polymorphism and dynamic typing. Every object “knows” its type, and through that type, it understands its intrinsic behavior like its methods, its attributes, and supported operations.

For instance, an Integer object’s ob_type member points to &PyLong_Type, a string object's to &PyUnicode_Type, instances of user-defined classes will point to their corresponding PyTypeObject. This ob_type pointer forms the very foundation of Python's dynamic typing and object-oriented features at the C level. By centralizing behavioral definitions in PyTypeObject, the interpreter can dispatch calls and resolve attributes at runtime without requiring explicit type checks for every operation, which underpins Python's "duck typing" philosophy; “If it walks like a duck and it quacks like a duck, then it must be a duck.” thing, anyway that’s something to talk later, I’m quickly getting distracted writing this.

B. The Comprehensive Behavioral Blueprint (An Introduction to PyTypeObject)

We talked about that Ziggazagga thing earlier, signifying that type objects themselves are full Python objects. And how type (the metaclass for all types) is an instance of itself, conceptually embodying this recursive nature within the interpreter. Now let’s take a look at the definition of PyTypeObject (in Include/object.h) :

typedef struct _typeobject {
    PyObject_VAR_HEAD /* ob_refcnt, ob_type (metatype), ob_size */
    const char *tp_name; /* type name, e.g. "int", "module.Class" */
    Py_ssize_t tp_basicsize; /* instance size in bytes */
    Py_ssize_t tp_itemsize; /* for var-sized objects (e.g. tuple) */

    /* Methods to implement standard operations (examples) */
    destructor tp_dealloc; /* how to free an instance */
    /* ... many more fields for attribute access, etc. ... */
    initproc tp_init; /* __init__ : initialize new instances */
    allocfunc tp_alloc; /* memory allocator for instances */
    newfunc tp_new; /* __new__ : create and return new instances */
    freefunc tp_free; /* low-level deallocation of memory */
    inquiry tp_is_gc; /* support for cyclic GC */
    /* ... */
} PyTypeObject;

Yeah, there is a lot. These fields serve as pointers to C functions or contain vital metadata, effectively encoding all the behavior of a type. Like tp_name stores the human readable name of the type (ex: “int”, “str”, “MyBadClass”). Fields like tp_basicsize and tp_itemsize determines the memory allocation needs for instances of this type. tp_new and tp_init are correspond to Python’s __new__ and __init__ methods, which does the object creation and initialization. More specifically, the tp_new points to a function that is responsible for allocating and returning a fresh instance (usually by calling PyObject_New or PyObject_NewVar)

The tp_dealloc function is what cleans up the object, when an object’s reference count drops to zero (it’s what you call a “destructor function”, so essentially tp_dealloc is a pointer to this function). Let’s look at a custom extension type implementation:

static void
    foo_dealloc(foo_object *self) {
        /* release contained references, possibly via Py_CLEAR() */
        Py_XDECREF(self->inner_ref);
        /* call tp_free to free memory */
        Py_TYPE(self)->tp_free((PyObject*)self);
}

The tp_free function is typically PyObject_Del (if object was allocated with PyObject_New ) or PyObject_GC_Del (for GC tracked objects) .

“The destructor function is called by the Py_DECREF() and Py_XDECREF()macros when the new reference count is zero. … The destructor should free all references the instance owns, free any memory buffers owned by the instance, and call the type’s tp_free function.” — excerpt from the doc: https://docs.python.org/3/c-api/typeobj.html — specifically from here

And fields like tp_is_gc determines if the type participates in cyclic garbage collection. If so, the runtime will also call the type’s tp_traverse and tp_clear functions when collecting cycles.

This honestly is just merely scratching the surface of PyTypeObject‘s capabilities. In the following sections, we will dive more into Structure, Semantics and Object Lifecycle Management like things and gets our hands dirty with some real coding.

3. Deep into PyTypeObject — Structure, Semantics and LifeCycle

A. The “tp slots”: A Comprehensive Look at Type Behavior

This object we are talking about, the PyTypeObject structure is a vast collection of C function pointers and other fields, which collectively known as “slots”. These slots are the C-Level implementation of Python’s special methods ( such as tp_name -> __name__ , tp_dealloc -> __del__ and tp_repr -> __repr__ )and other intrinsic behaviors. When defining a custom type in C (we are going to do that later in this article), developers populate these slots with pointers to C functions that implement the desired Python behavior. The PyType_Ready() function is then invoked to finalize the type object, populating any unassigned slots with default implementations and preparing the type for use within the interpreter.

These methods (such as __name__, __repr__, __add__ etc) are also known as “dunder” methods (short for “double underscore”)

1. Core Identity and Layout

Lets talk about the slots that define a type’s fundamental identity and its instances’ memory footprint.

tp_name is of course the most straightforward one, it’s simply a C string ( const char * ) that holds the type’s fully qualified name (ex: int or module.ClassName . This is basically how the interpreter knows what kind of thing it’s dealing with. It’s like the name tag of the type.

tp_doc which is also a const char * , and is pointing to the type’s docstring, when we do something like MyBadClass.__doc__ in Python, that is where it pulls that from.

Then there are two fields which take care of how much memory a type’s instance will occupy:

tp_basicsize (Py_ssize_t): Defines the minimum number of bytes required (or the base memory required) to store a single instance of the type.
tp_itemsize ( Py_ssize_t ): Specifies the per-item size for variable-length objects, such as tuples or strings, so like how many extra bytes to allocate for each item depending on how many elements the object will hold.

2. Attribute Access

The way Python handles attribute access is what brings flexibility to its highly dynamic object model.

The two main function pointers are:

tp_getattro (getattrofunc): This slot is called whenever an attribute is accessed such as obj.attr. It effectively maps to Python’s __getattribute__, and supports the fallback behavior of __getattr__ when needed.
tp_setattro (setattrofunc): This slot is responsible for attribute assignments and deletions (obj.attr = val or del obj.attr). It's the C-level equivalent of __setattr__ and __delattr__

In addition to above raw function hooks, we have arrays that allows types to present a structured view of their attributes and methods:

tp_methods (array of PyMethodDef): This defines the regular methods available on the type, these are the classic C-extension methods that become bound functions when accessed from Python.
tp_members (array of PyMemberDef): These describe basic C struct fields directly exposed as attributes. They are useful for simple int, float, or pointer fields that map directly from C to Python.
tp_getset (array of PyGetSetDef): This defines custom getter/setter pairs that work like properties, invoking logic on access, similar to what you’d write using the @property decorator in pure Python.

These slots and arrays collectively establish the low-level framework behind Python’s attribute handling mechanism. They support everything from simple field access to complete descriptor protocol integration, all while adhering to the Method Resolution Order (MRO).

We’ll explore the details of MRO later in another section, since it determines the exact order in which Python searches for attributes across complex inheritance hierarchies.

3. Protocol Implementations

PyTypeObject also has various pointers to sub structures and individual function pointers. These are the key “Protocol implementations” that determine how an object responds to different Python operations. The brilliance of this approach allow a single object to behave as a number, a sequence, a mapping, or be callable, iterable or comparable.

tp_as_number ( PyNumberMethods * ), this pointer is to PyNumberMethods structure, a collection of C functions that says what to do when treated like a number. If this pointer is not NULL, the object can perform defined arithmetic operations, such as those implemented by the __add__ and __sub__ etc methods. These methods allow for operations like addition and subtraction to be performed on instances of the object.

for example:

class CustomNumber:
    def __init__ (self, value):
        self.value = value

    def __repr__ (self):
        """
        Provides a developer-friendly string representation of the object.
        """
        return f"CustomNumber({self.value})"

    # --- Arithmetic Dunder Methods ---

    def __add__ (self, other):
        """
        Implements the addition operator (+).
        Called for CustomNumber() + other.
        """
        return CustomNumber(self.value + other.value)

    def __sub__ (self, other):
        """
        Implements the subtraction operator (-).
        Called for CustomNumber() - other.
        """

        return CustomNumber(self.value - other.value)

    def __mul__ (self, other):
        """
        Implements the multiplication operator (*).
        Called for CustomNumber() * other.
        """

        return CustomNumber(self.value * other.value)

    def __truediv__ (self, other):
        """
        Implements the true division operator (/).
        Called for CustomNumber() / other.
        """

        if other.value == 0:
            raise ZeroDivisionError("division by zero")
        return CustomNumber(self.value / other.value)

# --- Demonstration ---
print("--- CustomNumber Instances ---")
num1 = CustomNumber(10)
num2 = CustomNumber(5)
num3 = CustomNumber(2.5)
print(f"num1: {num1}")
print(f"num2: {num2}")
print(f"num3: {num3}")

print("\n--- Basic Arithmetic Operations ---")
print(f"{num1} + {num2} = {num1 + num2}")
print(f"{num1} - {num2} = {num1 - num2}")
print(f"{num1} * {num2} = {num1 * num2}")
print(f"{num1} / {num2} = {num1 / num2}")

# --- Output ---
"""
--- CustomNumber Instances ---
num1: CustomNumber(10)
num2: CustomNumber(5)
num3: CustomNumber(2.5)

--- Basic Arithmetic Operations ---
CustomNumber(10) + CustomNumber(5) = CustomNumber(15)
CustomNumber(10) - CustomNumber(5) = CustomNumber(5)
CustomNumber(10) * CustomNumber(5) = CustomNumber(50)
CustomNumber(10) / CustomNumber(5) = CustomNumber(2.0)

"""

tp_as_sequence (PySequenceMethods * ) — Points to PySequenceMethod structure, this also has C functions like above that defines the behavior for object that act like sequences, meaning objects with ordered collections where elements can be accessed by an integer index. Python types such as lists , tuples and str are primarily rely on this protocol. For example, sq_length implements __len__ , which is used by the len() function, sq_item implements __getitem__ for integer indexing (ex: some_obj[0] ). This structure also defines many other operations for sequences, including those for mutable sequences ( __setitem__, __delitem__), and operations like concatenation and repetition.
tp_as_mapping (PyMappingMethods *) , directs to PyMappingMethods structure, and defines how the object behaves as a mapping, mapping is a collection where elements are accessed by arbitrary keys (like strings, numbers, or other hashable objects — most commonly the Python dict). Similar to sequences this also implements __len__ via mp_length (for mappings) and __getitem__ via mp_subscript ( for key based lookup ex: some_obj['key'] ), similarly this structure also defines operations for mappings, including those for mutable mappings (ex: some_obj['key'] = value, del some_obj['key'] )

Now we have more of these. I will simply list them here along with what they implement. You can always find more details about them individually, so I see no point in going through all of them. Hopefully, the above ones will give you enough idea of “Protocol Implementations.”

tp_hash (hashfunc): Implements the object's __hash__ method.
tp_call (ternaryfunc): Implements the object's __call__ method.
tp_iter (getiterfunc : Implements the object’s __iter__ method.
tp_iternext (iternextfunc): Implements an iterator's __next__ method.
tp_richcompare (richcmpfunc): Implements the "rich comparison" methods (__lt__, __le__, __eq__, __ne__, __gt__, __ge__)

B. Modifying Type Semantics (tp_flags)

The tp_flags field contains a bitmask of unsigned_long values that represent the meaning and behavior of the type. The bitmask offers a very lightweight and compact way to specify the semantics of a type and also lend itself to other optimizations. Since the semantics are in the form of a bitmask, the type can be very explicit about the behavior it is defining, this is a common C level pattern used to represent and manage things where there are many options, but not too many individual fields.

These are some quite interesting and relevant flags, including:

Py_TPFLAGS_HEAPTYPE: Indicates that the type object itself is allocated on the heap, characteristic of Python-defined classes.
Py_TPFLAGS_BASETYPE: Allows the type to be used as a base class for inheritance.
Py_TPFLAGS_HAVE_GC: Signals that the object supports garbage collection, implying the presence of tp_traverse and tp_clear slots.
Py_TPFLAGS_IMMUTABLETYPE: Marks the type as immutable, meaning its attributes cannot be set or deleted after creation.
Py_TPFLAGS_MANAGED_DICT / Py_TPFLAGS_MANAGED_WEAKREF: These flags indicate that the instance's __dict__ or weak references are managed by the CPython VM.

C. Object Lifecycle Management: Allocation, Initialization, and Deallocation Revisited

The lifecycle of a Python object is broken into distinct phases — allocation, initialization, finalization, and deallocation, all of which are controlled through specific slots in the PyTypeObject.

1.LifeCycle

Object Allocation: tp_new (newfunc) , this function is responsible for allocating a new instance, it corresponds to __new__() from Python and typically handles memory allocation and minimal setup (such as setting reference counts and type).

Cool fact is that although the name says “new”, tp_new isn’t always required to return a new object. In some cases like singletons or memoized (Memoization is an optimization technique that uses caching, probably for an entire new article in the future) patterns, it can return a reference to an existing object. This flexibility gives developers precise control over the object identity and instantiation behavior.

Okay, now if you happen to ask what a “singleton” is, it means that you will always get the exact same object no matter how many times you try to create new instances of it, for example None, True and False are such singletons, there’s only one for each of these. It’s a design pattern that restricts the instantiation of a class to a single object.

Object Initialization: tp_init (initproc) , so after tp_new above returns a valid object, tp_init is invoked to perform initialization step, this is where instance attributes are setup and constructor arguments are handled. Yup this is Python’s __init__()

The question came to my mind right away was that “why the separation of these two”, This clear separation means that tp_new decides which object to provide (a brand new one or an existing one, reused one), while tp_init then consistently handles setting up that object’s specific state. So it’s like imagine you have an pool full of objects, tp_new might just grab an object from the pool instead of allocating a fresh one, then the role of tp_init is that even if tp_new returns an existing object, it can still “reset” or rather “re-initialize” its state for its new purpose, therefore this whole separation allows for optimizations such as reusing existing objects while still running initialization logic conditionally.

Object Deallocation and Cleanup: tp_dealloc (destructor) , When an object’s reference count ( ob_refcnt) reaches zero, CPython calls tp_dealloc (Sounds familiar?, yes we discussed about this in 1-B section ). This function is responsible for releasing owned resources, other Python objects, buffers, file handles etc and finally deallocating the object’s memory by calling tp_free .

For non-GC types, tp_free is what usually set to PyObject_Del() . This is consistent with the rule that says: “an object should be deallocated using the same allocator used to create it.” If PyObject_New() was used for allocation, PyObject_Del() should be used to free it.

you will also occasionally see the pattern:

tp_free((PyObject *)self);
Py_DECREF(Py_TYPE(self));

This ensures the type object itself (if heap allocated) can be freed once all instances are gone, since it holds a reference to its type by default.

Raw Memory Release: *tp_free (freefunc) *, this is the actual function that frees the memory allocated for the object. Depending on the type’s GC status and memory model, this is typically:

PyObject_Del() — simple and for non-GC types
PyObject_GC_Del() — for objects managed by the cyclic garbage collector

this is called within the tp_dealloc as the final step of destruction.

Optional Finalizer: *tp_finalize (destructor) *, This slot corresponds to __del__() method in Python. If defined tp_finalize is called once before the object is destroyed either by the GC or right before the deallocation.

Since you can call this before an object gets destroyed, you could actually create a new reference to this object, essentially resurrecting the object. But this must be handled with care as it can interfere with deterministic cleanup processes.

Breaking Cycles: tp_clear (inquiry) , This is actually a part of the garbage collector’s cycle breaking phase. It is called specifically to clear references the object holds to other Python objects, especially in case of self referential or mutually referential structures. Note that this is not called by PyDECREF , and is only triggered when CPython’s cyclic GC detects a cycle.

2. Static vs. Heap — Allocated Types

CPython supports two primary ways of defining custom types, with tradeoffs in performance, flexibility and control.

Static Types

Defined as statically allocated PyTypeObject structs in C. These are initialized at module load time via PyTypeReady() and are typically immutable. Static types are more efficient due to lower overhead and are often used for core types or simple extensions.

No runtime customization
Limited to single inheritance
Excellent for performance critical or fixed layout types

Heap Types

Heap allocated types (indicated by Py_TPFLAGS_HEAPTYPE) are created dynamically using functions like PyType_FromSpec() . These match Python’s class model more closely. They are slightly more expensive to manage but are essential for flexibility in user defined classes or framework level abstractions.

Dynamic creation and modification
Full multiple inheritance
Support for metaclasses and descriptors

Finally, aah let’s get our hands dirty.

Code Example: A Minimal Custom Type in C

Don’t worry about setups and errors, as I told at the beginning of the article, you can open this https://colab.research.google.com/drive/1RfLUdQbQWDMxonA5Zidn4teNKxfLYQ6d?usp=sharing link on another tab and see the example in action. This will contain all the three examples that we will have in this article, check the first cell collection tab for this particular one.

If you want to run this on your own machine, the code is available as a GitHub gist as well, so simply download and compile: https://gist.github.com/RezSat/e23d767605c1caa44f48ac4db7548439

The following C code outlines a minimal custom type, SimpleObject. This type exposes a single integer member and provides a basic __repr__ method.

#define PY_SSIZE_T_CLEAN
#include <Python.h>
#include <stdio.h> // For PySys_WriteStdout

// 1. Define the instance structure (must start with PyObject_HEAD)
typedef struct {
    PyObject_HEAD
    long value; // Our custom data member
} SimpleObject;

// 2. Implement tp_dealloc: Frees the object's memory
static void
SimpleObject_dealloc(SimpleObject *self) {
    Py_TYPE(self)->tp_free((PyObject *)self); // Call the type's free function
}

// 3. Implement tp_repr: Provides string representation ( __repr__ )
static PyObject *
SimpleObject_repr(SimpleObject *self) {
    return PyUnicode_FromFormat("<SimpleObject value=%ld at %p>",
                                 self->value, (void *)self);
}

// 4. Implement tp_new: Creates new instances ( __new__ )
static PyObject *
SimpleObject_new(PyTypeObject *type, PyObject *args, PyObject *kwds) {
    SimpleObject *self;
    long initial_value = 0; // Default value

    // Parse optional initial value
    if (!PyArg_ParseTuple(args, "|l", &initial_value)) {
        return NULL;
    }

    // Allocate memory for the object
    self = (SimpleObject *)type->tp_alloc(type, 0);
    if (self == NULL) {
        return NULL;
    }

    // Initialize our custom member
    self->value = initial_value;
    return (PyObject *)self;
}

// 5. Define the PyTypeObject structure
static PyTypeObject SimpleType = {
    PyVarObject_HEAD_INIT(NULL, 0) // Initializes ob_refcnt and ob_type (set by PyType_Ready)
   .tp_name = "simple_module.SimpleObject", // Type name
   .tp_basicsize = sizeof(SimpleObject), // Size of instance
   .tp_dealloc = (destructor)SimpleObject_dealloc, // Deallocation function
   .tp_repr = (reprfunc)SimpleObject_repr, // Representation function
   .tp_flags = Py_TPFLAGS_DEFAULT | Py_TPFLAGS_BASETYPE, // Default flags, allow subclassing
   .tp_doc = "A simple custom object with an integer value.", // Docstring
   .tp_new = SimpleObject_new, // Object creation function
};

// ---
// Corrected Module method definitions
// Declare SimpleModuleMethods as an ARRAY of PyMethodDef
static PyMethodDef SimpleModuleMethods[] = {
    {NULL, NULL, 0, NULL} // Sentinel
};

// ---
// 7. Define module structure
static struct PyModuleDef simplemodule = {
    PyModuleDef_HEAD_INIT,
    "simple_module", // Module name
    "A module defining a simple custom object.", // Module docstring
    -1, // Size of per-interpreter state
    SimpleModuleMethods // Module methods (now correctly a pointer to the array)
};

// 8. Module initialization function
PyMODINIT_FUNC
PyInit_simple_module(void) {
    PyObject *m;

    // Finalize the type object
    if (PyType_Ready(&SimpleType) < 0) {
        return NULL;
    }

    // Create the module
    m = PyModule_Create(&simplemodule);
    if (m == NULL) {
        return NULL;
    }

    // Add the custom type to the module
    Py_INCREF(&SimpleType); // Add a strong reference for the module
    if (PyModule_AddObject(m, "SimpleObject", (PyObject *)&SimpleType) < 0) {
        Py_DECREF(&SimpleType); // Decrement if adding fails
        Py_DECREF(m);
        return NULL;
    }

    return m;
}

Compilation (Linux/macOS):

gcc -shared -fPIC -I/usr/include/python3.x -o simple_module.so simple_module.c (Replace python3.x with your Python version, ex: python3.10)

Python Usage:

import simple_module
obj1 = simple_module.SimpleObject(100)
print(obj1)
# Expected output: <SimpleObject value=100 at 0x...>
obj2 = simple_module.SimpleObject()
print(obj2)
# Expected output: <SimpleObject value=0 at 0x...>

Let this be a boilerplate for your next CPython custom type. And this marked the end of this main section, and I promise the next section in which we will have two more interactive examples will be the last main section of this article, (cough x2) before the Conclusion :).

4. Advanced Concepts (For me): OOP, GC, and Performance

A. Inheritance and Method Resolution in CPython

CPython’s object model provides a simple but powerful and fast means of inheritance, method dispatch and polymorphism at the C level. While this implementation is much simpler than Python’s high level multiple inheritance, this C layer is optimized for performance and resembles the dynamic behavior of Python with slot based mechanics and linearized resolution paths.

1. C-Level Inheritance: `tp_base` and `PyType_Ready()`

At the C level, inheritance is handled through the tp_base slot in the PyTypeObject struct. This pointer references the immediate base type from which the current type inherits.

Initialization is handled by PyType_Ready(). During this process, CPython does something called “ Inheritance-by-copy ”, if a slot in the new type is unset, the value of that slot is copied straight from the PyTypeObject of the base type. For instance, PyType_Ready() will copy tp_repr from its tp_base (typically PyBaseObject_Type ) if it is not defined in the new type.

This copy-based approach is a purposeful performance enhancement. CPython prevents recurrent lookups along the inheritance chain during regular operation by resolving and storing function pointers at initialization time. The drawback is that since the values were set at the time of creation, modifications made to a base type’s slots later on will not immediately affect C-defined subclasses that have already been initialized (since the values were fixed at the time of their creation).

2. Method Resolution Order (MRO): C3 Linearization

Earlier, when looking at attribute access ( 3-A-1 ) (tp_getattro), we saw that Python needs to decide where to look for an attribute. This section is all about that.

At C-level inheritance is single, however CPython supports Python’s multiple inheritance through Method Resolution Order (MRO). MRO is the exact order in which the classes are searched when resolving a method or attribute, especially in complex class hierarchies where ambiguity (like the diamond problem — search for the term it's an issue that is very simple to understand) may occur.

CPython uses the C3 linearization algorithm to compute this order. This algorithm ensures:

Monotonicity (subclasses adhere to the order of the base class)
Predictability (regardless of the order in which the method is defined, behavior is consistent)
Determinism (the same result for the same hierarchy)

The result is stored in the tp_mro slot as a Python tuple of class objects. This slot is not inherited instead it is computed from scratch during PyType_Read().

In python you can do below to inspect the mro:

MyClass. __mro__
MyClass.mro()

When an attribute is accessed, the lookup starts with tp_getattro function. Most user defined types have this slot set to PyObject_GenericGetAttr, which performs the actual traversal of the MRO chain stored in tp_mro

Let’s actually look at what happens internally during this attribute lookup:

First , Traverse the MRO

Second , look for below in each class’s dictionary( tp_dict ):

Data Descriptors ( tp_descr_get, tp_descr_set )
Method (from tp_methods )
Members ( tp_members)
Get/Set properties ( tp_getset )

Third , look into the instance's own __dict__, if and only if the attribute isn’t found in any class. If the attribute is still not found after this process, tp_getattro raises an AttributeError .

This entire mechanism is implemented with tight, low overhead C logic, and these tp_getattro , tp_mro , tp_dict and the descriptor protocol forms the very foundation of Python’s attribute resolution behavior that we all love and use.

3. Polymorphism at the C Level

Polymorphism as we all know is a very common concept used in Object Oriented Programming (OOP). Polymorphism in Python is achieved through two simple constructs which we already discussed, the ob_type field in every PyObject, and the slot-based design of PyTypeObject.

We already know that every Python object begins with a pointer to its type. This ob_type pointer acts as the dispatch table. Whenever Python needs to perform an operation like calling an object, printing it, or accessing an attribute it simply checks the relevant slot in the object’s type (ex: tp_call for calling an object, tp_getattro to get an attribute)

This means CPython does not need explicit type checks or casting to implement polymorphism. The behavior is resolved at the runtime based on the object’s type. Two completely unrelated types can both implement tp_len or tp_iter and the interpreter will correctly call the appropriate function based on ob_type.

Yes, it's essentially runtime polymorphism, but not implemented with C++ style virtual tables or class hierarchies rather in pure C with lean, predictable mechanism built directly into CPython’s object model. This slot dispatch design makes the system compact and extensible with high performance and is perfectly aligned with Python’s dynamic nature.

B. Garbage Collection: Tackling Reference Cycles

1. The problem of Reference Cycles

Reference counting is simple and efficient, however it cannot resolve circular references. A circular reference occurred when two or more objects hold references to each other in a closed loop. In such cases, the ob_refcnt of each object never reaches zero, even if there is no external references. This makes them permanently unreachable from the program but never freed from memory.

for example:

a = []
b = []
a.append(b)
b.append(a)

In here, a references b and b references a . Even if we delete both names with del a,b the two lists still keep each other alive, and their reference counts remain above zero effectively creating memory leaks.

These becomes really annoying in long running applications like servers, where memory leaks accumulate over time. Python therefore supplements reference counting with an additional mechanism which is called the “Cyclic Garbage Collector”.

2. CPython’s Cyclic Garbage Collector

This Cyclic Garbage Collector is implemented in Modules/gcmodule.c (The gc module in Python). The garbage collector unlike the reference counting ( which runs continuously and deterministically), operates periodically and focuses only on objects that are containers (lists, dictionaries, sets and user defined objects that form cycles)

Periodically, the GC scans these objects, looking for groups that only reference each other and when such groups are found and proven unreachable, they will be reclaimed.

This is done with a “generational” algorithm (means it organizes into three groups based on their “age” / “how long it was alive”):

Generation 0: Newly allocated container objects.

Generation 1: Objects that survived one collection.

Generation 2: Long lived survivors that survived multiple rounds.

Most of these objects die early, therefore Generation 0 is collected most frequently, while older generations are scanned less often to reduce overhead.

Now, if you’re thinking, “I don’t trust the defaults to manage my memory,” you’re in luck because Python actually lets you peek into and control these processes.

Working with the gc Module in Python

Forcing a collection

we can force an immediate garbage collection. This can be useful in memory constrained environments where you need to free up memory at some point.

import gc

#Force a full collection
gc.collect()

2. Checking for uncollectable objects

when gc can’t free objects that are part of a cycle, particularly if they have __del__ methods

import gc

# Force a collection
gc.collect()
# Lists objects that the GC could not free
print(gc.garbage)

3. Inspecting objects in memory

Checking list of objects that is currently being tracked by the gc

import gc

objs = gc.get_objects() #function returns a list of all objects

# Print the number of objects being tracked
print(f"Currently tracking {len(objs)} objects")

4. Disabling and Enabling the gc

Can be useful for debugging

import gc

# Disable the cyclic garbage collector
gc.disable()
# ... your code here ...
# Enable the cyclic garbage collector
gc.enable()

5. Tuning collection thresholds

This is a fun one, gc uses thresholds to determine when to run. We can inspect and adjust these value to fine tune the behavior of the collector. Thresholds represent the number of new allocation in each generation before a collection is triggered.

import gc

# (700, 10, 10) by default
print(gc.get_threshold())
# Adjust the collection thresholds
gc.set_threshold(1000, 15, 15)
# Print the current number of new objects in each generation
print(gc.get_count())

Getting your hands down to the gc module is really cool, and fine tuning these thresholds can help performance in workloads that create many short lived objects. Its not something most Python developers need every day, but could be useful when debugging memory leaks or working in specialized environments.

Reference Counting and Cyclic Garbage Collection format the very backbone of CPython’s memory management, its just beautiful.

C. Inspecting CPython Internals: Hands-On Examples

1. Code Example: Inspecting `PyObject` in C

Examples here can be seen and run as mentioned before using this link : https://colab.research.google.com/drive/1RfLUdQbQWDMxonA5Zidn4teNKxfLYQ6d?usp=sharing

To illustrate the fundamental PyObject structure and its accessible fields, consider the following C extension. This example creates a Python integer object and then inspects its internal ob_refcnt and ob_type->tp_name fields using the CPython API macros.

#define PY_SSIZE_T_CLEAN
#include <Python.h>
#include <stdio.h> // For PySys_WriteStdout

// Define a simple C function that creates a Python integer
// and prints its ob_refcnt and ob_type->tp_name
static PyObject*
inspect_int_object(PyObject *self, PyObject *args) {
    PyObject *py_int_obj;
    long value;

    // Parse arguments: expect a single long integer
    if (!PyArg_ParseTuple(args, "l", &value)) {
        return NULL; // Error occurred
    }

    // Create a Python integer object
    py_int_obj = PyLong_FromLong(value);
    if (py_int_obj == NULL) {
        return NULL; // Error creating object
    }

    // Access ob_refcnt and ob_type using macros
    Py_ssize_t ref_count = Py_REFCNT(py_int_obj);
    PyTypeObject *type_obj = Py_TYPE(py_int_obj);
    const char *type_name = type_obj->tp_name;

    // Print the information
    PySys_WriteStdout("Object: %ld\n", value);
    PySys_WriteStdout(" Reference Count: %zd\n", ref_count);
    PySys_WriteStdout(" Type Name: %s\n", type_name);

    // Decrement the reference count for the object we created
    // This is crucial for proper memory management.
    Py_DECREF(py_int_obj);

    Py_RETURN_NONE; // Return None (increments its refcount)
}

// Module method definitions
static PyMethodDef MyInspectMethods = {
    {"inspect_int", inspect_int_object, METH_VARARGS,
     "Inspects a Python integer object's internal PyObject fields."},
    {NULL, NULL, 0, NULL} // Sentinel
};

// Module definition structure for Python 3
static struct PyModuleDef inspectmodule = {
    PyModuleDef_HEAD_INIT,
    "inspect_internals", // Module name
    "A module to inspect CPython object internals.", // Module docstring
    -1, // Size of per-interpreter state of the module, -1 means global state
    MyInspectMethods // Module methods
};

// Module initialization function
PyMODINIT_FUNC
PyInit_inspect_internals(void) {
    return PyModule_Create(&inspectmodule);
}

Compilation (Linux/macOS):

gcc -shared -fPIC -I/usr/include/python3.x -o inspect_internals.so inspect_internals.c

(Replace python3.x with your Python version, e.g., python3.10)

Python Usage:

import inspect_internals
inspect_internals.inspect_int(42)
# Expected output (reference count may vary for small integers due to memoization):
# Object: 42
# Reference Count: 1 (or 2 if sys.getrefcount() is used, or higher for memoized small ints)
# Type Name: int

2. Low-Level Access with `ctypes` in Python

As an illustrative example, one can even use Python’s ctypes library to peek at an object’s header. Since id(obj) in CPython returns the memory address of the object, we can cast it to a ctypes pointer.

For instance:

import ctypes, sys
lst = []
# Get reference count from the object header:
refcnt = ctypes.c_ssize_t.from_address(id(lst)).value
print("C ctypes says refcount =", refcnt)
print("sys.getrefcount says refcount =", sys.getrefcount(lst))

Output:

C ctypes says refcount = 1
sys.getrefcount says refcount = 2

D. Performance Considerations and Common Pitfalls

Unlike working at Python level, when working with CPython’s internals like through C extensions, developers have to deal with performace trade offs and memory management issues.

1. GIL’s Role in Reference Counting and Thread Safety

Global Interpreter Lock or GIL for short is a process-wide mutex ensuring that ony one thread executes Python bytecode at any given time. Its main role is to protect shared internal data structures, most notably the ob_refcnt field of every Python object.

If not for GIL, each Py_INCREF and Py_DECREF would require atomic instructions or fine-grained locks across millions of objects, which will add immense complexity and runtime cost. The GIL therefore represents a deliberate engineering choice which is to sacrifice parallelism in exchange for simplicity and robustness of the memory model.

2. Impact on Concurrency and CPU-Bound tasks

Because of the GIL, Python threads cannot achieve true multi-core parallelism for CPU bound tasks, even on a 32 core machine, only one thread can run bytecode at a time.

But this limitation is somewhat less severe for I/O bound workloads. The interpreter releases the GIL during blocking I/O (network, disk, sockets), allowing other threads to make progress, this is why multi-threading remains viable for I/O concurrency in Python, even if it underperforms for CPU-heavy tasks.

So in practice:

CPU bound work — use multiprocessing or C extensions
I/O bound work — multi threading will work fine.

3. The Road Ahead: PEP 703 and No-GIL CPython

Python is now introducing an experimental no-GIL build, it requires a deep re-engineering of CPython’s internals.

There experimenting on some techniques to move the interpreter from GIL’s bruteforce simplicity towards a scalable, multi-core aware memory model but without breaking the semantics of billions of lines of python code.

4. Reference Leaks vs Reference Deficits

Two of the most common failure modes are reference leaks and reference deficits, which we discussed roughly in above chapters

Reference Surplus (Leak): Forgetting to Py_DECREF an owned reference. The object stays alive forever, and long running processes slowly balloon in memory. Often silent and insidious.
Reference Deficit (Premature Free): Calling Py_DECREF too often. The object is deallocated too early, leading to ‘use-after-free’ bugs and segmentation faults. These are explosive and harder to debug, as the crash may occur far away from the original mistake.

Best Practices or C API Memory Management

When writing extensions, a strict discipline is essential.

Respect Ownership Semantics: Always check if a function returns a new reference (you own it) or a borrowed reference (you don’t). This is the single most important rule.
Error Handling Discipline: On error, functions usually return NULL but may have created intermediate objects. Clean them up properly before returning.
Helper Macros Save Lives: Use Py_XINCREF , Py_XDECREF , Py_NewRef , Py_CLEAR and Py_SETREF . These are not optional style points, they encode decades of hard-earned safety patterns.
Weak References: Use weakrefs ( Py_TPFLAGS_MANAGED_WEAKREF, PyObject_ClearWeakRefs ) for cache like structures that should not prevent GC.
Container Hygiene: If you implement container types in C, adjust the refcounts of contained elements meticulously.

Conclusion

So, what to take from all of this? CPython’s object model might look intimidating at first glance, but once you peel back the layers it’s actually a very neat system. Everything can be explained in few consistent ideas: objects carry their own type and reference count, types describe behavior through slots, and reference management ensures memory stays in check.

Whether you’re just curious, writing a C extension or thinking about contributing for CPython itself, understanding these internals gives you a whole new perspective on Python.

At the end of the day, you don’t need to memorize every slot or flag. What matters is grasping the philosophy; Python’s flexibility at the surface is built on a surprisingly strict, predictable C core. Once you know these, you can write better Python code, debug smarter and maybe even push the language forward yourself.

Yup, that marks the end of this article. Took me about a month to write, hope it gives you something useful :).

Swapping Variables in Python: Behind the scenes of a,b = b,a

Yehan Wasura — Wed, 28 May 2025 20:49:18 +0000

Swapping two variables in Python with a,b = b,a is a common idiom, used in memes comparing other languages to Python, but it often mystifies beginners who think it's "magic". There is even a common misconception of Python uses temporary variables to achieve this under the hood, while that can be a rough idea that's not the complete truth.

It’s just regular tuple packing and unpacking in Python.

The right-hand side b, a is an expression list that is evaluated into a tuple (b, a), and then that tuple is unpacked into the targets a and b on the left. This multiple-assignment is defined in the Python language reference: “an assignment statement evaluates the expression list (which can be a comma-separated list yielding a tuple) and assigns the single resulting object to each of the target lists, from left to right” 1. In other words, Python first evaluates the entire right side (in this case building a tuple (b,a)), then assigns its elements to a and b in order. This eliminates the risk of one variable clobbering the other during assignment.

In practical terms, one can think of a, b = b, a as roughly equivalent to:

tmp = (b, a) # pack into a temporary tuple 
a, b = tmp # unpack into a and b

It’s important to note that this is an assignment statement , not an expression, so it doesn’t “return” a value (a function performing the swap returns None 2). Also, the evaluation order is well-defined: Python first evaluates b then a, packs them into a tuple, and then performs the left-to-right assignment into a and b 1 3. This left-to-right rule is guaranteed by the language, so the swap is unambiguous and does not depend on evaluation order surprises.

Python Tuple Packing and Unpacking

At a high level, a, b = b, a works because Python supports packing multiple values into a tuple and unpacking them. In a, b = b, a, the right-hand side is a tuple expression (parentheses are optional) whose two elements are b and a. Python evaluates b and a, creating a new tuple object (b, a). Then the left-hand side sees that the target list a, b is also two names, so it unpacks that tuple: the first element is assigned to a and the second to b. For example:

x, y = y, x

is parsed as if Python did tmp = (y, x) then unpacked a, b = tmp. The language reference explicitly calls this “tuple unpacking”: “a comma-separated list [on the right] yields a tuple” which is then distributed to the variables on the left. 1

This also means that the expressions on the right are evaluated before any assignment happens. So even if you wrote something like a, b = b, some_function(a), Python computes both b and some_function(a) first, then assigns to a and b respectively. This is why you won’t mistakenly use an old or overwritten value – it’s all computed up front in tuple form. In our swap case, both b and a are read before writing to either variable, so the swap is “atomic” in behaviour.

CPython Implementation: Bytecode and Stack Operations

Under the hood, CPython translates a, b = b, a into bytecode that uses the evaluation stack. For example, disassembling a simple function shows how CPython does a two-variable swap 4:

>>> import dis
>>> def swap(a, b):
... a, b = b, a
... 
>>> dis.dis(swap)
  2 0 LOAD_FAST 1 (b)
              3 LOAD_FAST 0 (a)
              6 ROT_TWO
              7 STORE_FAST 0 (a)
             10 STORE_FAST 1 (b)
             13 LOAD_CONST 0 (None)
             16 RETURN_VALUE

Here’s what happens step by step:

LOAD_FAST 1 (b) pushes the value of b onto the Python stack.
LOAD_FAST 0 (a) then pushes the original value of a on top of that. Now the stack has b, a.
The ROT_TWO opcode swaps these top two stack items. After ROT_TWO, the stack has [a, b] on top.
STORE_FAST 0 (a) pops the top of stack (which is the original b) and stores it in a. Internally this does something like value = POP(); SETLOCAL(a, value).
STORE_FAST 1 (b) pops the next item (original a) and stores it in b. After these two stores, a has the old b and b has the old a.

(The final LOAD_CONST/RETURN_VALUE just returns None since the function has no return.)

The key opcodes are LOAD_FAST , ROT_TWO , and STORE_FAST. By definition, ROT_TWO “swaps the two top-most stack items” 5, so it does exactly the swap on the two values without creating any new Python objects. Neither LOAD_FAST nor STORE_FAST creates tuples – they work with references. Internally, LOAD_FAST n fetches the local variable slot n, increments its reference count, and pushes the object onto the stack. Conversely, STORE_FAST n pops one item from the stack and stores it into local slot n, decrementing the old value’s reference count if necessary.

In C, the ceval.c interpreter code for these opcodes looks roughly like:

// Python/ceval.c pseudocode for LOAD_FAST
PyObject *value = GETLOCAL(oparg); // get local var
if (value == NULL) { throw UnboundLocalError }
Py_INCREF(value); // increment refcount
PUSH(value); // push onto value stack
// ... later, for STORE_FAST:
PyObject *value = POP(); // pop top of stack
SETLOCAL(oparg, value); // store into localsplus array
// (SETLOCAL does Py_XDECREF on old value):contentReference[oaicite:7]{index=7}:contentReference[oaicite:8]{index=8}

6 7 The SETLOCAL(i,value) macro (used by STORE_FAST) does something like: save the old local to a temp, write the new value into the local slot, then Py_XDECREF the old value 7. This handles reference-count bookkeeping for you. Notice that during this swap, CPython only incremented and decremented reference counts of the objects a and b; it did not create any new tuple object at runtime for the 2-variable case. The ROT_TWO bytecode simply shuffled references on the stack without allocation.

For three-variable swaps (a, b, c = c, b, a), CPython similarly uses LOAD_FAST three times followed by ROT_THREE and ROT_TWO to cyclically rotate the top three stack items, then STORE_FAST thrice 8 9. No tuple is created there either. In fact, for 2- or 3-item assignments, CPython’s peephole optimizer specially replaces the generic tuple-build-and-unpack sequence with these more efficient stack-rotate ops 10.

However, once you swap 4 or more variables, CPython falls back to a less-optimized method. For example, consider:

d, c, b, a = a, b, c, d

Disassembling shows that CPython will LOAD_FAST each of the four values onto the stack, then call BUILD_TUPLE 4 and UNPACK_SEQUENCE 4 11:

0 LOAD_FAST 3 (d)
 3 LOAD_FAST 2 (c)
 6 LOAD_FAST 1 (b)
 9 LOAD_FAST 0 (a)
12 BUILD_TUPLE 4 # creates a 4-tuple (a,b,c,d)
15 UNPACK_SEQUENCE 4 # pops that tuple and pushes elements for assignment
18 STORE_FAST 0 (a)
21 STORE_FAST 1 (b)
24 STORE_FAST 2 (c)
27 STORE_FAST 3 (d)

That creates a temporary 4-tuple under the hood, then immediately unpacks it into d, c, b, a. (This is more “wasteful,” but CPython’s rule is to use the generic tuple-unpacking logic for 4+ items. The 2- and 3-item cases are optimized by a special peephole as mentioned 10 11.)

How Other Languages Swap

By way of comparison, other languages handle swapping differently:

C (using a temporary). In C you typically swap two variables with an extra variable. For example:

int temp = a;
a = b;
b = temp;

— This is straightforward and compiles down to a few machine instructions. (See e.g. this example 12.) There are clever tricks like XOR-swap or arithmetic-swap, but they aren’t used in high-level C code as often. The key point is C always needs a temporary storage (or analogous trick) at the source level; it doesn’t have tuple assignments.

C++ (std::swap). C++ provides std::swap(a, b). In generic C++03 form, it’s essentially implemented as:

T temp(a); // copy-construct
a = b; // assign
b = temp; // assign

In C++11 and later, it often uses move semantics:

T temp = std::move(a); 
a = std::move(b); 
b = std::move(temp);

— (Specialized types like containers may implement swap by just swapping pointers internally for efficiency.) In any case, std::swap typically compiles to a few assignments or moves – very low-level operations. The above template-based implementations are documented in StackOverflow answers 13 14. Because it’s compiled code with primitive operations (and often inlined), C++ swaps are extremely fast.

Java (pass-by-value semantics). Java has no tuple-unpacking or pointer-swap. Variables of primitive types must be swapped with a temp variable just as in C. For objects, it’s more subtle: Java method parameters are pass-by-value, meaning swapping two object references inside a function won’t affect the caller’s variables 15. For example:

// This DOES NOT swap caller's variables:
void swap(Object x, Object y) {
    Object temp = x;
    x = y;
    y = temp;
}jav

— After calling swap(a, b), the original a and b in the caller are unchanged 15. To swap in Java, you must swap in the caller’s scope, usually with a temporary variable. If you want a true “swap method,” you’d need to pass mutable holders (e.g. an array or a custom pair) or use some wrapper, since Java’s semantics won’t swap two separate variables directly. In practice, a Java programmer would simply do:

int temp = a;
a = b;
b = temp;

— The key point from 15 is that Java parameters are always passed by value , so you can’t write a swap utility that swaps two outside variables without returning new values or using mutable holders.

JavaScript (ES6 destructuring). Modern JS supports array destructuring for swapping. For example:

let a = 1, b = 3;
[a, b] = [b, a];
console.log(a, b); // 3 1

— This looks similar to Python. Under the hood, the JS engine first evaluates the right-hand side expression [b, a], which creates a new array, then destructures it into a and b. (It’s exactly analogous to a tuple: a temporary array [b,a] is built, then unpacked.) As one StackOverflow answer notes, it does create an array as a temporary value 16 – just with no explicit variable name for it. So JavaScript swapping via destructuring is syntactic sugar over the same concept. Without destructuring, you’d swap in JS like in C: with a temporary variable or another trick. The MDN docs also confirm that destructuring can swap variables and that without it you’d need a temp 17 18 .

A Rough Comparison of Performance and Memory

In terms of efficiency, Python’s tuple swap has a bit more overhead than a low-level swap in C/C++. In CPython, each LOAD_FAST and STORE_FAST involves C-level work (array access, reference counting, etc.) 6 7. For two variables, Python’s swap uses 2 loads + 1 rotate + 2 stores. That’s a handful of bytecode ops and reference count increments/decrements, all interpreted. By contrast, a C++ swap is a few machine instructions in optimized code. As one answer notes, “C++ would likely be much faster” than CPython’s version because C++ is compiled and optimized 19.

For a concrete sense of scale, a quick microbenchmark on typical hardware shows roughly a 4–5× speed advantage for C++ over CPython for raw variable swaps. For example, doing 10 million swaps of two integers took about 0.18 seconds in CPython 3.11 (≈18 ns per swap) versus about 0.04 seconds in optimized C++ (≈4 ns per swap) in our test. (Your mileage will vary by machine and Python version, but C/C++ are clearly lower-level and faster.) JavaScript’s destructuring requires allocating a small array each time, so it’s also slower than native C-level swaps (and incurs an array allocation and GC overhead per swap). All these differences mainly come from interpreter overhead, dynamic typing, and memory allocation.

Memory-wise, for the common 2-variable swap Python doesn’t actually allocate a tuple object (thanks to the ROT_TWO peephole), so it only bumps reference counts on the existing objects. For 3 or fewer, CPython uses no tuple allocation 10. In JS, swapping does allocate a 2-element array as a temporary 16 (though it’s usually optimized). In Python, if you ever swapped 4+ variables, a new tuple would be allocated as we saw. In contrast, C and C++ do their swaps entirely in registers/stack, no heap allocation. So from a memory standpoint, the Python approach is O(1) extra space (for 2-3 items) aside from transient stack slots, while JS destructuring uses a tiny array.

Compilers and runtimes do optimize these idioms. Python’s peephole optimizer replaces a general tuple build/unpack with ROT_TWO/THREE for 2–3 items 10. C++ compilers often inline and optimize std::swap. Java compilers/JIT will optimize the simple three-assign swap into the minimal moves. So in practice, each language handles the common swap idiom in the most efficient way it can given its semantics. But across languages, C/C++ will always have the edge in raw speed and minimal overhead, while Python and JavaScript trades a bit of performance for syntactic convenience and flexibility.

Parsing and AST Perspective

When Python parses a, b = b, a, it produces an AST Assign node whose target is a Tuple of two names and whose value is a Tuple of two expressions. For example, ast.parse("a, b = b, a") yields something like:

Assign(
  targets=[Tuple(elts=[Name('a'), Name('b')], ctx=Store())],
  value=Tuple(elts=[Name('b'), Name('a')], ctx=Load())
)

This reflects that the parser recognizes the comma-separated lists and builds tuple AST nodes. The parser does not do the swap at parse time — it merely sets up the tree. All the work happens at runtime during bytecode execution as described above. For novices, it’s helpful to know that the syntax a, b = b, a is just grammar for tuple assignment (the grammar calls the right side an “expression list” and the left side a “target list”) 1. In other words, even though we often say “tuple packing/unpacking,” in code the parentheses can be omitted. The parser effectively treats b, a as if it were (b, a).

Intuition and Takeaways

At the end of the day, a, b = b, a is syntactic sugar for what amounts to a three-step swap : evaluate the right-hand tuple, then unpack it into the left variables. No truly “mystical” mechanism is needed beyond understanding tuple assignment. Under the hood, CPython cleverly uses stack operations (LOAD_FAST, ROT_TWO, STORE_FAST) to perform the swap without an extra temp object in the 2-variable case 4 6. But conceptually, it’s the same idea as manually using a temporary variable.

Every programmer should internalize this pattern: it’s just multiple assignment. This insight prevents confusion and helps in other contexts (e.g. swapping list elements [i], [j] = [j], [i], or unpacking function results). Remember that Python guarantees right-hand evaluation first and left-to-right assignment 1, so the swap won’t corrupt values. Finally, if you ever peek at Python’s bytecode or C implementation, you’ll see it’s surprisingly straightforward – a few load, swap, and store instructions – not some hidden magic.

Key Takeaway: Python’s a, b = b, a is simply tuple unpacking with guaranteed order. It’s efficient for 2-3 values due to special bytecode (ROT_TWO/ROT_THREE) 5 10 , but it’s still doing a small sequence of operations (with reference-count overhead) under the hood. In languages like C/C++ or JavaScript, similar swaps either use a temporary or destructure an array. Understanding this at a low level just means realizing it’s a language feature (tuple assignment) backed by obvious VM steps, not a mysterious one-off hack.

Sources:

Python’s reference manual and bytecode docs 1 5; CPython bytecode analysis 4 6 7; C/C++ swap examples 12 13 14; Java pass-by-value discussion 15; JS destructuring docs and Q&A 17 16. These illustrate the mechanics in each context.

[1] 7. Simple statements — Python 3.13.3 documentation

[2] [4] [8] [10] python - How does swapping of members in tuples (a,b)=(b,a) work internally? - Stack Overflow

[3] Is python tuple assignment order fixed? - Stack Overflow

[5] 32.12. dis — Disassembler for Python bytecode — Python 3.5.10 documentation

[6] [python internal] From Python to Bytecode until C - Nutshell

[7] droettboom.com

[9] [11] [19] a,b = b,a in python vs std::swap() in C++ - Stack Overflow

[12] C Program to Swap Two Numbers | GeeksforGeeks

[13] [14] c++ - How does std::swap work in terms of constructors, assignment operators, and destructors?- Stack Overflow

[15] Java is Pass by Value, Not Pass by Reference | DigitalOcean

[16] javascript - why Array Destructuring can swap two variables without temperory variable - Stack Overflow

[17] [18] Destructuring - JavaScript | MDN

7 (Well, 6) Fun Python Easter Eggs You Didn’t Know About

Yehan Wasura — Sun, 17 Nov 2024 15:24:27 +0000

Python is not just a powerful programming language; it also has a playful side. Hidden within its syntax and libraries are a variety of Easter eggs that can bring a smile to your face or surprise you with their cleverness. Here’s a compilation of 7 { well 6 if you read well :) } delightful Python Easter eggs that you might not be aware of.

1. The Zen of Python

One of the most famous Easter eggs in Python is "The Zen of Python," which is a collection of guiding principles for writing Python programs. You can access it by typing the following command in a Python interpreter:


import this

This will display a poem that emphasizes simplicity, readability, and the importance of explicitness in coding.

2. The Python "import antigravity"

If you want to experience a bit of levity, you can import the antigravity module. This Easter egg is a reference to a classic comic strip from the webcomic "xkcd." To see it, simply run:


import antigravity

This will open a web browser and take you to the xkcd comic titled Python.

3. The "Hello, World!" in Different Languages

Python has a built-in module that can greet you in a fun and quirky way. You can access it by importing the __hello__ module:


import __hello__

This will print Hello world! in a playful manner.

4. The "import this" Poem

While we already mentioned "The Zen of Python," it’s worth noting that it’s not just a set of principles; it’s also a clever poem. The lines are witty and insightful, making it a delightful read for any Python enthusiast.

5. The "from future import braces"

This is a classic Python joke. If you try to run the following command:


from __future__ import braces

You’ll receive a SyntaxError with the message "not a chance." This humorous nod underscores Python's commitment to using indentation, not braces, for block delimiters.

6. The "import this" with a Twist

If you want to see a slightly different version of "The Zen of Python," you can use the __future__ module to import it in an unconventional way:


from __future__ import print_function

While this won’t change the output, it’s a fun way to explore the __future__ module.

7. The "import phello.foo"

This Easter egg is a playful reference to the "Hello, World!" program. You can access it by running:


import __phello__.foo

This will print Hello, world! in a quirky way, showcasing Python's sense of humor.

Python is not just a language for serious programming; it also has a whimsical side that can bring joy to developers. These Easter eggs are a testament to the creativity and humor of the Python community. So the next time you’re coding in Python, take a moment to explore these hidden gems and enjoy the lighter side of programming!

XSS Treasure Hunt: Unearthing Vulnerabilities with Google Dorks — Day 1

Yehan Wasura — Sun, 31 Mar 2024 21:46:56 +0000

XSS Treasure Hunt: Unearthing Vulnerabilities with Google Dorks

Forget the tedious technical jargon; let’s dive straight into the XSS treasure hunt using the magnificent power of Google dorks. Picture this: instead of sweating bullets over bug bounty platforms for hours on end, why not kick back, relax, and let Google dorks do the heavy lifting? After all, who doesn’t love a good ol’ vulnerability scavenger hunt?

So, armed with curiosity and a cup of coffee, I ventured into the wild realms of the Google Hacking Database (GHDB) — Google Dorks, OSINT, Recon (exploit-db.com). After a few clicks, I settled on a random gem: “inurl:php?id=1 site:com”

Now, it’s as simple as googling: inurl:php?id=1 site:com, and voilà! The journey begins.

I fired up my terminal with XSStrike, ready to unleash chaos upon unsuspecting websites. Of course, not every site that popped up was ripe for the XSS plucking, but that’s all part of the thrill, isn’t it? Persistence pays off, and lo and behold, there it was, nestled among the search results like a hidden gem: https://www.transpakcorp.com/company.php?id=752.

With a gleam in my eye and fingers at the ready, I delved into the site and, as expected, stumbled upon the elusive search box. Without hesitation, I unleashed XSStrike upon it, like a modern-day pirate seeking treasure.

Search Endpoint: https://www.transpakcorp.com/search.php?q=

XSStrike Command:

python3 xsstrike.py — blind -u https://www.transpakcorp.com/search.php?q=

Results on terminal:


        XSStrike v3.1.5

[~] Checking for DOM vulnerabilities
[+] WAF Status: Offline
[!] Testing parameter: q
[!] Reflections found: 3
[~] Analysing reflections
[~] Generating payloads
[!] Payloads generated: 9240
------------------------------------------------------------
[+] Payload: <HTml%09oNmOusEOveR%0a=%0aconfirm()%0dx//
[!] Efficiency: 94
[!] Confidence: 10
------------------------------------------------------------
[+] Payload: <dETaILs%09ONToGGle%09=%09confirm()>
[!] Efficiency: 100
[!] Confidence: 10
[?] Would you like to continue scanning? [y/N]

so, I tried that:

https://www.transpakcorp.com/search.php?q=%3CdETaILs%09ONToGGle%09=%09confirm()%3E

Behold, the payload’s handiwork — a tantalizing “details” option.

Clickety-click, and bam! The confirmation pops up like a surprise party.

And thus, my friends, a tradition is born. Every day, or perhaps every once in a while, I embark on this whimsical journey — not for fame or fortune, but for the sheer joy of the hunt. Sure, it may not line my pockets with gold, and it’s probably not entirely legal (let’s keep that between us, shall we?), but hey, it’s one heck of a warm-up routine.

So here’s to the thrill-seekers, the curious souls, and the slightly reckless adventurers. May your exploits be daring, your payloads be potent, and your days be filled with wonder and laughter. Cheers to the XSS treasure hunt, and may the odds be ever in our favor. Stay curious, my friends, and remember: always hack responsibly.

DEV Community: Yehan Wasura

I Turned an EXE Into Music (and it actually tells you something)

What this is (and what it isn’t)

The core idea: “Byte Texture” in small windows

Turning those features into sound (aka: I made bytes sing)

The PNG “fingerprint” dashboard

The GUI: because CLI is cool, but watching and clicking is fun

How to try it

Fun experiments (try these if you want your brain to do the “Oh??” thing)

Why I built this (really?)

The Truth About Python’s Truthiness

What in the world is Truthy?

Truthy and Falsy in Python

Falsy Values (Exceptions)

Truthy Values (Everything Else)

So, what is the right way to write our original intention?

Languages where “truthiness / falsiness” is built in (non-boolean values allowed in conditionals)

Languages where truthiness is not allowed or is very limited

What these language comparison tells us is that,

CPython Object Model and Reference Counting — Trying to make sense of PyObject and PyTypeObject

CPython Object Model and Reference Counting — Trying to make sense of PyObject and PyTypeObject

Why should anyone care about this?

1. The Base: PyObject/PyVarObject and Memory Management

A. The Heart of Everything: PyObject/PyVarObject and PyObject_HEAD/PyObject_VAR_HEAD

B. Core Memory Management: Reference Counting

2. The Link to Behavior: “ob_type“ and the “PyTypeObject” Blueprint

A. The Link to Type Information

B. The Comprehensive Behavioral Blueprint (An Introduction to PyTypeObject)

3. Deep into PyTypeObject — Structure, Semantics and LifeCycle

A. The “tp slots”: A Comprehensive Look at Type Behavior

1. Core Identity and Layout

2. Attribute Access

3. Protocol Implementations

B. Modifying Type Semantics (tp_flags)

C. Object Lifecycle Management: Allocation, Initialization, and Deallocation Revisited

1.LifeCycle

2. Static vs. Heap — Allocated Types

Code Example: A Minimal Custom Type in C

4. Advanced Concepts (For me): OOP, GC, and Performance

A. Inheritance and Method Resolution in CPython

1. C-Level Inheritance: tp_base and PyType_Ready()

2. Method Resolution Order (MRO): C3 Linearization

3. Polymorphism at the C Level

B. Garbage Collection: Tackling Reference Cycles

1. The problem of Reference Cycles

2. CPython’s Cyclic Garbage Collector

Working with the gc Module in Python

C. Inspecting CPython Internals: Hands-On Examples

1. Code Example: Inspecting PyObject in C

2. Low-Level Access with ctypes in Python

D. Performance Considerations and Common Pitfalls

1. GIL’s Role in Reference Counting and Thread Safety

2. Impact on Concurrency and CPU-Bound tasks

3. The Road Ahead: PEP 703 and No-GIL CPython

4. Reference Leaks vs Reference Deficits

Best Practices or C API Memory Management

Conclusion

Swapping Variables in Python: Behind the scenes of a,b = b,a

It’s just regular tuple packing and unpacking in Python.

Python Tuple Packing and Unpacking

CPython Implementation: Bytecode and Stack Operations

How Other Languages Swap

A Rough Comparison of Performance and Memory

Parsing and AST Perspective

Intuition and Takeaways

Sources:

7 (Well, 6) Fun Python Easter Eggs You Didn’t Know About

1. The Zen of Python

2. The Python "import antigravity"

3. The "Hello, World!" in Different Languages

4. The "import this" Poem

5. The "from future import braces"

6. The "import this" with a Twist

7. The "import phello.foo"

XSS Treasure Hunt: Unearthing Vulnerabilities with Google Dorks — Day 1

XSS Treasure Hunt: Unearthing Vulnerabilities with Google Dorks

1. C-Level Inheritance: `tp_base` and `PyType_Ready()`

1. Code Example: Inspecting `PyObject` in C

2. Low-Level Access with `ctypes` in Python