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 __@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@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
