On Sat, Aug 12, 2017 at 2:28 PM, rym...@gmail.com <rym...@gmail.com> wrote:
> So, I'm hardly an expert when it comes to things like this, but there are
> two things about this that don't seem right to me. (Also, I'd love to
> respond inline, but that's kind of difficult from a mobile phone.)
> The first is how set/get_execution_context_item take strings. Inevitably,
> people are going to do things like:

Yes, it accepts any hashable Python object as a key.

> CONTEXT_ITEM_NAME = 'foo-bar'
> ...
> sys.set_execution_context_item(CONTEXT_ITEM_NAME, 'stuff')
> IMO it would be nicer if there could be a key object used instead, e.g.
> my_key = sys.execution_context_key('name-here-for-debugging-purposes')
> sys.set_execution_context_item(my_key, 'stuff')

I thought about this, and decided that this is something that can be
easily designed on top of the PEP and put to the 'contextlib' module.

In practice, this issue can be entirely addressed in the
documentation, asking users to prefix their keys with their
library/framework/program name.

> The advantage here would be no need for string constants and no potential
> naming conflicts (the string passed to the key creator would be used just
> for debugging, kind of like Thread names).
> Second thing is this:
> def context(x):
>     old_x = get_execution_context_item('x')
>     set_execution_context_item('x', x)
>     try:
>         yield
>     finally:
>         set_execution_context_item('x', old_x)
> If this would be done frequently, a context manager would be a *lot* more
> Pythonic, e.g.:
> with sys.temp_change_execution_context('x', new_x):
>     # ...

Yes, this is a neat idea and I think we can add such a helper to
contextlib.  I want to focus PEP 550 API on correctness, minimalism,
and performance.  Nice APIs can then be easily developed on top of it

Python-ideas mailing list
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to