[issue44524] __name__ attribute in typing module

miss-islington added the comment: New changeset 81fa08c5ea2cf15254b951034b9d6c7358f96d79 by Miss Islington (bot) in branch '3.10': bpo-44524: Fix cryptic TypeError message when trying to subclass special forms in `typing` (GH-27710)

[issue44524] __name__ attribute in typing module

miss-islington added the comment: New changeset 06e9a35169e125488d4ae9228626eb95375f3a14 by Miss Islington (bot) in branch '3.10': bpo-44524: Don't modify MRO when inheriting from typing.Annotated (GH-27841) https://github.com/python/cpython/commit/06e9a35169e125488d4ae9228626eb95375f3a14

[issue44524] __name__ attribute in typing module

Change by miss-islington : -- pull_requests: +26397 pull_request: https://github.com/python/cpython/pull/27950 ___ Python tracker ___

[issue44524] __name__ attribute in typing module

Serhiy Storchaka added the comment: New changeset 23384a1749359f0ae7aaae052073d44b59e715a1 by Ken Jin in branch 'main': bpo-44524: Don't modify MRO when inheriting from typing.Annotated (GH-27841) https://github.com/python/cpython/commit/23384a1749359f0ae7aaae052073d44b59e715a1 --

[issue44524] __name__ attribute in typing module

Serhiy Storchaka added the comment: New changeset 5bd27c3be5734e158f67ff86087a977a25d89161 by Miss Islington (bot) in branch '3.10': bpo-44524: Do not set _name of _SpecialForm without need (GH-27861) (GH-27871)

[issue44524] __name__ attribute in typing module

Change by miss-islington : -- pull_requests: +26325 pull_request: https://github.com/python/cpython/pull/27871 ___ Python tracker ___

[issue44524] __name__ attribute in typing module

Serhiy Storchaka added the comment: New changeset 4ceec495598e78f0776dd46d511dcc612a434dc3 by Serhiy Storchaka in branch 'main': bpo-44524: Do not set _name of _SpecialForm without need (GH-27861) https://github.com/python/cpython/commit/4ceec495598e78f0776dd46d511dcc612a434dc3 --

[issue44524] __name__ attribute in typing module

Change by Serhiy Storchaka : -- pull_requests: +26319 pull_request: https://github.com/python/cpython/pull/27861 ___ Python tracker ___

[issue44524] __name__ attribute in typing module

Jelle Zijlstra added the comment: I don't think we need to support Annotated as a base class. PEP 593 is titled "Flexible function and variable annotations", and base classes are neither of those things. None of the examples in the PEP or the implementation use Annotated as a base class

[issue44524] __name__ attribute in typing module

Ken Jin added the comment: > Now a subclass of an Annotated alias is a generic type. Should it be? I'm unsure if Annotated should be subclassable in the first place, but if I understand PEP 593 correctly, class X(Annotated[int, (1, 10)]), should be equivalent to class X(int) right? If

[issue44524] __name__ attribute in typing module

Change by Ken Jin : -- pull_requests: +26305 pull_request: https://github.com/python/cpython/pull/27841 ___ Python tracker ___ ___

[issue44524] __name__ attribute in typing module

Serhiy Storchaka added the comment: There are some side effects of setting _name. In 3.9: >>> class X(Annotated[int, (1, 10)]): pass ... >>> X.__mro__ (, , ) In 3.10: >>> class X(Annotated[int, (1, 10)]): pass ... >>> X.__mro__ (, , , ) Now a subclass of an Annotated alias is a generic

[issue44524] __name__ attribute in typing module

Serhiy Storchaka added the comment: There are still cryptic TypeError messages for Annotated: >>> class X(Annotated[int | float, "const"]): pass ... Traceback (most recent call last): File "", line 1, in TypeError: metaclass conflict: the metaclass of a derived class must be a

[issue44524] __name__ attribute in typing module

Change by miss-islington : -- pull_requests: +26280 pull_request: https://github.com/python/cpython/pull/27815 ___ Python tracker ___

[issue44524] __name__ attribute in typing module

Łukasz Langa added the comment: New changeset a3a4d20d6798aa2975428d51f3a4f890248810cb by Yurii Karabas in branch 'main': bpo-44524: Fix cryptic TypeError message when trying to subclass special forms in `typing` (GH-27710)

[issue44524] __name__ attribute in typing module

Change by Yurii Karabas <1998uri...@gmail.com>: -- pull_requests: +26195 stage: resolved -> patch review pull_request: https://github.com/python/cpython/pull/27710 ___ Python tracker

[issue44524] __name__ attribute in typing module

Change by Łukasz Langa : -- assignee: -> lukasz.langa status: pending -> open ___ Python tracker ___ ___ Python-bugs-list mailing

[issue44524] __name__ attribute in typing module

Change by Łukasz Langa : -- priority: release blocker -> normal status: open -> pending ___ Python tracker ___ ___ Python-bugs-list

