Re: [Python-Dev] Thoughts on "contexts". PEPs 550, 555, 567, 568
I'll quickly add a few things below just in case there's anyone that cares. On Wed, Jan 10, 2018 at 2:06 AM, Koos Zevenhoven wrote: > > 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 > > Note here, that the point is to get a natural way to "undo" changes made to variables when exiting the scope. Undoing everything that is done within the defined scope is a very natural way to do it. Undoing individual .set(..) operations is more problematic. Features B+C could be essentially implemented as described in PEP 555, except with context_scope(cvar) being essentially the same as pushing and popping an empty Assignment object onto the reverse-linked stack. By empty, I mean a "key-value pair with a missing value". Then any set operations would replace the topmost assignment object for that variable with a new key-value pair (or push a new Assignment if there isn't one). However, to also get feature A, the stack may have to contain full mappings instead of assignemnt objects with just one key-value pair. I hope that clarifies some parts. Otherwise, in terms of semantics, the same things apply as for PEP 555 when it comes to generator function calls and next(..) etc., so we'd need to make sure it works well enough for all use cases. For instance, I'm not quite sure if I have a good enough understanding of the timeout example that Nathaniel wrote in the PEP 550 discussion to tell what would be required in terms of semantics, but I suppose it should be fine. -- Koos > 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 > > -- + 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
Re: [Python-Dev] Thoughts on "contexts". PEPs 550, 555, 567, 568
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 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
> 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
>> 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
>>> wrote:
>>>
On Jan 10, 2018 07:17, "Yury Selivanov"
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
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
>
> _
Re: [Python-Dev] Thoughts on "contexts". PEPs 550, 555, 567, 568
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 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 > 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 >> wrote: >> >>> On Jan 10, 2018 07:17, "Yury Selivanov" 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 >>> 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
Re: [Python-Dev] Thoughts on "contexts". PEPs 550, 555, 567, 568
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 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 > wrote: > >> On Jan 10, 2018 07:17, "Yury Selivanov" 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 >> 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/mailman/options/python-dev/guido% >> 40python.org >> >> > > > -- > --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
Re: [Python-Dev] Thoughts on "contexts". PEPs 550, 555, 567, 568
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 wrote: > On Jan 10, 2018 07:17, "Yury Selivanov" 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 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
Re: [Python-Dev] Thoughts on "contexts". PEPs 550, 555, 567, 568
On Jan 10, 2018 07:17, "Yury Selivanov" 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 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/ > 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/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Thoughts on "contexts". PEPs 550, 555, 567, 568
Wasn't PEP 555 rejected by Guido? What's the point of this post? Yury On Wed, Jan 10, 2018 at 4:08 AM Koos Zevenhoven 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/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/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Thoughts on "contexts". PEPs 550, 555, 567, 568
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/archive%40mail-archive.com
