bpo-44524: Do not set _name of _SpecialForm without need #27861
Conversation
Becase setting non-empty _name affects other behavior. In most cases __name__ can be derived from __origin__.__name__.
|
What does Ken Jin say? |
There was a problem hiding this comment.
LGTM. Personally I don't think setting _name on _SpecialForms will break anything (because they aren't subclassable, and any methods they need are overridden, so their MRO doesn't matter). But I've been wrong on multiple occasions at this point 😉 , so let's just be safe. From a technical standpoint, Serhiy's solution is much cleaner (and faster) too.
PS @serhiy-storchaka , you can do the same for Annotated and copy the test over from my PR #27841. I'm closing that so we don't have to deal with merging multiple PRs.
| @@ -962,7 +959,7 @@ def __mro_entries__(self, bases): | |||
|
|
|||
| def __getattr__(self, attr): | |||
| if attr in {'__name__', '__qualname__'}: | |||
| return self._name | |||
| return self._name or self.__origin__.__name__ | |||
There was a problem hiding this comment.
This solution is so nice. I wish I'd thought about this a little deeper when I proposed the original one:(.
Anyways if I'm not wrong, __origin__ will always be set on all GenericAlias to some type, so this should always succeed.
| return _UnionGenericAlias(self, parameters, name="Optional") | ||
| return _UnionGenericAlias(self, parameters) |
There was a problem hiding this comment.
Will there be a subtle difference between how the two behaves since one sets name and the other doesn't?
I would think not but I'm not sure.
There was a problem hiding this comment.
Setting _name affects subclassing and pickling/copying. Union[] and Optional[] are not subclassable, and special implementation of __reduce__ was added in previous commits. If there are other difference, I do not know.
|
Thanks @serhiy-storchaka for the PR 🌮🎉.. I'm working now to backport this PR to: 3.10. |
|
GH-27871 is a backport of this pull request to the 3.10 branch. |
) Because setting non-empty _name affects behavior of other code. In most cases __name__ can be derived from __origin__.__name__. (cherry picked from commit 4ceec49) Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
It is easier to merge them separately. There are no conflicts. |
Because setting non-empty
_nameaffects other behavior.In most cases
__name__can be derived from__origin__.__name__.https://bugs.python.org/issue44524