[issue44524] __name__ attribute in typing module

Łukasz Langa added the comment: Curiously, while the root cause for the refleaks is in BPO-44856, while hunting down how test_typing.py triggered them, I found that for a while now this exception has been kind of broken: >>> class C(Union[int, str]): ... ... Traceback (most recent call

[issue44524] __name__ attribute in typing module

Pablo Galindo Salgado added the comment: Wow, turns out the reference leak has been here since forever! I opened https://bugs.python.org/issue44856? to tackle it -- ___ Python tracker

[issue44524] __name__ attribute in typing module

Pablo Galindo Salgado added the comment: Unfortunately given that the all refleak buildbots will start to fail and the fact that this got into the release candidate, per our buildbot policy (https://discuss.python.org/t/policy-to-revert-commits-on-buildbot-failure/404) we will be forced to

[issue44524] __name__ attribute in typing module

Change by Pablo Galindo Salgado : -- priority: high -> release blocker ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue44524] __name__ attribute in typing module

Pablo Galindo Salgado added the comment: Unfortunately PR27614 and its backport has introduced reference leaks: ❯ ./python -m test test_typing -R : 0:00:00 load avg: 1.12 Run tests sequentially 0:00:00 load avg: 1.12 [1/1] test_typing beginning 9 repetitions 123456789 . test_typing

[issue44524] __name__ attribute in typing module

Łukasz Langa added the comment: Looks like we can re-close this again. Thanks for your quick reaction, Bas! ✨  ✨ -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue44524] __name__ attribute in typing module

miss-islington added the comment: New changeset 36a2497093f0c66c2fb1667308691561c1bbe3f4 by Miss Islington (bot) in branch '3.10': bpo-44524: Fix an issue wherein `_GenericAlias._name` was not properly set for specialforms (GH-27614)

[issue44524] __name__ attribute in typing module

Change by miss-islington : -- pull_requests: +26126 pull_request: https://github.com/python/cpython/pull/27632 ___ Python tracker ___

[issue44524] __name__ attribute in typing module

Łukasz Langa added the comment: New changeset 8bdf12e99a3dc7ada5f85bba79c2a9eb9931f5b0 by Bas van Beek in branch 'main': bpo-44524: Fix an issue wherein `_GenericAlias._name` was not properly set for specialforms (GH-27614)

[issue44524] __name__ attribute in typing module

Łukasz Langa added the comment: Serhiy, good question. As builtin generics return the base `__name__` for subscribed version, it makes sense to do the same for the versions in `typing`, especially if their unsubscribed versions provide `__name__`. As to "why even have `__name__` in the first

[issue44524] __name__ attribute in typing module

Serhiy Storchaka added the comment: Thank you Ken Jin. But it does not explain why objects which currently have __name__/__qualname__ is None should have these attribute. There is no builtin data type that corresponds to ClassVar, Final, Literal, Concatenate or TypeGuard. And (int | str)

[issue44524] __name__ attribute in typing module

Ken Jin added the comment: @Serhiy a summary from what I understand. I hope this helps: > I am confused. Why do these objects should have __name__ and __qualname__ > attributes? What document specifies this? I don't think any doc specifies this. The docs for __name__ and __qualname__ say

[issue44524] __name__ attribute in typing module

Serhiy Storchaka added the comment: I am confusing. Why do these objects should have __name__ and __qualname__ attributes? What document specifies this? How are these attributes used? collections.abc.MutableSet and typing.MutableSet are different things. The former is a class, the latter is

[issue44524] __name__ attribute in typing module

Bas van Beek added the comment: All right, the `__name__` bug fix is up at https://github.com/python/cpython/pull/27614. -- ___ Python tracker ___

[issue44524] __name__ attribute in typing module

Change by Bas van Beek : -- pull_requests: +26108 stage: resolved -> patch review pull_request: https://github.com/python/cpython/pull/27614 ___ Python tracker ___

[issue44524] __name__ attribute in typing module

Ken Jin added the comment: @Bas van Beek, thanks for testing numpy on 3.10rc1 and sending that link over. I was confused about what your original question entailed. The link provided much more context :). Seems that __name__ = None unintentionally breaks things that use annotations to

[issue44524] __name__ attribute in typing module

Bas van Beek added the comment: I do agree that it's nice to have a `__name__` for special forms, as they do very much behave like types even though they're strictly speaking not distinct classes. Whether we should have this feature is a distinct "problem" from its `__name__` being `None`

[issue44524] __name__ attribute in typing module

Ken Jin added the comment: > This PRs herein have created a situation wherein the > `__name__`/`__qualname__` attributes of certain typing objects can be `None`. > Is this behavior intentional? The affected objects are special forms which can hold types, so Union[], TypeGuard[], and

[issue44524] __name__ attribute in typing module

Guido van Rossum added the comment: Serhiy or Ken-Jin? -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44524] __name__ attribute in typing module

