__name__ attribute in typing module

[farcat]

BPO	44524
Nosy	@gvanrossum, @ambv, @serhiy-storchaka, @JelleZijlstra, @pablogsal, @miss-islington, @uriyyo, @BvB93, @Fidget-Spinner
PRs	bpo-44524: Add missed __name__ and __qualname__ to typing module objects #27237 [3.10] bpo-44524: Add missed __name__ and __qualname__ to typing module objects (GH-27237) #27246 bpo-44524: Fix an issue wherein _GenericAlias._name was not properly set for specialforms #27614 [3.10] bpo-44524: Fix an issue wherein _GenericAlias._name was not properly set for specialforms (GH-27614) #27632 bpo-44524: Make exc msg more useful when subclass from special form #27710 [3.10] bpo-44524: Fix cryptic TypeError message when trying to subclass special forms in typing (GH-27710) #27815 bpo-44524: Don't modify MRO when inheriting from typing.Annotated #27841 bpo-44524: Do not set _name of _SpecialForm without need #27861 [3.10] bpo-44524: Do not set _name of _SpecialForm without need (GH-27861) #27871 [3.10] bpo-44524: Don't modify MRO when inheriting from typing.Annotated (GH-27841) #27950
Files	typing_attributes.py: tools to see what items in a module miss given attributes; applied to typing

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/ambv'
closed_at = None
created_at = <Date 2021-06-28.14:15:33.897>
labels = ['type-bug', '3.10', '3.11']
title = '__name__ attribute in typing module'
updated_at = <Date 2021-08-28.18:09:48.928>
user = 'https://bugs.python.org/farcat'

bugs.python.org fields:

activity = <Date 2021-08-28.18:09:48.928>
actor = 'miss-islington'
assignee = 'lukasz.langa'
closed = False
closed_date = None
closer = None
components = []
creation = <Date 2021-06-28.14:15:33.897>
creator = 'farcat'
dependencies = []
files = ['50135']
hgrepos = []
issue_num = 44524
keywords = ['patch']
message_count = 41.0
messages = ['396638', '396715', '396725', '396729', '396739', '396778', '397684', '397790', '397795', '397804', '397807', '397818', '397819', '397824', '398945', '398969', '398983', '398986', '398991', '399011', '399015', '399019', '399029', '399081', '399087', '399105', '399107', '399157', '399160', '399164', '399176', '399865', '399918', '399924', '399928', '399929', '400020', '400024', '400283', '400286', '400490']
nosy_count = 11.0
nosy_names = ['gvanrossum', 'farcat', 'lukasz.langa', 'serhiy.storchaka', 'JelleZijlstra', 'pablogsal', 'miss-islington', 'uriyyo', 'BvB93', 'kj', 'lars2']
pr_nums = ['27237', '27246', '27614', '27632', '27710', '27815', '27841', '27861', '27871', '27950']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue44524'
versions = ['Python 3.10', 'Python 3.11']

[farcat]

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

[Fidget-Spinner]

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.

[lars2]

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.

[Fidget-Spinner]

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.

[gvanrossum]

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.

[farcat]

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.

[gvanrossum]

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

[farcat]

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.

[ambv]

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.

[Fidget-Spinner]

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.

[gvanrossum]

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.