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
a
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 si
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 because there are a
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.
I'll also note that
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
https://www.python.org/dev
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 realize I *can*, but
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
>>
>
> If the implicit "yield from" id
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, tho
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 once to use 'await',
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.
>>
>
> I don't think a
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 make
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 assignme
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 happy to declare that `await` is out of scope
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 com
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
>
> 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 that `await`,
`yield` and `yield from` should all b
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 4:22 PM, Guido van Rossum
>> 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 that `await`, `yield`
>> and `yield from` should all be banned from occurring in all comprehensions
>> and generator expressio
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 wrote:
>>>
On Fri, Nov 24, 2017 at 4:22 PM, Guido van Rossu
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
>>> wrote:
>>>
The more I hear about this topic, the more I
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 that `await`, `yield`
>>> and `yield from` should all be ban
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 2017 at 14:55, Ivan Lev
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 controversial. It is clear t
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 sta
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 comprehensions
>> and generator expressi
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 vio
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
27 matches
Mail list logo
