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)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4