Bas van Beek added the comment: This PRs herein have created a situation wherein the `__name__`/`__qualname__` attributes of certain typing objects can be `None`. Is this behavior intentional? ``` >>> from typing import Union >>> print(Union[int, float].__name__) None ``` -- nosy:

[issue44524] __name__ attribute in typing module

Łukasz Langa added the comment: New changeset c895f2bc4f270efce30fe3687ce85095418175f4 by Miss Islington (bot) in branch '3.10': bpo-44524: Add missed __name__ and __qualname__ to typing module objects (GH-27237) (#27246)

[issue44524] __name__ attribute in typing module

Change by miss-islington : -- nosy: +miss-islington nosy_count: 7.0 -> 8.0 pull_requests: +25794 pull_request: https://github.com/python/cpython/pull/27246 ___ Python tracker

[issue44524] __name__ attribute in typing module

Łukasz Langa added the comment: Thanks! ✨  ✨ -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue44524] __name__ attribute in typing module

Change by Łukasz Langa : -- versions: +Python 3.10, Python 3.11 -Python 3.9 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue44524] __name__ attribute in typing module

Łukasz Langa added the comment: New changeset bce1418541a64a793960182772f985f64afbfa1a by Yurii Karabas in branch 'main': bpo-44524: Add missed __name__ and __qualname__ to typing module objects (#27237) https://github.com/python/cpython/commit/bce1418541a64a793960182772f985f64afbfa1a

[issue44524] __name__ attribute in typing module

Guido van Rossum added the comment: I see this as part of a trend to improve runtime introspection of complex type expressions. That seems to be going ahead regardless of whether we like it or not, so let's do this. -- ___ Python tracker

[issue44524] __name__ attribute in typing module

Ken Jin added the comment: Yurii has a working PR for __name__ in _BaseGenericAlias, but not for _SpecialForm yet. Guido and/or Lukasz, do y'all think we should support __name__ and __qualname__ for special forms too? Personally I don't see how it'd hurt and I'm +1 for this. --

[issue44524] __name__ attribute in typing module

Łukasz Langa added the comment: > I think __module__ should be set to ‘typing’, and __qualname__ to > ‘typing.WhatEver’. PEP 3155 specifies that `__qualname__` does not include the module name: https://www.python.org/dev/peps/pep-3155/#excluding-the-module-name Rather, it's for nested

[issue44524] __name__ attribute in typing module

Lars added the comment: Happy to see progress on this issue and I can see that adding these attributes to the ABC's in typing makes the most sense. However for my direct use-case (simplified: using Any in a type checking descriptor) it would be really practical to have the __name__ (and

[issue44524] __name__ attribute in typing module

Change by Yurii Karabas <1998uri...@gmail.com>: -- keywords: +patch nosy: +uriyyo nosy_count: 5.0 -> 6.0 pull_requests: +25786 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27237 ___ Python tracker

[issue44524] __name__ attribute in typing module

Guido van Rossum added the comment: Sorry for the slow progress. I don’t think it is important for Any orUnion to have these attributes, but the ones that match ABCs or concrete classes (e.g. MutableSet, Counter) should probably have __name__, __qualname__, and __module__, since the

[issue44524] __name__ attribute in typing module

Lars added the comment: I have been doing some research, but note that I don't have much experience with the typing module. That said, there seem to be 2 main cases: - '_SpecialForm': with instances Any, Union, etc. - '_BaseGenericAlias'/'_SpecialGenericAlias': base classes collections

[issue44524] __name__ attribute in typing module

Guido van Rossum added the comment: It sounds reasonable to add the __name__ attribute. Since these objects aren't really types, the default mechanism for constructing a type doesn't give them this. Are there other attributes that are missing? We should probably add those too. --

[issue44524] __name__ attribute in typing module

Ken Jin added the comment: Lars, yes you're right that __name__ is documented in datamodel, sorry I wasn't clear in my original message. What I meant was that specifically for the typing module, it's not exposed anywhere in its docs https://docs.python.org/3/library/typing.html. > If I were

[issue44524] __name__ attribute in typing module

Lars van Gemerden added the comment: I was not aware the __name__ attribute is an implementation detail. It is described in the docs: https://docs.python.org/3/reference/datamodel.html. I have been using it since python 2.7, for example for logging. The function “split_module_names” is just

[issue44524] __name__ attribute in typing module

Ken Jin added the comment: > Is this intentional? It seems a little inconsistent. The `__name__` attribute is for internal use only. It's subject to change every release along with other implementation details. Sorry, I don't really understand what this issue is requesting. Do you want to

[issue44524] __name__ attribute in typing module

Change by Jelle Zijlstra : -- nosy: +Jelle Zijlstra, kj ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44524] __name__ attribute in typing module

New submission from Lars : I noticed some (perhaps intentional) oddities with the __name__ attribute: - typing classes like Any (subclass of _SpecialForm) do not have a __name__ attribute, - abstract base classes in typing, like MutableSet do not have a __name__ attribute, - 'ChainMap',