Re: [Python-Dev] Using async/await in place of yield expression

On Sun, Nov 26, 2017 at 9:33 PM, Caleb Hattingh wrote: > The PEP only says that __await__ must return an iterator, but it turns out > that it's also required that that iterator > should not return any intermediate values. I think you're confused :-). When the iterator yields an intermediate value

Re: [Python-Dev] Using async/await in place of yield expression

On Mon, 27 Nov 2017 00:41:55 -0800 Nathaniel Smith wrote: > > Since most libraries assume that they control both __await__ and the > coroutine runner, they don't tend to give great error messages here > (though trio does [2] ;-)). I think this is also why the asyncio docs > don't talk about this.

Re: [Python-Dev] Using async/await in place of yield expression

Hello, On Mon, 27 Nov 2017 15:33:51 +1000 Caleb Hattingh wrote: [] > The PEP only says that __await__ must return an iterator, but it > turns out that it's also required that that iterator > should not return any intermediate values. This requirement is only > enforced in the event loop, not >

Re: [Python-Dev] Second post: PEP 557, Data Classes

On 11/27/2017 1:04 AM, Nick Coghlan wrote: On 27 November 2017 at 15:04, Greg Ewing wrote: Nick Coghlan wrote: Perhaps the check could be: (type(lhs) == type(rhs) or fields(lhs) == fields(rhs)) and all (individual fields match) I think the types should *always* have to match, or at lea

Re: [Python-Dev] Using async/await in place of yield expression

On 27 November 2017 at 18:41, Nathaniel Smith wrote: > > In asyncio, the convention is that the values you send back must be > Future objects, Thanks this is useful. I didn't pick this up from the various PEPs or documentation. I guess I need to go through the src :) ___

Re: [Python-Dev] Second post: PEP 557, Data Classes

On 25.11.2017 22:06, Eric V. Smith wrote: The updated version should show up at https://www.python.org/dev/peps/pep-0557/ shortly. This PEP looks very promising and will make my life quite a bit easier, since we are using a pattern involving data classes. Currently, we write the constructor b

Re: [Python-Dev] Second post: PEP 557, Data Classes

On 11/27/2017 6:01 AM, Sebastian Rittau wrote: On 25.11.2017 22:06, Eric V. Smith wrote: The major changes from the previous version are: - Add InitVar to specify initialize-only fields. This is the only feature that does not sit right with me. It looks very obscure and "hacky". From what

Re: [Python-Dev] Second post: PEP 557, Data Classes

On 27.11.2017 12:01, Sebastian Rittau wrote: The major changes from the previous version are: - Add InitVar to specify initialize-only fields. This is the only feature that does not sit right with me. It looks very obscure and "hacky". From what I understand, we are supposed to use the fi

Re: [Python-Dev] Second post: PEP 557, Data Classes

On 27.11.2017 13:23, Eric V. Smith wrote: I had something like your suggestion half coded up, except I inspected the args to __post_init__() and added them to __init__, avoiding the API-unfriendly *args and **kwargs. I understand your concerns with *args and **kwargs. I think we need to find a

Re: [Python-Dev] Second post: PEP 557, Data Classes

On 11/27/2017 7:31 AM, Sebastian Rittau wrote: On 27.11.2017 13:23, Eric V. Smith wrote: I had something like your suggestion half coded up, except I inspected the args to __post_init__() and added them to __init__, avoiding the API-unfriendly *args and **kwargs. I understand your concerns with

Re: [Python-Dev] Second post: PEP 557, Data Classes

On 11/27/2017 7:26 AM, Sebastian Rittau wrote: On 27.11.2017 12:01, Sebastian Rittau wrote: The major changes from the previous version are: - Add InitVar to specify initialize-only fields. This is the only feature that does not sit right with me. It looks very obscure and "hacky". From w

Re: [Python-Dev] Second post: PEP 557, Data Classes

