[Python-Dev] Thoughts on "contexts". PEPs 550, 555, 567, 568

[Koos Zevenhoven]

The status of PEP 555 is just a side track. Here, I took a step back
compared to what went into PEP 555.

—Koos


On Wed, Jan 10, 2018 at 6:21 PM, Guido van Rossum <guido at python.org> wrote:

> The current status of PEP 555 is "Withdrawn". I have no interest in
> considering it any more, so if you'd rather see a decision from me I'll be
> happy to change it to "Rejected".
>
> On Tue, Jan 9, 2018 at 10:29 PM, Koos Zevenhoven <k7hoven at gmail.com>
> wrote:
>
>> On Jan 10, 2018 07:17, "Yury Selivanov" <yselivanov.ml at gmail.com> wrote:
>>
>> Wasn't PEP 555 rejected by Guido? What's the point of this post?
>>
>>
>> I sure hope there is a point. I don't think mentioning PEP 555 in the
>> discussions should hurt.
>>
>> A typo in my post btw: should be "PEP 567 (+568 ?)" in the second
>> paragraph of course.
>>
>> -- Koos (mobile)
>>
>>
>> Yury
>>
>> On Wed, Jan 10, 2018 at 4:08 AM Koos Zevenhoven <k7hoven at gmail.com>
>> wrote:
>>
>>> Hi all,
>>>
>>> I feel like I should write some thoughts regarding the "context"
>>> discussion, related to the various PEPs.
>>>
>>> I like PEP 567 (+ 567 ?) better than PEP 550. However, besides providing
>>> cvar.set(), I'm not really sure about the gain compared to PEP 555 (which
>>> could easily have e.g. a dict-like interface to the context). I'm still not
>>> a big fan of "get"/"set" here, but the idea was indeed to provide those on
>>> top of a PEP 555 type thing too.
>>>
>>> "Tokens" in PEP 567, seems to resemble assignment context managers in
>>> PEP 555. However, they feel a bit messy to me, because they make it look
>>> like one could just set a variable and then revert the change at any point
>>> in time after that.
>>>
>>> PEP 555 is in fact a simplification of my previous sketch that had a
>>> .set(..) in it, but was somewhat different from PEP 550. The idea was to
>>> always explicitly define the scope of contextvar values. A context manager
>>> / with statement determined the scope of .set(..) operations inside the
>>> with statement:
>>>
>>> # Version A:
>>> cvar.set(1)
>>> with context_scope():
>>>     cvar.set(2)
>>>
>>>     assert cvar.get() == 2
>>>
>>> assert cvar.get() == 1
>>>
>>> Then I added the ability to define scopes for different variables
>>> separately:
>>>
>>> # Version B
>>> cvar1.set(1)
>>> cvar2.set(2)
>>> with context_scope(cvar1):
>>>     cvar1.set(11)
>>>     cvar2.set(22)
>>>
>>> assert cvar1.get() == 1
>>> assert cvar2.get() == 22
>>>
>>>
>>> However, in practice, most libraries would wrap __enter__, set and
>>> __exit__ into another context manager. So maybe one might want to allow
>>> something like
>>>
>>> # Version C:
>>> assert cvar.get() == something
>>> with context_scope(cvar, 2):
>>>     assert cvar.get() == 2
>>>
>>> assert cvar.get() == something
>>>
>>>
>>> But this then led to combining "__enter__" and ".set(..)" into
>>> Assignment.__enter__ -- and "__exit__" into Assignment.__exit__ like this:
>>>
>>> # PEP 555 draft version:
>>> assert cvar.value == something
>>> with cvar.assign(1):
>>>     assert cvar.value == 1
>>>
>>> assert cvar.value == something
>>>
>>>
>>> Anyway, given the schedule, I'm not really sure about the best thing to
>>> do here. In principle, something like in versions A, B and C above could be
>>> done (I hope the proposal was roughly self-explanatory based on earlier
>>> discussions). However, at this point, I'd probably need a lot of help to
>>> make that happen for 3.7.
>>>
>>> -- Koos
>>>
>>> _______________________________________________
>>> Python-Dev mailing list
>>> Python-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/python-dev
>>> Unsubscribe: https://mail.python.org/mailma
>>> n/options/python-dev/yselivanov.ml%40gmail.com
>>>
>>
>>
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%
>> 40python.org
>>
>>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>



-- 
+ Koos Zevenhoven + http://twitter.com/k7hoven +
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180110/72a5fd4d/attachment-0001.html>