On Wed, Aug 16, 2017 at 4:07 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > TLDR: I really like this version, and the tweaks I suggest below are > just cosmetic.
Thanks, Nick! > I figure if there are any major technical traps > lurking, you'll find them as you work through updating the reference > implementation. FWIW I've implemented 3-5 different variations of PEP 550 (along with HAMT) and I'm fairly confident that datastructures and optimizations will work, so no major traps there are really expected. The risk that we need to manage now is getting the API design "right". > > 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. Initially I wanted to have "sys.new_context_item(name)" signature, but then I thought that some users might be confused what "name" actually means. In some contexts you might say that the "name" of the CI is the name of the variable it is bound to, IOW, for "foo = CI(name="bar")' the name is "foo". But some users might think that it's "bar". OTOH, PEP 550 doesn't have any introspection APIs at this point, and the final version of it will have to have them. If we add something like "sys.get_execution_context_as_dict()", then it would be preferable for CIs to have short name-like descriptions, as opposed to multiline docstrings. So in the end, I think that we should adopt a namedtuple solution, and just make the first "ContextItem" parameter a positional-only "name": ContextItem(name: str, /) > >> 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. We also have cr_code and gi_code, which are used for introspection purposes but refer to CodeObject. I myself don't like the mess the C-style convention created for our Python code (think of what the "dis" and "inspect" modules have to go through), so I'm +0 for having "__local_context__". > >> 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(). Fixed the link, and will update the Acknowledgments section with your paragraph (thanks!) Yury _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
