[Python-Dev] super() does not work during class initialization

[Martin Teichmann]

> For folks that haven't looked at the tracker issue: I personally like
> the change, but it does involve storing the cell object in a
> dunder-variable in the class namespace while it's being defined (until
> type.__new__ executes and both populates it and removes it from the
> class namespace).

I think I had the same weird feelings like you when writing the code. It feels
a bit dodgy to abuse the class namespace to transport information from the
compiler to type.__new__. Only when I saw that __qualname__ already does
it, I decided it was probably not such a bad idea. The current implementation,
setting the __class__ cell at the end of __build_class__ doesn't feel dodgy to
me, it simply feels wrong. Nothing of real importance should happen there, as
it is just an implementation detail.

If we are fearing that we clutter namespace too much, we might call the
entries @qualname and @cell, then we are sure they will never mask
a user's class member.

Most of my bad feelings actually only come from the fact that we don't know
what we actually put our entries into, as __prepare__ might return something
weird that doesn't do what we expect. Given Eric Snow's comment that
class namespaces will be ordered by default soon anyways, we might deprecate
__prepare__ altogether, eliminating most of the bad feelings.

Speaking of which, instead of having OrderedDict re-implemented in C, maybe
we could just change the compiler to leave the order in which things are defined
in a class in the class namespace, say as a member __order__? Then we could
use plain-old dicts for the class namespace, and we would not slow down class
creation (not that it matters much), as determining the order would happen at
compile time.

> Since it introduces new behaviour that's visible to Python level code,
> I've suggested that Martin roll the suggestion into his current PEP
> 487 (which adds __init_subclass__ to similarly tidy up a few
> challenges with the way classes are currently initialised).

I thought about that, but while I stumbled over this issue while working
on PEP 487, it is actually unrelated. I didn't want people to think that
this change is needed to implement PEP 487. And while
"and now for something completely different" might be a nice
Monty Python reference, it is mostly frowned upon in PEPs as per PEP 1.

Alternatively, I could write a new PEP. But I actually think that
the change is not worth a PEP, because the changes will move
the CPython implementation actually closer to what is documented,
so I feel it is more a bugfix than an extension.

I have no problem to pursue any of the above paths,
how do other people feel about it?

Greetings

Martin