Repository navigation
PEP 849: Minor edits and fixes - #5185
Conversation
| value 5. Annotate functions do not have to support this format. If an | ||
| annotate function is called with this format, it must return a | ||
| ``AnnotationAST`` object. These are instances of a proposed new class that | ||
| dict with str keys and ``AnnotationAST`` objects as values (or a single ``AnnotationAST`` object |
There was a problem hiding this comment.
The prose earlier said it returns a dictionary of strings to AnnotationAST objects.
Though maybe a single AnnotationAST object would make sense? The namespace is the same for all annotations in a namespace, after all.
There was a problem hiding this comment.
My original implementation used the layout that you're describing. But in the discourse thread David Ellis requested the nesting to be flipped in order to support synthesizing annotate functions more easily. Essentially, if each annotate object has its own reference to its namespace we can merge e.g. dataclasses from different modules without having to worry about namespace issues. The compiler generated annotate functions also don't actually create duplicate namespace objects, so memory usage isn't a big problem.
This layout also has the advantage that every annotation format returns a dict mapping variable names to some data. When I implemented the other version I had to add a lot of boilerplate case distinctions to things like the dataclasses or annotationlib modules.
| Compiler-generated annotate functions will always support this format. | ||
| They will store the necessary AST data stored as string constants and then | ||
| construct a new ``AnnotationAST`` objects each time they are called. The | ||
| They will store the necessary AST data as string constants and then |
There was a problem hiding this comment.
Unrelated to the grammatical fix on this line: shouldn't this be bytes constants?
There was a problem hiding this comment.
Currently the implementation is using genuine str objects. Bytes have the advantage that the encoding is slightly simpler since you don't need to worry about it being valid UTF-8. But strings let us intern them, which slightly reduces memory usage (about 1.5% of overall module/.pyc size). Execution time (both of the annotate call and module import) is the same for both types. I don't have a strong stance on which is better, if there's a reason to prefer one over the other I'm happy to just go with that.
There was a problem hiding this comment.
We could build bytes interning as part of this PEP, but I guess strings are fine too.
Documentation build overview
|
2 participants
cc @ImogenBits