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

[Guido van Rossum]

So, for __qualname__, should we just update the docs to make this the
law? If that's your recommendation, I'm fine with it, and you can
submit a doc patch.

On Sun, Jul 17, 2016 at 10:01 AM, Martin Teichmann
<lkb.teichmann at gmail.com> wrote:
> Hi,
>
> so I did quite some research on this topic. And what I found out is
> that __qualname__ needs to exist in the namespace. Not necessarily
> because it should be used, but because it may be modified.
>
> The story goes as follows: the compiler sets the __qualname__ at the
> beginning of the class body. Within the class body, it may be modified
> as needed. Then type.__new__ takes it and uses it.
>
> Now one could think that instead of setting the __qualname__ at the
> beginning of the class body, we could do so at the end as to not
> clutter the namespace, and only if the __qualname__ has been set in
> the class body we would use the user-supplied version. But this is
> forgetting __prepare__: unfortunately, we have no good way to find out
> whether something has been set in a class body, because we have no
> guarantee that the object returned by __prepare__ doesn't do something
> weird, as autogenerating values for all requested keys.
>
>> 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.
>
> I tried to give some context on my issue
> (http://bugs.python.org/issue23722). Hope that helps.
>
> 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)