Python 3 introduced __qualname__. This attribute exists on class types and also instances of certain class types, such as functions. For example:

def f(): pass

print(f.__name__)
print(f.__qualname__)

class Class: pass

print(Class.__name__)
print(Class.__qualname__)

yields:

f
f
Class
Class

An instance of a class however does not have __name__ or __qualname__ attributes. With:

c = Class()

print(c.__name__)
print(c.__qualname__)

yielding:

Traceback (most recent call last):
  File "qualnametest.py", line 13, in <module>
    print(c.__name__)
AttributeError: 'Class' object has no attribute '__name__'

Traceback (most recent call last):
  File "qualnametest.py", line 14, in <module>
    print(c.__qualname__)
AttributeError: 'Class' object has no attribute '__qualname__'

For a class, it is possible to override the __name__ attribute using a property.

class Class:
    @property
    def __name__(self):
        return 'override'

c = Class()

print(c.__name__)

With the result being:

override

This is useful in writing object proxies or function wrappers for decorators as rather than having to copy the __name__ attribute into the wrapper, the lookup can be deferred until when it is required.

The same though cannot be done for __qualname__. With:

class Class:
    @property
    def __qualname__(self):
        return 'override'

yielding an error when the class definition is being processed:

Traceback (most recent call last):
  File "qualnametest.py", line 16, in <module>
    class Class:
TypeError: type __qualname__ must be a str, not property

This means the same trick cannot be used in object proxies and function wrappers and instead __qualname__ must be copied and assigned explicitly as a string attribute in the __init__() function of the object proxy or function wrapper.

I can sort of understand a prohibition on __qualname__ being a string attribute in certain cases, especially if overriding it on a type or instance where __qualname__ attribute already exists, but I don't understand why a limitation would be imposed to prevent using a property as a means of generating the value for a class instance which doesn't otherwise have a __qualname__ attribute. There is no similar restriction for __name__.

Unless there is a good specific reason for this behaviour, the ability to override it with a property in cases where the __qualname__ attribute didn't already exist, would be handy for proxies and wrappers.

I guess this would be a harmless improvement in any case.

This would also be useful for me - I just hit this same problem. If someone could give some guidance on how to make this change I'd be happy to put up a PR.

This is the check that is preventing qualname being a property:

https://github.com/python/cpython/blob/994f90c0772612780361e1dc5fa5223dce22f70a/Objects/typeobject.c#L2853

Note that it is not the same check used for assignment, which is here:

https://github.com/python/cpython/blob/994f90c0772612780361e1dc5fa5223dce22f70a/Objects/typeobject.c#L559


I think some unit tests are missing for properties, they would need to be added.

See also Issue41294.