Python

The registry row this page is generated from

Read at render time from the same family row the register reads, so nothing in this block can disagree with it.

Extensions

.py, .pyw, .pyi

Registry names

python

Recorded symbols

functions · classes · methods · types

Relationship types this analyzer constructs

11 of 14 constructed, read from this analyzer's source and re-derived by the languages gate. Each row below is one of the engine's types, in the engine's own order.

11 constructed, 3 not constructed. All 3 absent types are recorded as ruled absent: the written reason and the corpus measurement behind each are in this family's completeness record. The register explains what each label means.

What this analyzer does not resolve

• Builtins are excluded from the call graph on purpose: a builtin is a call into the interpreter, not a node in the repository. The same rule drops every __dunder__ call.
• A callee that is not a plain name or an attribute names nothing statically, so (f if flag else g)(), FACTORIES[k](x) and f()() all record nothing — a fallback to the first child node was removed because it produced fabrications.
• A decorator call is never a call edge, and a def nested inside another function publishes no symbol at all: its body is attributed to the enclosing function, because a local function is a scope, not a declaration.

Every line above was written against Python’s own analyzer module and is named against a construct in it, so it can be checked against the source. Nothing here is inherited from a template, or from another language’s page.

Where you meet it in a repository

Recognised by extension — .py, .pyw, .pyi. Everything below is about where those files actually sit in a working repository.

• __init__.py marks a package, so a bare import utils inside one is relative to the importing file — the same name can mean different modules in different directories.
• Framework code is mostly inheritance: models, views and serializers subclass bases that live in the framework or in another installed app.
• Type annotations name types across module boundaries, so a method's parameters carry references to types the file never declares.

Questions this index answers

Phrased as retrievals, because that is what an index can honestly do: it holds the symbols and the edges between them, and hands them back with the evidence attached.

1. Which classes extend this base, and which method overrides which?
2. What does this module export through __all__?
3. Which functions in this file call that one?
4. Which attributes does this class assign to self, and which methods read them?

What the analyzer sees in code like this

from .models import User

class Cart(Base):                       # bb records: class Cart · extends Base
    def add(self, user: User) -> None:  # bb records: method add · references User
        self.count += 1                 # bb records: attribute count

    def total(self) -> int:             # bb records: method total
        return self.count

Symbols are stored with the file they came from and the bytes they span, so a hit points at a line rather than at a guess. The annotations in the sample are commentary for the reader, not strings the index would store.

Languages that turn up in the same repository

Application & systems — the count beside each name is how many relationship types that family’s analyzer constructs.

• TypeScript14 types
• JavaScript12 types
• Rust14 types
• Go12 types
• Java10 types
• C++11 types
• C9 types
• C#11 types
• Swift11 types
• Kotlin11 types
• Dart13 types
• Zig8 types
• Objective-C11 types
• Visual Basic11 types
• VBA9 types