TLDR: I really like this version, and the tweaks I suggest below are just cosmetic. I figure if there are any major technical traps lurking, you'll find them as you work through updating the reference implementation.
On 16 August 2017 at 09:55, Yury Selivanov <yselivanov...@gmail.com> wrote: > Context Item Object > ------------------- > > The ``sys.new_context_item(description)`` function creates a > new ``ContextItem`` object. The ``description`` parameter is a > ``str``, explaining the nature of the context key for introspection > and debugging purposes. > > ``ContextItem`` objects have the following methods and attributes: > > * ``.description``: read-only description; It may be worth having separate "name" and "description" attributes, similar to __name__ and __doc__ being separate on things like functions. That way, error messages can just show "name", while debuggers and other introspection tools can include a more detailed description. > Coroutine Object Modifications > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > To achieve this, a small set of modifications to the coroutine object > is needed: > > * New ``cr_local_context`` attribute. This attribute is readable > and writable for Python code. For ease of introspection, it's probably worth using a common `__local_context__` attribute name across all the different types that support one, and encouraging other object implementations to do the same. This isn't like cr_await and gi_yieldfrom, where we wanted to use different names because they refer to different kinds of objects. > Acknowledgments > =============== [snip] > Thanks to Nick Coghlan for numerous suggestions and ideas on the > mailing list, and for coming up with a case that cause the complete > rewrite of the initial PEP version [19]_. [snip] > .. [19] https://mail.python.org/pipermail/python-ideas/2017-August/046780.html The threading in pipermail makes it difficult to get from your reply back to my original comment, so it may be better to link directly to the latter: https://mail.python.org/pipermail/python-ideas/2017-August/046775.html And to be completely explicit about: I like your proposed approach of leaving it up to iterator developers to decide whether or not to run with a local context or not. If they don't manipulate any context items, it won't matter, and if they do, it's straightforward to add a suitable call to sys.run_in_local_context(). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
