> 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. - Ł
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ 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
