[Python-Dev] __qualname__ exposed as a local variable: standard?

[Guido van Rossum]

I think this and similar issues suffer from a lack of people who have
both the time and the understanding to review patches and answer
questions of this nature.

To the OP: I would recommend not depending on the presence of
__qualname__ in the locals, as another compiler/interpreter may come
up with a different approach. However, if you have a use case, please
present it here and maybe we could consider making this a documented
feature.

To Martin: it would be easier for people (even myself, who implemented
this super() hack eons ago) to review your patch if you were able to
explain the current and proposed behavior more precisely. You are
doing your best but realistically almost nobody has enough context to
understand what you wrote in the tracker (certainly to me it's not
enough to remind me of how the super() machinery currently works --
but reading the patch doesn't enlighten me much either as it's mostly
about changes to the low-level C code).

On Wed, Jul 13, 2016 at 7:00 AM, Martin Teichmann
<lkb.teichmann at gmail.com> wrote:
> Hi list,
>
>> I noticed __qualname__ is exposed by locals() while defining a class. This
>> is handy but I'm not sure about its status: is it standard or just an
>> artifact of the current implementation? (btw, the pycodestyle linter -former
>> pep8- rejects its usage). I was unable to find any reference to this
>> behavior in PEP 3155 nor in the language reference.
>
> I would like to underline the importance of this question, and give
> some background, as it happens to resonate with my work on PEP 487.
>
> The __qualname__ of a class is originally determined by the compiler.
> One might now think that it would be easiest to simply set the
> __qualname__ of a class once the class is created, but this is not as
> easy as it sounds. The class is created by its metaclass, so possibly
> by user code, which might create whatever it wants, including
> something which is not even a class. So the decision had been taken to
> sneak the __qualname__ through user code, and pass it to the
> metaclasses __new__ method as part of the namespace, where it is
> deleted from the namespace again. This has weird side effects, as the
> namespace may be user code as well, leading to the funniest possible
> abuses, too obscene to publish on a public mailing list.
>
> A very different approach has been taken for super(). It has similar
> problems: the zero argument version of super looks in the surrounding
> scope for __class__ for the containing class. This does not exist yet
> at the time of creation of the methods, so a PyCell is put into the
> function's scope, which will later be filled. It is actually filled
> with whatever the metaclasses __new__ returns, which may, as already
> be said, anything (some sanity checks are done to avoid crashing the
> interpreter).
>
> I personally prefer the first way of doing things like for
> __qualname__, even at the cost of adding things to the classes
> namespace. It could be moved after the end of the class definition,
> such that it doesn't show up while the class body is executed. We
> might also rename it to __ at qualname__, this way it cannot be accessed
> by users in the class body, unless they look into locals().
>
> This has the large advange that super() would work immediately after
> the class has been defined, i.e. already in the __new__ of the
> metaclass after it has called type.__new__.
>
> All of this changes the behavior of the interpreter, but we are
> talking about undocumented behavior.
>
> The changes necessary to make super() work earlier are store in
> http://bugs.python.org/issue23722
>
> Greetings
>
> Martin
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org



-- 
--Guido van Rossum (python.org/~guido)