As noted in https://docs.python.org/3/reference/datamodel.html?#creating-the-class-object, implementing PEP 487 required the introduction of __classcell__ as a way for __build_class__ to pass the zero-arg super() cell object through to type.__new__.

Now that Python 3.7+ offers context variables, we may be able to design a more robust (and better hidden) alternative which stashes the "current zero-arg super cell object" in a context variable, allowing type.__new__ to retrieve it when needed, without having to pass it through the class body execution namespace.

This would work only if we had chained contexts from PEP 550.  With PEP 567, swapping the current Context in boundmethods would cause all methods to lose the context that the user wanted them to run in.

Note that this isn't about the __class__ reference itself - that would still be a closure cell.

This issue is about the fact that since Python 3.6, type.__new__ has handled calling __set_name__ on all the descriptors, so __build_class__ needs a way to pass the cell over to type.__new__.

Currently, the channel for that is the class body execution namespace itself, which created a new requirement for metaclasses to ensure that the "__classcell__" entry actually makes it all the way to "type.__new__". Django at least had to make changes to account for that, and it's mildly disappointing to be imposing that requirement on library and framework authors solely because of a technical limitation in CPython.

Even without context chaining, it seems to me that nesting of class definitions could be handled by making the context variable a list of cell objects and having type.__new__ look at the final entry rather than the whole thing.

> Even without context chaining, it seems to me that nesting of class definitions could be handled by making the context variable a list of cell objects and having type.__new__ look at the final entry rather than the whole thing.

Hum, yeah, this might work :)