Chris Angelico wrote: I'm not sure there's any distinction between a "point" and a "vector from the origin to a point". They transform differently. For example, translation affects a point, but makes no difference to a vector. There are two ways of dealing with that. One is to use vectors to r

Re: [Python-Dev] Second post: PEP 557, Data Classes

On 11/27/17 10:51 AM, Guido van Rossum wrote: Following up on this subthread (inline below). On Mon, Nov 27, 2017 at 2:56 AM, Eric V. Smith mailto:e...@trueblade.com>> wrote: On 11/27/2017 1:04 AM, Nick Coghlan wrote: On 27 November 2017 at 15:04, Greg Ewing mailto:greg.ew.

Re: [Python-Dev] Second post: PEP 557, Data Classes

Following up on this subthread (inline below). On Mon, Nov 27, 2017 at 2:56 AM, Eric V. Smith wrote: > On 11/27/2017 1:04 AM, Nick Coghlan wrote: > >> On 27 November 2017 at 15:04, Greg Ewing >> wrote: >> >>> Nick Coghlan wrote: >>> Perhaps the check could be: (type(lhs)

Re: [Python-Dev] Second post: PEP 557, Data Classes

Sounds good. On Nov 27, 2017 8:00 AM, "Eric V. Smith" wrote: > On 11/27/17 10:51 AM, Guido van Rossum wrote: > >> Following up on this subthread (inline below). >> >> On Mon, Nov 27, 2017 at 2:56 AM, Eric V. Smith > > wrote: >> >> On 11/27/2017 1:04 AM, Nick Coghla

[Python-Dev] generator vs iterator etc. (was: How assignment should work with generators?)

On Mon, Nov 27, 2017 at 3:55 PM, Steven D'Aprano wrote: > On Mon, Nov 27, 2017 at 12:17:31PM +0300, Kirill Balunov wrote: > ​​ > > > 2. Should this work only for generators or for any iterators? > > I don't understand why you are even considering singling out *only* > generators. A generator is

Re: [Python-Dev] Using async/await in place of yield expression

On Mon, Nov 27, 2017 at 1:12 AM, Antoine Pitrou wrote: > On Mon, 27 Nov 2017 00:41:55 -0800 > Nathaniel Smith wrote: > > > > Since most libraries assume that they control both __await__ and the > > coroutine runner, they don't tend to give great error messages here > > (though trio does [2] ;-))

Re: [Python-Dev] Using async/await in place of yield expression

On Sun, Nov 26, 2017 at 7:43 PM, Chris Angelico wrote: > Honestly, this is one of Python's biggest problems when it comes to > async functions. I don't know the answer to that question, and I don't > know where in the docs I'd go looking for it. In JavaScript, async > functions are built on top o

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

I need to cut this debate short (too much to do already) but I'd like to press that I wish async/await to be available for general tinkering (like writing elegant parsers), not just for full fledged event loops. -- --Guido van Rossum (python.org/~guido) ___

[Python-Dev] Can Python guarantee the order of keyword-only parameters?

First, a thirty-second refresher, so we're all using the same terminology: A *parameter* is a declared input variable to a function. An *argument* is a value passed into a function.  (*Arguments* are stored in *parameters.*) So in the example "def foo(clonk): pass; foo(3)", clonk i

Re: [Python-Dev] Can Python guarantee the order of keyword-only parameters?

Plus 1 from me. I'm not 100% sure the signature / inspect backport does this, but as you say, it should be trivial to do, to whatever extent the python version we're hosted on does it. Rob On 28 Nov. 2017 07:14, "Larry Hastings" wrote: > > > First, a thirty-second refresher, so we're all using

Re: [Python-Dev] Can Python guarantee the order of keyword-only parameters?

On 11/27/2017 12:19 PM, Robert Collins wrote: Plus 1 from me. I'm not 100% sure the signature / inspect backport does this, but as you say, it should be trivial to do, to whatever extent the python version we're hosted on does it. I'm not sure exactly what you mean when you say "signature / i

Re: [Python-Dev] Using async/await in place of yield expression

Guido van Rossum wrote: The source for sleep() isn't very helpful -- e.g. @coroutine is mostly a backwards compatibility thing. So how are you supposed to write that *without* using @coroutine? -- Greg ___ Python-Dev mailing list Python-Dev@python.o

Re: [Python-Dev] Using async/await in place of yield expression

On Mon, Nov 27, 2017 at 1:58 PM, Greg Ewing wrote: > Guido van Rossum wrote: > >> The source for sleep() isn't very helpful -- e.g. @coroutine is mostly a >> backwards compatibility thing. >> > > So how are you supposed to write that *without* using @coroutine? > A simplified version using async

Re: [Python-Dev] Can Python guarantee the order of keyword-only parameters?

On Mon, Nov 27, 2017 at 10:13 AM Larry Hastings wrote: > > > First, a thirty-second refresher, so we're all using the same terminology: > > A *parameter* is a declared input variable to a function. > An *argument* is a value passed into a function. (*Arguments* are stored > in *parameters.*) > >

Re: [Python-Dev] Can Python guarantee the order of keyword-only parameters?

On Mon, Nov 27, 2017 at 10:05 AM, Larry Hastings wrote: > I'd like inspect.signature to guarantee that the order of keyword-only > parameters always matches the order they were declared in. Technically this > isn't a language feature, it's a library feature. But making this guarantee > would req

Re: [Python-Dev] PEP 565: show DeprecationWarning in __main__ (round 2)

I am basically in agreement with this now. Some remarks: - I would recommend adding a note to the abstract about the recommendation for test runners to also enable these warnings by default. - In some sense, simple scripts that are distributed informally (e.g. as email attachments or via shared d

Re: [Python-Dev] Can Python guarantee the order of keyword-only parameters?

On Mon, Nov 27, 2017 at 12:05 PM, Larry Hastings wrote: [..] > The PEP for > inspect.signature (PEP 362) says that when comparing two signatures for > equality, their positional and positional-or-keyword parameters must be in > the same order. It makes a point of *not* requiring that the two func

[Python-Dev] 3.7.0a3 cutoff extended a week to 12-04

We are extending the cutoff for the next 3.7 alpha preview (3.7.0a3) a week, moving it from today to 12-04 12:00 UTC. The main reason is a selfish one: I have been traveling and mainly offline for the last few weeks and I am still catching up with activity. Since we are getting close to featur

Re: [Python-Dev] Can Python guarantee the order of keyword-only parameters?

On 11/27/2017 03:58 PM, Yury Selivanov wrote: We can't say anything about the order if someone passes a partial object Sure we could.  We could ensure that functools.partial behaves in a sane way, then document and guarantee that behavior. or sets custom Signature objects to func.__signa

Re: [Python-Dev] Using async/await in place of yield expression

On 11/27/2017 5:05 PM, Guido van Rossum wrote: On Mon, Nov 27, 2017 at 1:58 PM, Greg Ewing > wrote: Guido van Rossum wrote: The source for sleep() isn't very helpful -- e.g. @coroutine is mostly a backwards compatibility thing. So how

Re: [Python-Dev] Second post: PEP 557, Data Classes

On 11/27/2017 10:51 AM, Guido van Rossum wrote: Following up on this subthread (inline below). Didn't we at one point have something like isinstance(other, self.__class__) and fields(other) == fields(self) and (plus some optimization if the types are identical)? That feels ideal, because

Re: [Python-Dev] PEP 565: show DeprecationWarning in __main__ (round 2)

25.11.17 07:33, Nick Coghlan пише: * ``FutureWarning``: always reported by default. The intended audience is users of applications written in Python, rather than other Python developers (e.g. warning about use of a deprecated setting in a configuration file format). Given its presence i