FYI, the SC has decided to accept PEP 649, but for 3.13 rather than 3.12 (and without a future import). Given the size of the implementation and the number of details that’ll need to get sorted out, and the relatively acceptable status quo, we’re more comfortable that way. We do want to get it into 3.13 early, though, to give the implementation as much exposure as possible.
12 Likes
OK! So, it’s the __dict__ of the class, rather than the namespace of the class statement.
The issue I see is that the class __dict__ is not set (and in general, can’t be created) until the class is finalized, at which point the function objects for its methods are already created. And things like Pydantic decorators will want to inspect annotations right after those functions are made.
(Are you planning something like starting with a mappingproxy of the class statement’s namespace, and then swapping its underlying object and using it as class __dict__?)
Worse than that! What we’re actually going to store is a “cell variable”, which the class-definition machinery will create and maintain for us. Initially it’ll contain the “namespace” object (the object returned by __prepare__). Once the class is defined, and the class-definition machinery creates the final class __dict__ and copies all the data into it, it’ll also update the cell variable to point to the final class __dict__. We’ll then add a new opcode or two that looks up names in this dict at runtime, because the value of the class dict can change at any time, so we can’t depend on the static namespace resolution work done by symtable at compile-time.
And by “we” I mean me and @Jelle will do it, and really by “we” I just mean Jelle, because he already did it for his implementation of 695.
3 Likes