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

2017-11-25 Thread Ethan Furman
On 11/25/2017 04:20 PM, David Mertz wrote: On Sat, Nov 25, 2017 at 3:37 PM, Guido van Rossum wrote: Maybe you didn't realize async/await don't need an event loop? Driving an async/await-based coroutine is just as simple as driving a yield-from-based one (`await` does exactly the same thing

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

2017-11-25 Thread Carl Meyer
Hi Eric, Really excited about this PEP, thanks for working on it. A couple minor questions: > If compare is True, then eq is ignored, and __eq__ and __ne__ will be automatically generated. IMO it's generally preferable to make nonsensical parameter combinations an immediate error, rather than

Re: [Python-Dev] Allow tuple unpacking in return and yield statements

2017-11-25 Thread Nick Coghlan
On 26 November 2017 at 09:22, Terry Reedy wrote: > Since return and yield are often the first half of a cross-namespace > assignment, requiring the () is a bit surprising. Perhaps someone else has > a good reason for the difference. These kinds of discrepancies tend to arise

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

2017-11-25 Thread Nick Coghlan
On 26 November 2017 at 02:59, Guido van Rossum wrote: > > I'd be happy to stop with the conclusion that we're going to rip out some > confusing syntax rather than trying to generate code for it -- IMO we've > proved to ourselves that this stuff is too complicated to be useful.

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

2017-11-25 Thread Eric V. Smith
One more change: - Per-field metadata, for use by third parties. Also, thanks to Guido and Ivan for all of their feedback on the various issues that got the PEP to this point. Eric. On 11/25/2017 4:06 PM, Eric V. Smith wrote: The updated version should show up at

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

2017-11-25 Thread David Mertz
On Sat, Nov 25, 2017 at 3:37 PM, Guido van Rossum wrote: > Maybe you didn't realize async/await don't need an event loop? Driving an > async/await-based coroutine is just as simple as driving a yield-from-based > one (`await` does exactly the same thing as `yield from`). > I

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

2017-11-25 Thread Guido van Rossum
On Sat, Nov 25, 2017 at 3:24 PM, Greg Ewing wrote: > Nick Coghlan wrote: > > def example(): >> comp1 = yield from [(yield x) for x in ('1st', '2nd')] >> comp2 = yield from [(yield x) for x in ('3rd', '4th')] >> return comp1, comp2 >> > >

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

2017-11-25 Thread Greg Ewing
Serhiy Storchaka wrote: Ivan explained that this function should be rough equivalent to def f(): t = [(yield i) for i in range(3)] return (x for x in t) This is a *rough* equivalent. There are differences in details. The details would seem to be overwhelmingly important,

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

2017-11-25 Thread Guido van Rossum
On Sat, Nov 25, 2017 at 1:05 PM, David Mertz wrote: > FWIW, on a side point. I use 'yield' and 'yield from' ALL THE TIME in real > code. Probably 80% of those would be fine with yield statements, but a > significant fraction use `gen.send()`. > > On the other hand, I have yet

Re: [Python-Dev] Allow tuple unpacking in return and yield statements

2017-11-25 Thread Guido van Rossum
I think the proposal is reasonable and won't require a PEP. On Nov 25, 2017 3:25 PM, "Terry Reedy" wrote: > On 11/25/2017 1:55 AM, David Cuthbert wrote: > >> First time contributing back -- if I should be filing a PEP or something >> like that for this, please let me know. >>

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

2017-11-25 Thread Greg Ewing
Nick Coghlan wrote: def example(): comp1 = yield from [(yield x) for x in ('1st', '2nd')] comp2 = yield from [(yield x) for x in ('3rd', '4th')] return comp1, comp2 If the implicit "yield from" idea seems too magical, then the other direction we could go is to

Re: [Python-Dev] Allow tuple unpacking in return and yield statements

2017-11-25 Thread Terry Reedy
On 11/25/2017 1:55 AM, David Cuthbert wrote: First time contributing back -- if I should be filing a PEP or something like that for this, please let me know. I don't think a PEP is needed. Coming from https://bugs.python.org/issue32117, unparenthesized tuple unpacking is allowed in

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

2017-11-25 Thread Yury Selivanov
On Sat, Nov 25, 2017 at 3:27 PM, Guido van Rossum wrote: > On Sat, Nov 25, 2017 at 9:21 AM, Yury Selivanov > wrote: >> >> So we are keeping asynchronous generator expressions as long as they are >> defined in an 'async def' coroutine? > > > I would be

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

2017-11-25 Thread Eric V. Smith
The updated version should show up at https://www.python.org/dev/peps/pep-0557/ shortly. The major changes from the previous version are: - Add InitVar to specify initialize-only fields. - Renamed __dataclass_post_init__() to __post_init(). - Rename cmp to compare. - Added eq, separate from

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

2017-11-25 Thread David Mertz
FWIW, on a side point. I use 'yield' and 'yield from' ALL THE TIME in real code. Probably 80% of those would be fine with yield statements, but a significant fraction use `gen.send()`. On the other hand, I have yet once to use 'await', or 'async' outside of pedagogical contexts. There are a whole

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

2017-11-25 Thread Guido van Rossum
> > On Sat, Nov 25, 2017 at 12:17 PM Brett Cannon wrote: > On Fri, Nov 24, 2017, 19:32 Guido van Rossum, wrote: >> >>> On Fri, Nov 24, 2017 at 4:22 PM, Guido van Rossum >>> wrote: >>> The more I hear about this topic, the more I think

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

2017-11-25 Thread Yury Selivanov
So we are keeping asynchronous generator expressions as long as they are defined in an 'async def' coroutine? Yury On Sat, Nov 25, 2017 at 12:17 PM Brett Cannon wrote: > > > On Fri, Nov 24, 2017, 19:32 Guido van Rossum, wrote: > >> On Fri, Nov 24, 2017 at

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

2017-11-25 Thread Brett Cannon
On Fri, Nov 24, 2017, 19:32 Guido van Rossum, wrote: > On Fri, Nov 24, 2017 at 4:22 PM, Guido van Rossum > wrote: > >> The more I hear about this topic, the more I think that `await`, `yield` >> and `yield from` should all be banned from occurring in all

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

2017-11-25 Thread Guido van Rossum
On Sat, Nov 25, 2017 at 8:07 AM, Ivan Levkivskyi wrote: > On 25 November 2017 at 16:57, Guido van Rossum wrote: > >> On Sat, Nov 25, 2017 at 6:55 AM, Ivan Levkivskyi >> wrote: >> >>> On 25 November 2017 at 04:30, Guido van Rossum

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

2017-11-25 Thread Ivan Levkivskyi
On 25 November 2017 at 16:57, Guido van Rossum wrote: > On Sat, Nov 25, 2017 at 6:55 AM, Ivan Levkivskyi > wrote: > >> On 25 November 2017 at 04:30, Guido van Rossum wrote: >> >>> On Fri, Nov 24, 2017 at 4:22 PM, Guido van Rossum

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

2017-11-25 Thread Guido van Rossum
On Sat, Nov 25, 2017 at 6:55 AM, Ivan Levkivskyi wrote: > On 25 November 2017 at 04:30, Guido van Rossum wrote: > >> On Fri, Nov 24, 2017 at 4:22 PM, Guido van Rossum >> wrote: >> >>> The more I hear about this topic, the more I think

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

2017-11-25 Thread Antoine Pitrou
At this point, the fact that several Python core developers fail to understand the pieces of code presented as examples should be a hint that the syntax here is far from desirable... Regards Antoine. On Sat, 25 Nov 2017 15:47:14 + Paul Moore wrote: > On 25 November

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

2017-11-25 Thread Paul Moore
On 25 November 2017 at 14:55, Ivan Levkivskyi wrote: > Continuing the topic of the ban, what exactly should be banned? For example > will this still be valid? > > def pack_two(): > return [(yield), (yield)] # Just a list display > > I don't see how this is

[Python-Dev] Allow tuple unpacking in return and yield statements

2017-11-25 Thread David Cuthbert
First time contributing back -- if I should be filing a PEP or something like that for this, please let me know. Coming from https://bugs.python.org/issue32117, unparenthesized tuple unpacking is allowed in assignments: rest = (4, 5, 6) a = 1, 2, 3, *rest but not in yield or return

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

2017-11-25 Thread Ivan Levkivskyi
On 25 November 2017 at 04:30, Guido van Rossum wrote: > On Fri, Nov 24, 2017 at 4:22 PM, Guido van Rossum > wrote: > >> The more I hear about this topic, the more I think that `await`, `yield` >> and `yield from` should all be banned from occurring in all

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

2017-11-25 Thread Serhiy Storchaka
24.11.17 00:20, Greg Ewing пише: Serhiy Storchaka wrote: Ivan explained that this function should be rough equivalent to    def f():    t = [(yield i) for i in range(3)]    return (x for x in t) This seems useless to me. It turns a lazy iterator into an eager one, which is a gross

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

2017-11-25 Thread Serhiy Storchaka
24.11.17 02:50, Nick Coghlan пише: If we went down that path, then a list comprehension like the following:     results = [(yield future) for future in list_of_futures] might be compiled as being equivalent to:     def __listcomp_generator(iterable):     result = []     for future