> 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 _______________________________________________ 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
