Issue 44524: name attribute in typing module (original) (raw)
Created on 2021-06-28 14:15 by farcat, last changed 2022-04-11 14:59 by admin.
Messages (41)
Author: Lars (farcat)
Date: 2021-06-28 14:15
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', 'Counter', 'OrderedDict' do not have a name attribute when imported from typing, but do when imported from collections.
I have written a function to show presence/absence if the name name attribute:
def split_module_names(module): unnamed, named = set(), set() for name in dir(module): if not name.startswith('_'): attr = getattr(module, name) try: if hasattr(attr, 'name'): named.add(name) else: unnamed.add(name) except TypeError: pass return named, unnamed
import typing import collections
typing_named, typing_unnamed = split_module_names(typing) collec_named, collec_unnamed = split_module_names(collections)
print("typing_unnamed:", typing_unnamed) print("collec_named & typing_unnamed:", collec_named & typing_unnamed)
Is this intentional? It seems a little inconsistent.
I also found something that sometimes the name attribute does resolve:
class S(typing.Sized): def len(self): return 0
print("'Sized' in typing_unnamed:", 'Sized' in typing_unnamed) print("[t.name for t in S.mro]:", [t.name for t in S.mro]) # here name is resolved! print("getattr(typing.Sized, 'name', None):", getattr(typing.Sized, 'name', None))
printing:
'Sized' in typing_unnamed: True [t.name for t in S.mro]: ['S', 'Sized', 'Generic', 'object'] getattr(typing.Sized, 'name', None): None
Author: Ken Jin (kj) * 
Date: 2021-06-29 11:55
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 add the split_module_names function or standardize __name__ or something else? Depending on what you're suggesting the follow up would be different.
Author: Lars van Gemerden (lars2)
Date: 2021-06-29 13:21
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 a function to see what items in a module have and do not have a name attribute; thought it might help proceedings.
If I were to suggest an improvement, it would be that all classes and types (or minimally the abc’s) would have a name attribute, being the name under which it can be imported. Also that the abc’s in typing and collections are as similar as possible.
Author: Ken Jin (kj) *
Date: 2021-06-29 14:03
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 to suggest an improvement, it would be that all classes and types (or minimally the abc’s) would have a name attribute, being the name under which it can be imported.
I think this makes sense. It should be as simple as adding self.name = name or some variant. Note that some types hack their names, such as TypeVar or ParamSpec. So it's not always that name == type/class name.
Also that the abc’s in typing and collections are as similar as possible. We strive towards this but it's difficult to get it 100%. The abcs in typing are implemented in pure Python and alias the ones in collections, while the ones in collections are sometimes tied to C. AFAIK, most types in typing only do what the PEPs promise. I hope you understand.
Author: Guido van Rossum (gvanrossum) *
Date: 2021-06-29 14:46
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.
Author: Lars (farcat)
Date: 2021-06-30 14:35
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 classes.
I think '_SpecialForm' can be enhanced to have 'name' by replacing the '_name' attribute with 'name'. Maybe add 'qualname' as well. I cannot say whether there are many more attributes that could be implemented to have the same meaning as in 'type'. The meaning of attributes like 'mro' seem difficult to define. Alternatively 'getattr' could be added (but that might be too much):
def getattr(self, attr): return getattr(self._getitem, attr)
'_BaseGenericAlias''_SpecialGenericAlias' the 'getattr' method could perhaps be adapted (or overridden in '_SpecialGenericAlias') as follows, from:
def getattr(self, attr): # We are careful for copy and pickle. # Also for simplicity we just don't relay all dunder names if 'origin' in self.dict and not _is_dunder(attr): return getattr(self.origin, attr) raise AttributeError(attr)
to:
def getattr(self, attr): if 'origin' in self.dict: return getattr(self.origin, attr) raise AttributeError(attr)
or perhaps:
def getattr(self, attr): if 'origin' in self.dict and hasattr(type, attr): return getattr(self.origin, attr) raise AttributeError(attr)
to forward unresolved attribute names to the original class.
I have written some tools and tested some with the above solutions and this seems to solve the missing 'name' issue and make the typing abc's much more in line with the collection abc's. However I did not do any unit/regression testing (pull the repo, etc.)
tools are attached.
Author: Guido van Rossum (gvanrossum) *
Date: 2021-07-17 03:18
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 originals have those. I think module should be set to ‘typing’, and qualname to ‘typing.WhatEver’.
Author: Lars (farcat)
Date: 2021-07-19 11:26
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 perhaps qualname and module) attributes in the Any type. This is mainly for consistent logging/printing purposes.
Since Any already has a _name attribute, changing this to name might achieve this.
Author: Łukasz Langa (lukasz.langa) *
Date: 2021-07-19 13:19
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 classes and classes created in local scopes.
Author: Ken Jin (kj) *
Date: 2021-07-19 14:59
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.
Author: Guido van Rossum (gvanrossum) *
Date: 2021-07-19 15:30
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.
Author: Łukasz Langa (lukasz.langa) *
Date: 2021-07-19 17:22
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
Author: Łukasz Langa (lukasz.langa) *
Date: 2021-07-19 17:23
Thanks! ✨ 🍰 ✨
Author: Łukasz Langa (lukasz.langa) *
Date: 2021-07-19 17:57
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) https://github.com/python/cpython/commit/c895f2bc4f270efce30fe3687ce85095418175f4
Author: Bas van Beek (BvB93) *
Date: 2021-08-04 19:48
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__)
NoneAuthor: Guido van Rossum (gvanrossum) *
Date: 2021-08-05 06:35
Serhiy or Ken-Jin?
Author: Ken Jin (kj) *
Date: 2021-08-05 10:14
This PRs herein have created a situation wherein the
__name__/__qualname__attributes of certain typing objects can beNone. Is this behavior intentional?
The affected objects are special forms which can hold types, so Union[], TypeGuard[], and Concatenate[].
Personally, I don't really understand the meaning of name for special forms. From the docs https://docs.python.org/3/library/stdtypes.html#definition.name, name refers to "The name of the class, function, method, descriptor, or generator instance.". name make sense for GenericAlias because it's supposed to be an almost transparent proxy to the original class (eg. typing.Callable -> collections.abc.Callable). A special form is not really any one of those things listed in the docs (though I'm aware it's implemented using GenericAlias internally).
OTOH, Python's definition of a type and typing's are wildly different. Union[X, Y] is called a "Union type" (despite being an object), and all types ought to have name ;).
@Lars, would it help your use case for Union[X, Y] and friends to have name too? Note that this would mean the builtin union object (int | str) will need to support name too. It looks a bit strange to me, but if it's useful I'm a +0.5 on this.
CC-ed Serhiy for his opinion too.
Author: Bas van Beek (BvB93) *
Date: 2021-08-05 10:30
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 (as can happen in its the current implementation),
the latter of which is actively breaking tests over in https://github.com/numpy/numpy/pull/19612.
I don't recall ever seeing a non-string name before, so I'd argue that this is a bug.
It seems to be easy to fix though (see below for a Union example), so if there are objections I'd like to submit a PR.
- return _UnionGenericAlias(self, parameters)
+ return _UnionGenericAlias(self, parameters, name="Union")Author: Ken Jin (kj) *
Date: 2021-08-05 10:58
@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 generate docstrings.
I don't recall ever seeing a non-string name before, so I'd argue that this is a bug.
Yes.
Whether we should have this feature is a distinct "problem" from its
__name__beingNone
If we properly set name for all typing special forms, it won't have this problem anymore right? So we can kill two birds with one stone :).
I'd like to submit a PR.
Please do! I'm re-opening this issue. Thanks for informing us.
Author: Bas van Beek (BvB93) *
Date: 2021-08-05 16:22
All right, the __name__ bug fix is up at https://github.com/python/cpython/pull/27614.
Author: Serhiy Storchaka (serhiy.storchaka) *
Date: 2021-08-05 16:42
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 not a class. I don't know exact reasons, but it was intentional. We introduced mro_entries for this (it was significant intervention in class creation mechanism).
Author: Ken Jin (kj) *
Date: 2021-08-05 17:37
@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 they apply only to "name of the class, function, method, descriptor, or generator instance". The typing "types" are objects, not classes, so normally they wouldn't apply, but maybe there is an exception (see below).
How are these attributes used?
According to OP, for logging/printing purposes. Initially, I was slightly against adding this. But I realized that it make sense for ABCs and concrete classes. PEP 585 says that the builtin types.GenericAlias is a "thin proxy type that forwards all method calls and attribute accesses to the bare origin type"[1] with some exceptions. typing._GenericAlias is supposed to behave similarly to builtin version.
list[int].name 'list' collections.abc.Callable[[int], str].name 'Callable'
Both typing.List[int].name and typing.Callable[int].name raised error before Yurii's PR. So I think it's good that we aligned typing's behavior and the builtin version.
[1] https://www.python.org/dev/peps/pep-0585/#parameters-to-generics-are-available-at-runtime
I just realized Łukasz wrote PEP 585, so maybe he can shed some insight too.
Author: Serhiy Storchaka (serhiy.storchaka) *
Date: 2021-08-05 18:53
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) does not have these attributes. Would not be better to raise AttributeError instead of returning None?
Author: Łukasz Langa (lukasz.langa) *
Date: 2021-08-06 12:48
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 place?", it's for introspection purposes.
Author: Łukasz Langa (lukasz.langa) *
Date: 2021-08-06 13:36
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)
https://github.com/python/cpython/commit/8bdf12e99a3dc7ada5f85bba79c2a9eb9931f5b0
Author: miss-islington (miss-islington)
Date: 2021-08-06 17:08
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)
https://github.com/python/cpython/commit/36a2497093f0c66c2fb1667308691561c1bbe3f4
Author: Łukasz Langa (lukasz.langa) *
Date: 2021-08-06 17:10
Looks like we can re-close this again. Thanks for your quick reaction, Bas! ✨ 🍰 ✨
Author: Pablo Galindo Salgado (pablogsal) *
Date: 2021-08-06 22:24
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 leaked [29, 29, 29, 29] references, sum=116 test_typing leaked [10, 10, 10, 10] memory blocks, sum=40 test_typing failed (reference leak)
== Tests result: FAILURE ==
1 test failed: test_typing
1 re-run test: test_typing
Total duration: 1.2 sec
Author: Pablo Galindo Salgado (pablogsal) *
Date: 2021-08-06 23:46
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 revert 8bdf12e99a3dc7ada5f85bba79c2a9eb9931f5b0 and its backport to avoid masking other issues if this is not fixed in 24 hours.
Author: Pablo Galindo Salgado (pablogsal) *
Date: 2021-08-07 01:21
Wow, turns out the reference leak has been here since forever! I opened https://bugs.python.org/issue44856? to tackle it
Author: Łukasz Langa (lukasz.langa) *
Date: 2021-08-07 11:20
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 last): File "", line 1, in TypeError: init() takes 2 positional arguments but 4 were given
It's still a TypeError but the message is cryptic. This regressed in Python 3.9. In Python 3.8 and before, this used to be more descriptive:
class C(Union[int, str]): ... ... Traceback (most recent call last): File "", line 1, in File "/Users/ambv/.pyenv/versions/3.8.9/lib/python3.8/typing.py", line 317, in new raise TypeError(f"Cannot subclass {cls!r}") TypeError: Cannot subclass <class 'typing._SpecialForm'>
Interestingly, after the Bas' last change, the exception is now yet different:
class C(Union[int, str]): ... ... Traceback (most recent call last): File "", line 1, in TypeError: metaclass conflict: the metaclass of a derived class must be a (non-strict) subclass of the metaclasses of all its bases
This makes sense, the conflict is due to bases being (typing.Union, <class 'typing.Generic'>) where "typing.Union" is really a _UnionGenericAlias since this is a subscripted Union (unlike bare "typing.Union" which is an instance of _SpecialForm). And in _GenericAlias' mro_entries we're finding:
Clearly Ivan only intended _name to be used for shadowing builtins and ABCs.
BTW, the "init() takes 2 positional arguments but 4 were given" is about SpecialForm's init. It's called with 4 arguments through here in builtin___build_class_:
This isn't high priority since the end result is a TypeError anyway, but it's something I will be investigating to make the error message sensible again.
Author: Łukasz Langa (lukasz.langa) *
Date: 2021-08-18 19:08
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)
https://github.com/python/cpython/commit/a3a4d20d6798aa2975428d51f3a4f890248810cb
Author: Serhiy Storchaka (serhiy.storchaka) *
Date: 2021-08-19 13:48
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 (non-strict) subclass of the metaclasses of all its bases
Author: Serhiy Storchaka (serhiy.storchaka) *
Date: 2021-08-19 16:36
There are some side effects of setting _name. In 3.9:
class X(Annotated[int, (1, 10)]): pass ... X.mro (<class '__main__.X'>, <class 'int'>, <class 'object'>)
In 3.10:
class X(Annotated[int, (1, 10)]): pass ... X.mro (<class '__main__.X'>, <class 'int'>, <class 'typing.Generic'>, <class 'object'>)
Now a subclass of an Annotated alias is a generic type. Should it be?
Author: Ken Jin (kj) *
Date: 2021-08-19 17:50
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 that's the case, it's subclassable and Generic shouldn't be in the MRO.
FWIW, the other special forms don't allow subclassing, so we don't need to think about this problem for them. Annotated is a special cookie.
I propose we just drop the _name hack temporarily in Annotated. A real fix requires fixing up mro_entries, but I am uncomfortable with us backporting to 3.10 anything that touches mro_entries due to the numerous edge cases it has and how close we are to 3.10 final.
Author: Jelle Zijlstra (JelleZijlstra) *
Date: 2021-08-19 18:07
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 either.
On the other hand, subclassing Annotated[T, ...] does work at runtime in 3.9, so maybe we're bound by backward compatibility now.
Author: Serhiy Storchaka (serhiy.storchaka) *
Date: 2021-08-21 06:48
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
Author: Serhiy Storchaka (serhiy.storchaka) *
Date: 2021-08-21 09:33
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) https://github.com/python/cpython/commit/5bd27c3be5734e158f67ff86087a977a25d89161
Author: Serhiy Storchaka (serhiy.storchaka) *
Date: 2021-08-25 18:14
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
Author: miss-islington (miss-islington)
Date: 2021-08-25 18:36
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
Author: miss-islington (miss-islington)
Date: 2021-08-28 18:09
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)
https://github.com/python/cpython/commit/81fa08c5ea2cf15254b951034b9d6c7358f96d79
History
Date
User
Action
Args
2022-04-11 14:59:47
admin
set
github: 88690
2021-08-28 18:09:48
miss-islington
set
messages: +
2021-08-25 18:36:58
miss-islington
set
messages: +
2021-08-25 18:14:09
miss-islington
set
pull_requests: + <pull%5Frequest26397>
2021-08-25 18:14:07
serhiy.storchaka
set
messages: +
2021-08-21 09:33:37
serhiy.storchaka
set
messages: +
2021-08-21 06:48:19
miss-islington
set
pull_requests: + <pull%5Frequest26325>
2021-08-21 06:48:08
serhiy.storchaka
set
messages: +
2021-08-20 17:19:13
serhiy.storchaka
set
pull_requests: + <pull%5Frequest26319>
2021-08-19 18:07:35
JelleZijlstra
set
messages: +
2021-08-19 17:50:08
kj
set
messages: +
2021-08-19 17:49:42
kj
set
pull_requests: + <pull%5Frequest26305>
2021-08-19 16:36:15
serhiy.storchaka
set
messages: +
2021-08-19 13:48:13
serhiy.storchaka
set
messages: +
2021-08-18 19:08:41
lukasz.langa
set
messages: +
2021-08-18 19:08:41
miss-islington
set
pull_requests: + <pull%5Frequest26280>
2021-08-10 13:58:48
uriyyo
set
stage: resolved -> patch review
pull_requests: + <pull%5Frequest26195>
2021-08-07 11:23:07
lukasz.langa
set
status: pending -> open
assignee: lukasz.langa
2021-08-07 11:22:56
lukasz.langa
set
priority: release blocker -> normal
status: open -> pending
2021-08-07 11:20:54
lukasz.langa
set
messages: +
2021-08-07 01:21:27
pablogsal
set
messages: +
2021-08-06 23:46:52
pablogsal
set
messages: +
2021-08-06 22:24:43
pablogsal
set
priority: high -> release blocker
2021-08-06 22:24:15
pablogsal
set
status: closed -> open
nosy: + pablogsal
messages: +
resolution: fixed ->
2021-08-06 17:10:12
lukasz.langa
set
status: open -> closed
resolution: fixed
messages: +
stage: patch review -> resolved
2021-08-06 17:08:38
miss-islington
set
messages: +
2021-08-06 13:36:44
miss-islington
set
pull_requests: + <pull%5Frequest26126>
2021-08-06 13:36:39
lukasz.langa
set
messages: +
2021-08-06 12:48:03
lukasz.langa
set
messages: +
2021-08-05 18:53:33
serhiy.storchaka
set
messages: +
2021-08-05 17:37:10
kj
set
messages: +
2021-08-05 16:42:15
serhiy.storchaka
set
messages: +
2021-08-05 16:22:40
BvB93
set
messages: +
2021-08-05 16:16:21
BvB93
set
stage: resolved -> patch review
pull_requests: + <pull%5Frequest26108>
2021-08-05 10:58:22
kj
set
priority: normal -> high
status: closed -> open
resolution: fixed -> (no value)
messages: +
2021-08-05 10:30:29
BvB93
set
messages: +
2021-08-05 10:14:04
kj
set
nosy: + serhiy.storchaka
messages: +
2021-08-05 06:35:53
gvanrossum
set
messages: +
2021-08-04 19:48:44
BvB93
set
nosy: + BvB93
messages: +
2021-07-19 17:57:34
lukasz.langa
set
messages: +
2021-07-19 17:24:29
miss-islington
set
nosy: + miss-islington
pull_requests: + <pull%5Frequest25794>
2021-07-19 17:24:08
lukasz.langa
set
versions: + Python 3.10, Python 3.11, - Python 3.9
2021-07-19 17:23:59
lukasz.langa
set
status: open -> closed
resolution: fixed
messages: +
stage: patch review -> resolved
2021-07-19 17:22:32
lukasz.langa
set
messages: +
2021-07-19 15:30:40
gvanrossum
set
messages: +
2021-07-19 14:59:22
kj
set
messages: +
2021-07-19 13:19:32
lukasz.langa
set
nosy: + lukasz.langa
messages: +
2021-07-19 11:26:37
farcat
set
messages: +
2021-07-19 11:07:07
uriyyo
set
keywords: + patch
nosy: + uriyyo
pull_requests: + <pull%5Frequest25786>
stage: patch review
2021-07-17 03🔞39
gvanrossum
set
messages: +
2021-06-30 14:35:26
farcat
set
files: + typing_attributes.py
messages: +
2021-06-29 14:46:03
gvanrossum
set
messages: +
2021-06-29 14:03:34
kj
set
messages: +
2021-06-29 13:21:19
lars2
set
nosy: + lars2
messages: +
2021-06-29 11:55:16
kj
set
nosy: + gvanrossum
messages: +
2021-06-28 15:14:37
JelleZijlstra
set
nosy: + JelleZijlstra, kj
2021-06-28 14:15:33
farcat
create