Add module keyword argument to typing.TypeAliasType

Feature or enhancement

Proposal:

Add 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.

Note 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.

Motivation

typing.TypeAliasType currently derives __module__ from a frame walk. 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.

There is currently no way to fix this after the fact, because __module__ is read-only:

>>> from typing import TypeAliasType
>>> ta = TypeAliasType("A", int)
>>> ta.__module__ = "x"
AttributeError: attribute '__module__' of 'typing.TypeAliasType' objects is not writable

Meanwhile 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.

Adding a __module__ kwarg to the TypeAliasType constructor is an easy, backward-compatible way to address this.
collections.namedtuple and enum.Enum expose such a kwarg and thus serve as precedent. Admittedly, the motivations for this kwarg in namedtuple and Enum 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).

API

The new TypeAliasType constructor signature would be

TypeAliasType(name, value, *, type_params=(), qualname=None, module=None)

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.

Has this already been discussed elsewhere?

I have already discussed this feature proposal on Discourse

Links to previous discussion of this feature:

https://discuss.python.org/t/adding-a-module-keyword-argument-to-typing-typealiastype/107087

Linked PRs

pythongh-149132: Add module keyword argument to `typing.TypeAliasType`

@JelleZijlstra

Note 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.

IMO this is not the case. This may also mean that we are not interested in that proposal or we missed it!

As for the issue it tries to solve, why not injecting __name__ into the exec namespace? I think (but I am not totally sure) that this could perhaps solve your issues.

OTOH, I do not see a reason to reject an explicit module argument except that it may be confusing when combined with the qualified name.

cc @JelleZijlstra

IMO this is not the case. This may also mean that we are not interested in that proposal or we missed it!

That's helpful to know---is there a better way to bump a discourse thread in such cases?

As for the issue it tries to solve, why not injecting __name__ into the exec namespace? I think (but I am not totally sure) that this could perhaps solve your issues.

Do you mean

l = {}
exec("""import typing
T = typing.TypeAliasType("T", int)
""", locals=l, globals={"__name__": "foo"})

Or

import typing

def make_tat():
  return typing.TypeAliasType("T", int)

make_tat.__module__ = "foo"

Or something else?

To me this feels a bit heavy, especially from the C API. Furthermore, I think you could similarly do this for namedtuple and Enum, but they have the module kwarg anyway and so consistency remains a factor.

except that it may be confusing when combined with the qualified name.

Also I realize this is possibly due to my error in mentioning __qualname__ in the issue itself, but in fact I've realized that TypeAliasType doesn't currently have __qualname__. I'm updating the issue as such

I meant the globals=... one. But if it is through the C API, then I can I see why it would be annoying. I would leave the decision to Jelle.

For the DPO question, there is no way to really know apart by tagging core devs directly when possible.. or just wait for more than 1 week (or bump the thread if there is no reaction at all).

Having likes on the DPO message may indicate that the feature is well-perceived at least. Sorry for not being more helpful here :(

Having likes on the DPO message may indicate that the feature is well-perceived at least. Sorry for not being more helpful here :(

That's plenty helpful already--thanks!

pythongh-149132: Add module keyword argument to `typing.TypeAliasType`

I commented on the Discuss thread.

Closing in favor of #149171

Navigation Menu

Repository navigation

Add `module` keyword argument to `typing.TypeAliasType` #149132

Feature or enhancement

Proposal:

Motivation

API

Has this already been discussed elsewhere?

Links to previous discussion of this feature:

Linked PRs

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Add module keyword argument to typing.TypeAliasType #149132

Description

Feature or enhancement

Proposal:

Motivation

API

Has this already been discussed elsewhere?

Links to previous discussion of this feature:

Linked PRs

Activity

picnixz commented on Apr 29, 2026

ericmarkmartin commented on Apr 29, 2026

ericmarkmartin commented on Apr 29, 2026

picnixz commented on Apr 29, 2026

ericmarkmartin commented on Apr 29, 2026

JelleZijlstra commented on Apr 29, 2026

ericmarkmartin commented on Apr 30, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions

Add `module` keyword argument to `typing.TypeAliasType` #149132