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
