(original) (raw)

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)