[Python-Dev] PEP 563: Postponed Evaluation of Annotations

[INADA Naoki]

As memory footprint and import time point of view, I prefer string to thunk.

We can intern strings, but not lambda.
Dict containing only strings is not tracked by GC,
dict containing lambdas is tracked by GC.
INADA Naoki  <songofacandy at gmail.com>


On Tue, Nov 7, 2017 at 8:20 AM, Lukasz Langa <lukasz at langa.pl> wrote:
>
>
>> On Nov 5, 2017, at 11:28 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>> On 6 November 2017 at 16:36, Lukasz Langa <lukasz at langa.pl> wrote:
>>
>> - compile annotations like a small nested class body (but returning
>> the expression result, rather than None)
>> - emit MAKE_THUNK instead of the expression's opcodes
>> - emit STORE_ANNOTATION as usual
>>
>
> Is the motivation behind creating thunks vs. reusing lambdas just the difference in handling class-level scope? If so, would it be possible to just modify lambdas to behave thunk-like there? It sounds like this would strictly broaden the functionality of lambdas, in other words, wouldn't create backwards incompatibility for existing code.
>
> Reusing lambdas (with extending them to support class-level scoping) would be a less scary endeavor than introducing a brand new language construct.
>
> With my current understanding I still think stringification is both easier to implement and understand by end users. The main usability win of thunks/lambdas is not very significant: evaluating them is as easy as calling them whereas strings require typing.get_type_hints(). I still think being able to access function-local state at time of definition is only theoretically useful.
>
> What would be significant though is if thunk/lambdas helped fixing forward references in general. But I can't really see how that could work.
>
> - Ł
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/songofacandy%40gmail.com
>