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 <songofaca...@gmail.com> On Tue, Nov 7, 2017 at 8:20 AM, Lukasz Langa <luk...@langa.pl> wrote: > > >> On Nov 5, 2017, at 11:28 PM, Nick Coghlan <ncogh...@gmail.com> wrote: >> >> On 6 November 2017 at 16:36, Lukasz Langa <luk...@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@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/songofacandy%40gmail.com > _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
