__qualname__ in python 3.3

Peter Otten __peter__ at web.de
Sat Sep 6 12:47:44 EDT 2014


ISE Development wrote:

> Hi,
> 
> When a class is defined within a function, the class generation function's
> '__qualname__' attrbute is not qualified a name.
> 
> For instance:
> 
>     def test():
>         class T:
>             def method(self):
>                 pass
>         t = T()
>         t.method()
> 
> When tracing a call to 'test()' using 'sys.settrace()', extracting the
> 'code' object from the frames of 'call' events and matching it to a
> 'function' object (using 'gc.get_referrers()') results in the following:
> 
> 'code' object     'function' object
> ----------------  ------------------------------------
> co_name: test     __qualname__: test
> co_name: T        __qualname__: T
> co_name: method   __qualname__: test.<locals>.T.method
> 
> The second call corresponds to the class definition and not the call to
> the constructor (which is in fact a call to 'object.__init__', a C
> function hence not traced as a 'call' event - I checked this by
> disassembling the code object).
> 
> I would expect the second call's '__qualname__' to be 'test.<locals>.T'.
> Can this be considered a bug? If so, I'll open one.

I don't understand what you are doing, so I tried to reproduce the 
unqualified class name in 3.4 with the simpler approach of returning T:

Python 3.4.0 (default, Apr 11 2014, 13:05:11) 
[GCC 4.8.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> def test():
...     class T:
...         def method(self): pass
...     return T
... 
>>> T = test()
>>> T.__qualname__
'test.<locals>.T'
>>> T.method.__qualname__
'test.<locals>.T.method'

If you do it that way with 3.3 (I don't have it handy) do you still see
T instead of test.<locals>.T?





More information about the Python-list mailing list