Re: [Python-Dev] PEP 567 v2

Do you see any average Python users on this thread? We are trying to pick the PEP apart from the POV of having to use the complicated parts of the API in a framework. Victor's questions are reasonable. On Tue, Jan 2, 2018 at 10:13 PM, Yury Selivanov wrote: > I don't want to expose a SetContext o

Re: [Python-Dev] PEP 567 v2

On Tue, Jan 2, 2018 at 4:51 PM, Victor Stinner wrote: > Why ContextVar.reset(token) does nothing at the second call with the same > token? What is the purpose of Token._used? I guess that there is an use > case to justify this behaviour. > > reset() should have a result: true if the variable was

Re: [Python-Dev] PEP 567 v2

On Tue, Jan 2, 2018 at 4:45 PM, Victor Stinner wrote: > Le 2 janv. 2018 18:57, "Guido van Rossum" a écrit : > > Oh, the "Specification" section in the PEP is too brief on several of > these subjects. It doesn't really specify what var.get() does if the value > is not set, nor does it even mentio

Re: [Python-Dev] PEP 567 v2

On Tue, Jan 2, 2018 at 5:30 PM, Victor Stinner wrote: > Hum, it seems like the specification (API) part of the PEP is polluted by > its implementation. The PEP just require a few minor changes to better > describe the behaviour/API instead of insisting on the read only internal > thing which is s

Re: [Python-Dev] PEP 567 v2

I don't want to expose a SetContext operation because of, again, potential incompatibility with PEP 550, where generators expect to fully control push/pop context operation. Second, Context.run is 100% enough for *any* async framework to add support for PEP 567. And because the PEP is focused just

Re: [Python-Dev] PEP 567 v2

On Wed, Jan 3, 2018 at 3:04 AM Victor Stinner wrote: > What is the behaviour of ContextVar.reset(token) if the token was created > from a different variable? Raise an exception? > > token = var1.set("value") > var2.reset(token) > > The PEP states that Token.var only exists for debug or introspect

Re: [Python-Dev] PEP 567 v2

On Wed, Jan 3, 2018 at 2:36 AM Victor Stinner wrote: > > I would really like to invite more people to review this PEP! I expect > I'll be accepting it in the next two weeks, but it needs to go through more > rigorous review. > > I read again the PEP and I am still very confused by Context.run().

Re: [Python-Dev] Concerns about method overriding and subclassing with dataclasses

Chris Barker writes: > are we only talking about __repr__ here ??? I am, because I haven't thought about the other methods, except to note I find it hard to imagine a use case *for me* that would require any of them. That sorta disqualifies me from comment. ;-) I assumed others were talking ab

Re: [Python-Dev] PEP 567 v2

Hum, it seems like the specification (API) part of the PEP is polluted by its implementation. The PEP just require a few minor changes to better describe the behaviour/API instead of insisting on the read only internal thing which is specific to the proposed implementation which is just one arbitra

Re: [Python-Dev] PEP 567 v2

What is the behaviour of ContextVar.reset(token) if the token was created from a different variable? Raise an exception? token = var1.set("value") var2.reset(token) The PEP states that Token.var only exists for debug or introspection. Victor Le 3 janv. 2018 00:51, "Victor Stinner" a écrit : W

Re: [Python-Dev] PEP 567 v2

PEP: "int PyContext_Enter(PyContext *) and int PyContext_Exit(PyContext *) allow to set and restore the context for the current OS thread." What is the difference between Enter and Exit? Why not having a single Py_SetContext() function? Victor ___ Pytho

Re: [Python-Dev] PEP 567 v2

Why ContextVar.reset(token) does nothing at the second call with the same token? What is the purpose of Token._used? I guess that there is an use case to justify this behaviour. reset() should have a result: true if the variable was restored to its previous state, false if reset() did nothing beca

Re: [Python-Dev] PEP 567 v2

Le 2 janv. 2018 18:57, "Guido van Rossum" a écrit : Oh, the "Specification" section in the PEP is too brief on several of these subjects. It doesn't really specify what var.get() does if the value is not set, nor does it even mention var.get() except in the code examples for var.reset(). It's als

Re: [Python-Dev] PEP 567 v2

> I would really like to invite more people to review this PEP! I expect I'll be accepting it in the next two weeks, but it needs to go through more rigorous review. I read again the PEP and I am still very confused by Context.run(). The PEP states multiple times that a context is immutable: * "

Re: [Python-Dev] 'continue'/'break'/'return' inside 'finally' clause

Serhiy Storchaka wrote: > Currently 'break' and 'return' are never used inside 'finally' > clause in the stdlib. See the _recv_bytes() function: Lib/multiprocessing/connection.py: 316 > I would want to see a third-party code that uses them. These are the only ones I found so far: ./gevent/src

[Python-Dev] Unique loader per module

We have what I think is one last design question for importlib.resources. https://gitlab.com/python-devs/importlib_resources/issues/49 The problem is that the ResourceReader ABC omits the package from the function signatures, so that on a compatible loader, you only need to specify the resource

Re: [Python-Dev] PEP 567 v2

Oh, the "Specification" section in the PEP is too brief on several of these subjects. It doesn't really specify what var.get() does if the value is not set, nor does it even mention var.get() except in the code examples for var.reset(). It's also subtle that ctx[var] returns the default (if there i

Re: [Python-Dev] [ssl] The weird case of IDNA

> On 31 Dec 2017, at 18:07, Nathaniel Smith wrote: > > On Dec 31, 2017 7:37 AM, "Stephen J. Turnbull" > > wrote: > Nathaniel Smith writes: > > > Issue 1: Python's built-in IDNA implementation is wrong (implements > > IDNA 2003, not IDNA 2008). >