typing._GenericAlias objects allow arbitrary dunder attribute creation

[JelleZijlstra]

Bug report

Bug description:

Objects like typing.List[int] allow arbitrary dunders to be set, and because of the cache, those attributes can leak to other objects created elsewhere in the program:

>>> x = List[int]
>>> x.__whatever__ = 42
>>> List[int].__whatever__
42

The cache behavior seems like it could lead to undesirable behavior. In 3.14 we somewhat accidentally fixed a similar bug with Union objects, and it turns out some people were relying on this: #132139. Let's think about whether we also want to remove this wart for other typing objects in 3.15.

CPython versions tested on:

CPython main branch

Operating systems tested on:

No response

[emmatyping]

Setting dunders on genetic aliases is not (as far as I am aware) documented/supported behavior. So it's not clear to me this is a bug we need to do anything about?

[JelleZijlstra]

It's unsupported; the trouble is that if people do it in practice, they may get upset if we change something about how it works later. So we might be better off disallowing attribute assignment on these objects entirely so people stop relying on it.

[azerty-svg]

Here's what the language reference says:
(About name forms)
*

System-defined names, informally known as “dunder” names. These names are defined by the interpreter and its implementation (including the standard library). Current system names are discussed in the [Special method names](https://docs.python.org/3/reference/datamodel.html#specialnames) section and elsewhere. More will likely be defined in future versions of Python. Any use of __*__ names, in any context, that does not follow explicitly documented use, is subject to breakage without warning.

Found in language reference 3.3.2

[azerty-svg]

System-defined names, informally known as “dunder” names. These names are defined by the interpreter and its implementation (including the standard library). Current system names are discussed in the Special method names section and elsewhere. More will likely be defined in future versions of Python. Any use of * names, in any context, that does not follow explicitly documented use, is subject to breakage without warning.

[azerty-svg]

My interpretation:
Since settind dunder attributes on type aliases is not documented, People are not to complain if they use it and suddendly stuff starts breaking. Because they weren't supposed to use the possibility anyway.

It's unsupported; the trouble is that if people do it in practice, they may get upset if we change something about how it works later. So we might be better off disallowing attribute assignment on these objects entirely so people stop relying on it.

Therefore, we don't care of people getting upset

[azerty-svg]

So, is setting dunder attributes on type aliases necessary?
Does it makes anything easier?
Does it gives new possibilities?

[azerty-svg]

Wanting to set an attribute on type aliases feels quite weird.

[azerty-svg]

Is setting an attribute on a type alias documented?