René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Add `module` keyword argument to `typing.TypeAliasType`","articleBody":"# Feature or enhancement\n\n### Proposal:\n\nAdd an optional keyword-only `module` argument to `typing.TypeAliasType`, so that callers can override the `__module__` attribute at construction time instead of relying on frame introspection.\n\nNote that while I have posted this idea on Discourse (see linked thread), I haven't gotten any replies. I optimistically take this as the proposal being minor and uncontroversial.\n\n### Motivation\n\n`typing.TypeAliasType` currently derives `__module__` from a [frame walk](https://github.com/python/cpython/blob/d71e3bc5a0f2f7af407eb32a8a5b36acf66070aa/Objects/typevarobject.c#L391). This is unsuitable when constructing `TypeAliasType` objects inside `exec`, from C, or with a factory helper. In such cases `caller()` returns `None` or the wrong module.\n\nThere is currently no way to fix this after the fact, because `__module__` is read-only:\n\n```python\n\u003e\u003e\u003e from typing import TypeAliasType\n\u003e\u003e\u003e ta = TypeAliasType(\"A\", int)\n\u003e\u003e\u003e ta.__module__ = \"x\"\nAttributeError: attribute '__module__' of 'typing.TypeAliasType' objects is not writable\n```\n\nMeanwhile there are consumers that rely on `__module__`, such as IDE go-to-definition or introspection-based stub generation (e.g. with `f\"{alias.__module__}.{alias.__name__}\"`). Such tools have no good recourse when `__module__` is wrong.\n\nAdding a `__module__` kwarg to the `TypeAliasType` constructor is an easy, backward-compatible way to address this. \n`collections.namedtuple` and `enum.Enum` expose such a kwarg and thus serve as precedent. Admittedly, the motivations for this kwarg in [`namedtuple`](https://github.com/python/cpython/blob/d71e3bc5a0f2f7af407eb32a8a5b36acf66070aa/Lib/collections/__init__.py#L517-L521) and [`Enum`](https://github.com/python/cpython/blob/d71e3bc5a0f2f7af407eb32a8a5b36acf66070aa/Lib/enum.py#L718-L720) seem to have more to do with pickling, which is not a use-case of especial import for `TypeAliasType` (though certainly one _can_ pickle a `TypeAliasType`).\n\n### API\n\nThe new `TypeAliasType` constructor signature would be\n\n```python\nTypeAliasType(name, value, *, type_params=(), qualname=None, module=None)\n```\n\n`module=None` (default or explicit) preserves today's behavior. Any other value is stored verbatim with no validation, matching the `namedtuple` and `enum` APIs. Note that I don't object to adding validation here, but figured I'd start off by proposing something most consistent with the precedential APIs.\n\n### Has this already been discussed elsewhere?\n\nI have already discussed this feature proposal on Discourse\n\n### Links to previous discussion of this feature:\n\nhttps://discuss.python.org/t/adding-a-module-keyword-argument-to-typing-typealiastype/107087\n\n\u003c!-- gh-linked-prs --\u003e\n### Linked PRs\n* gh-149133\n* https://github.com/python/typing_extensions/pull/149133\n\u003c!-- /gh-linked-prs --\u003e","author":{"url":"https://github.com/ericmarkmartin","@type":"Person","name":"ericmarkmartin"},"datePublished":"2026-04-29T05:20:11.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":7},"url":"https://github.com/149132/cpython/issues/149132"}