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

[Guido van Rossum]

I'm sorry, Koos, but based on your past contributions I am not interested
in discussing this topic with you.

On Wed, Jan 10, 2018 at 8:58 AM, Koos Zevenhoven <k7hoven at gmail.com> wrote:

> 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/mailma
>>> n/options/python-dev/guido%40python.org
>>>
>>>
>>
>>
>> --
>> --Guido van Rossum (python.org/~guido)
>>
>
>
>
> --
> + Koos Zevenhoven + http://twitter.com/k7hoven +
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180110/9f03b9ee/attachment.html>