(original) (raw)
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 <guido@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 <k7hoven@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--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@gmail.com> wrote:Unsubscribe: https://mail.python.org/mailmaOn Jan 10, 2018 07:17, "Yury Selivanov" <yselivanov.ml@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)YuryOn Wed, Jan 10, 2018 at 4:08 AM Koos Zevenhoven <k7hoven@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() == 2assert cvar.get() == 1Then I added the ability to define scopes for different variables separately:# Version Bcvar1.set(1)cvar2.set(2)with context\_scope(cvar1):cvar1.set(11)cvar2.set(22)assert cvar1.get() == 1assert cvar2.get() == 22However, 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() == somethingwith context\_scope(cvar, 2):assert cvar.get() == 2assert cvar.get() == somethingBut 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 == somethingwith cvar.assign(1):assert cvar.value == 1assert cvar.value == somethingAnyway, 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/mailman/options/python-dev/yselivano v.ml%40gmail.com
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev n/options/python-dev/guido%40p ython.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 +