Skip to content

feat: resolve declared entry points through module-level aliases - #188

Merged
SizzleUnrlsd merged 8 commits into
mainfrom
feat/entry-point-aliases
Sep 29, 2026
Merged

SizzleUnrlsd merged 8 commits into
mainfrom
feat/entry-point-aliases

Conversation

@SizzleUnrlsd

Copy link
Copy Markdown
Contributor

An EntryPoint naming a project symbol now applies through a module-level alias of the function or class it names.

A deployment declaration names its handler as the module binds it, handlers.main, and the module may bind that name as an alias of the function doing the work, main = actual. function_entry_point now tries the declared symbols of the function's own name and of every module-level alias of it; for a method, those of its class and of the class's aliases, method models before class models whichever name they use.

  • An alias is an assignment of one name to another executed at module level, in a conditional or a try as well, followed transitively and in source order; main = handler = actual counts through the frontend's hidden chain name.
  • A name bound inside a function or class, or to a call, an import, a string or any other value, is no alias: the model names nothing through it, and the engine still infers nothing from a name. What a declaration names and the engine cannot resolve stays for the integration reading the declaration to report.

Tests: tests/test_entry_point_aliases.py (15 cases, failing before the change); pytest -m "not regression" 1438 passed, 2 skipped; regression corpus 19 passed, snapshots unchanged; ruff check . and mypy clean.

…ocessor

A TEMPLATES bound in a function, called or not, or in a class configures nothing; a function reading, mutating or rebinding the module's TEMPLATES leaves the activation uncertain; a local TEMPLATES beside module settings changes nothing.
request_processor walked every node of every module and counted any assignment to TEMPLATES, so a function-local or class-level assignment activated the request context processor. It now walks the modules with their scope tables: an assignment counts only at module scope, and a mention counts only when the name resolves to the module's binding, or to nothing, as a star import gives. ScopeTable.scope_for accepts a lambda, whose scope the builder already records.
…e flow

A block rendering {{ block.super }} extends the parent's block: its filters stay fed by the render context, with the parent template as the place of the call, however block.super is rendered; a block without it replaces the parent's whole block; other overridden blocks stay excluded; a chain of templates keeps exactly the parents each level renders, once.
A template extending another replaced every block it defined in the parent, so the parent's filter applications dropped out of the render context flow even when the child rendered {{ block.super }}, which Django executes. A template now records the blocks that render block.super, and only the blocks defined without it are passed up as replaced, level by level.
A deployment declaration names its handler as the module binds it, and a module may bind that name as an alias of the function doing the work: main = actual. A model naming the alias's project symbol now applies to the function, or to the class's methods for a class alias. Aliases are module-level assignments of one name to another, followed transitively in source order; a name bound inside a function or class, or to a call, an import or any other value, is no alias.
@SizzleUnrlsd SizzleUnrlsd added the enhancement New feature or request label Sep 28, 2026
@SizzleUnrlsd SizzleUnrlsd self-assigned this Sep 28, 2026
@SizzleUnrlsd
SizzleUnrlsd merged commit 0aca784 into main Sep 29, 2026
10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant