[Python-Dev] Thoughts on "contexts". PEPs 550, 555, 567, 568

Koos Zevenhoven k7hoven at gmail.com
Tue Jan 9 19:06:06 EST 2018


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180110/fc834f49/attachment.html>


More information about the Python-Dev mailing list