[Python-Dev] PEP 563: Postponed Evaluation of Annotations (original) (raw)
Guido van Rossum guido at python.org
Wed Nov 8 01:24:10 EST 2017
- Previous message (by thread): [Python-Dev] PEP 563: Postponed Evaluation of Annotations
- Next message (by thread): [Python-Dev] PEP 563: Postponed Evaluation of Annotations
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
To top off today's set of hopeful thread closures I want to put this one to rest.
While I'm not ready to accept PEP 563 yet (I'm waiting for the first cut of the implementation) I am hereby nixing the thunk idea.
When I said I was more worried about that than about the stringification that wasn't about compatibility so much as about conceptual simplicity. Right now the contents of annotations can be one of two things: an object created by evaluating an annotation, or a string literal. With stringification these two possibilities remain the only two possibilities (and they will still both occur in files that don't use the future import). With thunks, there would be a third option, a 0-argument callable.
I've always disliked APIs (like Django templates, IIRC) that "transparently" support callables by calling them and treat all other values as-is. (What if I have a value that just happens to be callable?) I don't want to add such an API.
I also don't like the idea that there's nothing you can do with a thunk besides calling it -- you can't meaningfully introspect it (not without building your own bytecode interpreter anyway).
Using an AST instead of a string is also undesirable -- the AST changes in each release, and the usual strong compatibility guarantees don't apply here. And how are you going to do anything with it? If you've got a string and you want an AST node, it's one call away. But if you've got an AST node and you want either a string or the object to which that string would evaluate, you've got a lot of work to do. Plus the AST takes up a lot more space than the string, and we don't have a way to put an AST in a bytecode file. (And as Inada-san pointed out a thunk also takes up more space than a string.)
Nick, please don't try to save the thunk proposal by carefully dissecting every one of my objections. That will just prolong its demise.
-- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20171107/fb64c687/attachment.html>
- Previous message (by thread): [Python-Dev] PEP 563: Postponed Evaluation of Annotations
- Next message (by thread): [Python-Dev] PEP 563: Postponed Evaluation of Annotations
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]