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)
_______________________________________________ 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
