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/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 > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > guido%40python.org > > -- --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