tag

#development

10 pages tagged

Deep Reads › CPython Internals › 9. Development Workflow ›

85. Sanitizers

85. Sanitizers Sanitizers are compiler instrumentation tools that detect low-level C and C++ defects at runtime. They are especially useful for CPython development because CPython is a large C program with manual memory management, custom allocators, platform-specific code paths, and many extension-module boundaries. A debug build catches CPython invariant violations. Sanitizers catch classes of C undefined behavior that may survive ordinary assertions. 85.1 What Sanitizers Detect Sanitizers insert checks into...
cpython python internals development
Deep Reads › CPython Internals › 9. Development Workflow ›

82. Running the Test Suite

82. Running the Test Suite The CPython test suite is one of the most important parts of the project. It protects language semantics, runtime behavior, standard library correctness, ABI stability, memory management invariants, and platform compatibility across operating systems and architectures. A CPython contributor spends a large amount of time inside the test system. Even small changes to parser logic, object lifetime handling, reference counting, imports, or threading can break...
cpython python internals development
Deep Reads › CPython Internals › 9. Development Workflow ›

83. Debug Builds

83. Debug Builds A CPython debug build is a development build of the interpreter with extra runtime checks enabled. It is slower than a normal release build, but it exposes bugs that would otherwise appear as random crashes, memory corruption, reference leaks, or undefined behavior. Debug builds are used when modifying CPython itself, writing C extensions, investigating object lifetime bugs, or validating changes to the runtime. 83.1 What a Debug...
cpython python internals development
Deep Reads › CPython Internals › 9. Development Workflow ›

87. Writing Core Tests

87. Writing Core Tests Core tests in CPython are regression tests for the interpreter, the standard library, and the C API. They are written to protect behavior that CPython promises to users, extension authors, and downstream distributors. A good CPython test is small, deterministic, isolated, and directly connected to a specific behavior. It should fail before the fix and pass after the fix. It should avoid timing assumptions, external services,...
cpython python internals development
Deep Reads › CPython Internals › 9. Development Workflow ›

86. Tracing Memory Bugs

86. Tracing Memory Bugs Memory bugs in CPython are difficult because the visible failure often happens far away from the original mistake. A missing Py_INCREF , an extra Py_DECREF , a wrong allocator call, or an incomplete GC traversal may corrupt state silently. The crash may appear thousands of bytecode instructions later. Tracing memory bugs means reconstructing object lifetime: where an object was allocated, who owns it, when its reference...
cpython python internals development
Deep Reads › CPython Internals › 9. Development Workflow ›

90. Reading PEPs

90. Reading PEPs A Python Enhancement Proposal, or PEP, is a design document for a significant change to Python. PEPs describe language changes, standard library changes, process rules, compatibility policy, governance, release schedules, and implementation plans. For CPython internals work, PEPs matter because many implementation choices exist to satisfy a design accepted years earlier. Reading only the C code often shows what CPython does. Reading the PEP explains why it...
cpython python internals development
Deep Reads › CPython Internals › 9. Development Workflow ›

84. GDB and LLDB

84. GDB and LLDB Native debuggers are essential when working on CPython internals. Python-level tools can show frames, variables, exceptions, and source lines, but they cannot fully explain crashes inside the C runtime. When a bug involves reference counts, object layout, frame state, memory corruption, invalid pointers, or C extension behavior, you need a native debugger. On Linux, CPython developers usually use GDB. On macOS, LLDB is common. Both can...
cpython python internals development
Deep Reads › CPython Internals › 9. Development Workflow ›

89. Making a CPython Patch

89. Making a CPython Patch A CPython patch is a coordinated change to the interpreter, runtime, standard library, tests, documentation, and development metadata. Even a small fix may affect object lifetime, bytecode behavior, platform compatibility, import state, or public APIs. Making a good CPython patch requires more than changing code. The patch must preserve runtime invariants, include regression tests, follow repository conventions, build correctly across platforms, and explain user-visible behavior...
cpython python internals development
Deep Reads › CPython Internals › 9. Development Workflow ›

88. Documentation Workflow

88. Documentation Workflow CPython documentation is part of the implementation. It describes the language, the standard library, the C API, command-line behavior, build configuration, and development process. A CPython change is incomplete when the behavior changes but the documentation still describes the old behavior. The documentation is maintained in the CPython repository, reviewed with code changes, built locally by contributors, and published for Python users and extension authors. 88.1 Where...
cpython python internals development
Deep Reads › CPython Internals › 9. Development Workflow ›

91. Release Process

91. Release Process The CPython release process turns the development branch into a stable Python version. It covers feature planning, branch management, release candidates, build artifacts, documentation publication, security updates, maintenance releases, and end-of-life policy. A release is not just a Git tag. It is a coordinated handoff from development to users, distributors, package maintainers, platform vendors, and downstream projects. 91.1 Why the Release Process Matters CPython is the reference...
cpython python internals development