The timing of all of this is unfortunate. I'm sorry that my participation
in the discussion has been a bit "on-off" lately. But my recent
contributions have involved studying things like the interaction of
threading/concurrency aspects of signal handling, as well as investigating
subtleties of various proposals for context variables, including my own.
Those are not exactly low-hanging fruit, and I'm sorry about not being able
to eat them.
It is also unfortunate that I haven't written down this proposal
("versions" A-C) to anywhere near the amount of precision than I did for
PEP 555, which wasn't 100% specified in the first draft either. For
consideration, I just thought it's better to at least mention it, so that
those that now have a good understanding of the issues involved could
perhaps understand it. I can add more detail, but to make it a full
proposal now, I would probably need to join forces with a coauthor (with a
good understanding of these issues) to figure out missing parts. I could
tune in later to finish the PEP and write docs in case the approach gets
implemented.
-- Koos
On Wed, Jan 10, 2018 at 7:17 PM, Guido van Rossum <gu...@python.org> wrote:
> 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 <k7ho...@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 <gu...@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 <k7ho...@gmail.com>
>>> wrote:
>>>
>>>> On Jan 10, 2018 07:17, "Yury Selivanov" <yselivanov...@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 <k7ho...@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@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@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)
>
--
+ Koos Zevenhoven + http://twitter.com/k7hoven +
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
