(original) (raw)

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 <guido@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 <k7hoven@gmail.com> wrote:

On Jan 10, 2018 07:17, "Yury Selivanov" <yselivanov.ml@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 <k7hoven@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/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 +