On 6 December 2014 at 04:42, Guido van Rossum wrote:
> For those who haven't followed along, here's the final text of PEP 479, with
> a brief Acceptance section added. The basic plan hasn't changed, but there's
> a lot more clarifying text and discussion of a few counter-proposals. Please
> send s
For those who haven't followed along, here's the final text of PEP 479,
with a brief Acceptance section added. The basic plan hasn't changed, but
there's a lot more clarifying text and discussion of a few
counter-proposals. Please send suggestions for editorial improvements to
p...@python.org. The
On 30 November 2014 at 12:31, Chris Angelico wrote:
> On Sun, Nov 30, 2014 at 1:04 PM, Jim J. Jewett wrote:
>> (4) It can happen because of "yield from" yielding from an iterator,
>> rather than a generator?
>
> No; as I understand it (though maybe I'm wrong too), "yield from" will
> yield every
On Sun, Nov 30, 2014 at 1:04 PM, Jim J. Jewett wrote:
> I have a strong suspicion that I'm missing something; I have been
> persuaded both directions too often to believe I have a grip on the
> real issue.
>
> So I'm putting out some assumptions; please tell me if I'm wrong, and
> maybe make them
I have a strong suspicion that I'm missing something; I have been
persuaded both directions too often to believe I have a grip on the
real issue.
So I'm putting out some assumptions; please tell me if I'm wrong, and
maybe make them more explicit in the PEP.
(1) The change will only affect situat
On Sat, Nov 29, 2014 at 9:07 AM, Nick Coghlan wrote:
> Guido wrote a specific micro-benchmark for that case in one of the
> other threads. On his particular system, the overhead was around 150
> ns per link in the chain at the point the data processing pipeline was
> shut down. In most scenarios
On 30 November 2014 at 02:45, Olemis Lang wrote:
> On 11/28/14, Guido van Rossum wrote:
> [...]
>>
>> @Olemis: You never showed examples of how your code would be used, so it's
>> hard to understand what you're trying to do and how PEP 479 affects you.
>>
>
> The intention is not to restart the d
On 11/28/14, Guido van Rossum wrote:
[...]
>
> @Olemis: You never showed examples of how your code would be used, so it's
> hard to understand what you're trying to do and how PEP 479 affects you.
>
The intention is not to restart the debate . PEP is approved , it's
done ... but ...
as a side-e
@Victor: I'm glad you found a work-around. Maybe you can let your users
control it with a flag? It is often true that straddling code pays a
performance cost. Hopefully the slight performance dip might be an
incentive for people to start thinking about porting to asyncio.
@Olemis: You never showed
correction ...
On 11/28/14, Olemis Lang wrote:
>
> try:
>...
> except RuntimeError:
>return
>
... should be
{{{#!py
# inside generator function body
try:
...
except StopIteration:
return
}}}
[...]
--
Regards,
Olemis - @olemislc
Apache(tm) Bloodhound contributor
http://issue
off-topic , not about asyncio but related to the PEP and other things
been discussed in this thread
On 11/28/14, Victor Stinner wrote:
> 2014-11-28 3:49 GMT+01:00 Nick Coghlan :
>
[...]
>
> So yes, it may help to have a new specialized exception, even if "it
> works" with RuntimeError.
>
This is
2014-11-28 3:49 GMT+01:00 Nick Coghlan :
> I think between contextlib and Trollius, the case is starting to be
> made for raising an UnhandledStopIteration subclass of RuntimeError,
> rather than a generic RuntimeError.
I modified Trollius to test such idea:
* Return inherits from Exception (not
On Fri, Nov 28, 2014 at 8:18 PM, Victor Stinner
wrote:
> 2014-11-28 10:12 GMT+01:00 Greg Ewing :
>> I don't understand. If I'm interpreting PEP 479 correctly, in
>> 'x = yield from foo', a StopIteration raised by foo.__next__()
>> doesn't get turned into a RuntimeError
>
> The Trollius coroutine u
2014-11-28 10:12 GMT+01:00 Greg Ewing :
> I don't understand. If I'm interpreting PEP 479 correctly, in
> 'x = yield from foo', a StopIteration raised by foo.__next__()
> doesn't get turned into a RuntimeError
The Trollius coroutine uses "raise Return(value)" which is basically a
"raise StopIterat
Guido van Rossum wrote:
The issue here is that asyncio only interprets StopIteration as
returning from the generator (with a possible value), while a Trollius
coroutine must use "raise Return()" to specify a return value;
this works as long as Return is a subclass of StopIteration, but PEP 479
On 28 November 2014 at 08:09, Victor Stinner wrote:
> 2014-11-27 22:54 GMT+01:00 Victor Stinner :
>> I don't see how it would work.
>
> If it cannot be fixed, would it make sense to allow trollius to
> continue to work as it currently works with something like "from
> __past__ import generator_don
On Fri, Nov 28, 2014 at 8:54 AM, Victor Stinner
wrote:
> def return_value(value):
> if 0:
> yield
> raise Return(value)
This is one known significant backward-incompatibility issue with this
PEP - it'll be difficult to make this work on Python 2.7, where
"return value" would be a
2014-11-27 22:54 GMT+01:00 Victor Stinner :
> I don't see how it would work.
If it cannot be fixed, would it make sense to allow trollius to
continue to work as it currently works with something like "from
__past__ import generator_dont_stop"?
When I talked with a friend about the transition from
2014-11-27 20:06 GMT+01:00 Guido van Rossum :
> The issue here is that asyncio only interprets StopIteration as returning
> from the generator (with a possible value),
I'm not sure that the issue is directly related to asyncio.
trollius_coro() raises a StopIteration to return the result to caller
On Thu, Nov 27, 2014 at 10:08 AM, Victor Stinner
wrote:
> I'm trying to follow the discussion about the PEP 479 (Change
> StopIteration handling inside generators), but it's hard to read all
> messages. I'm concerned by trollius and asyncio which heavily rely on
> StopIteration.
>
> Trollius curr
Hi,
I'm trying to follow the discussion about the PEP 479 (Change
StopIteration handling inside generators), but it's hard to read all
messages. I'm concerned by trollius and asyncio which heavily rely on
StopIteration.
Trollius currently supports running asyncio coroutines: a trollius
coroutine
On 27 November 2014 at 09:50, Guido van Rossum wrote:
> On Wed, Nov 26, 2014 at 3:15 PM, Nick Coghlan wrote:
>> This is actually the second iteration of this bug: the original
>> implementation *always* suppressed StopIteration. PJE caught that one before
>> Python 2.5 was released, but we didn't
On Thu, Nov 27, 2014 at 8:57 AM, Isaac Schwabacher
wrote:
>> Can you summarize that in a self-contained form for inclusion in the PEP?
>>
>> (That was a rhetorical question. :-)
>
> Sure. Is it on GitHub? ;D
Thanks Isaac, I've incorporated your edits.
https://raw.githubusercontent.com/Rosuav/Gen
> Can you summarize that in a self-contained form for inclusion in the PEP?
>
> (That was a rhetorical question. :-)
Sure. Is it on GitHub? ;D
ijs
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Uns
On Wed, Nov 26, 2014 at 3:15 PM, Nick Coghlan wrote:
>
> On 27 Nov 2014 03:58, "Paul Moore" wrote:
> >
> > On 26 November 2014 at 17:19, Guido van Rossum wrote:
> > > It's hard to use as an example because the behavior of contextlib is an
> > > integral part of it -- currently for me the exampl
You can use the README here: https://github.com/Rosuav/GenStopIter
On Wed, Nov 26, 2014 at 1:57 PM, Isaac Schwabacher
wrote:
> > Can you summarize that in a self-contained form for inclusion in the PEP?
> >
> > (That was a rhetorical question. :-)
>
> Sure. Is it on GitHub? ;D
>
> ijs
>
--
-
On 27 Nov 2014 03:58, "Paul Moore" wrote:
>
> On 26 November 2014 at 17:19, Guido van Rossum wrote:
> > It's hard to use as an example because the behavior of contextlib is an
> > integral part of it -- currently for me the example boils down to
"there is
> > a bug in contextlib"
>
> Hmm, fair po
On 14-11-26, Guido van Rossum wrote:
> On Wed, Nov 26, 2014 at 8:54 AM, Paul Moore wrote:
>
> > On 26 November 2014 at 16:24, Isaac Schwabacher wrote:
> > > This actually leads to a good example of why the PEP is necessary:
> > [...]
> >
> > Oh! If that's the current behaviour, then it probably
Can you summarize that in a self-contained form for inclusion in the PEP?
(That was a rhetorical question. :-)
On Wed, Nov 26, 2014 at 12:17 PM, Isaac Schwabacher
wrote:
> On 14-11-26, Guido van Rossum wrote:
> > On Wed, Nov 26, 2014 at 8:54 AM, Paul Moore wrote:
> >
> > > On 26 November 2014
On 11/26/2014 08:54 AM, Paul Moore wrote:
> On 26 November 2014 at 16:24, Isaac Schwabacher wrote:
>> This actually leads to a good example of why the PEP is necessary:
> [...]
>
> Oh! If that's the current behaviour, then it probably needs to go into
> the PEP as a motivating example. It's far m
On 26 November 2014 at 17:19, Guido van Rossum wrote:
> It's hard to use as an example because the behavior of contextlib is an
> integral part of it -- currently for me the example boils down to "there is
> a bug in contextlib"
Hmm, fair point. I was assuming that the bug in contextlib can't be
On Wed, Nov 26, 2014 at 8:54 AM, Paul Moore wrote:
> On 26 November 2014 at 16:24, Isaac Schwabacher
> wrote:
> > This actually leads to a good example of why the PEP is necessary:
> [...]
>
> Oh! If that's the current behaviour, then it probably needs to go into
> the PEP as a motivating exampl
On 26 November 2014 at 16:24, Isaac Schwabacher wrote:
> This actually leads to a good example of why the PEP is necessary:
[...]
Oh! If that's the current behaviour, then it probably needs to go into
the PEP as a motivating example. It's far more convincing than most of
the other arguments I've
On 11/26/14, Nick Coghlan wrote:
> On 26 November 2014 at 04:04, Guido van Rossum wrote:
> > On Tue, Nov 25, 2014 at 9:49 AM, Chris Angelico wrote:
> >>
> >> On Wed, Nov 26, 2014 at 4:45 AM, Isaac Schwabacher
> >> wrote:
> >> > Yield can also raise StopIteration, if it's thrown in. The current
On 11/26/14, Nick Coghlan wrote:
> On 26 November 2014 at 04:04, Guido van Rossum wrote:
> > On Tue, Nov 25, 2014 at 9:49 AM, Chris Angelico wrote:
> >>
> >> On Wed, Nov 26, 2014 at 4:45 AM, Isaac Schwabacher
> >> wrote:
> >> > Yield can also raise StopIteration, if it's thrown in. The current
On 26 November 2014 at 04:04, Guido van Rossum wrote:
> On Tue, Nov 25, 2014 at 9:49 AM, Chris Angelico wrote:
>>
>> On Wed, Nov 26, 2014 at 4:45 AM, Isaac Schwabacher
>> wrote:
>> > Yield can also raise StopIteration, if it's thrown in. The current
>> > interaction of generator.throw(StopIterat
On 11/25/14, Chris Angelico wrote:
> On Wed, Nov 26, 2014 at 2:20 AM, Steven D'Aprano wrote:
> > I wouldn't interpret it like that.
> >
> > Calling next() on an empty iterator raises StopIteration. That's not a
> > bug indicating a failure, it's the protocol working as expected. Your
> > response
On Tue, Nov 25, 2014 at 10:12 AM, Isaac Schwabacher
wrote:
> On 11/25/14, Guido van Rossum wrote:
> > On Tue, Nov 25, 2014 at 9:49 AM, Chris Angelico ros...@gmail.com')" target="1">ros...@gmail.com> wrote:
> >
> > > On Wed, Nov 26, 2014 at 4:45 AM, Isaac Schwabacher
> > > ischwabac...@wisc.edu
On 11/25/14, Guido van Rossum wrote:
> On Tue, Nov 25, 2014 at 9:49 AM, Chris Angelico ros...@gmail.com> wrote:
>
> > On Wed, Nov 26, 2014 at 4:45 AM, Isaac Schwabacher
> > > 't=ischwabac...@wisc.edu>> wrote:
> > > Yield can also raise StopIteration, if its thrown in. The current
> > > interac
On Tue, Nov 25, 2014 at 9:49 AM, Chris Angelico wrote:
> On Wed, Nov 26, 2014 at 4:45 AM, Isaac Schwabacher
> wrote:
> > Yield can also raise StopIteration, if it's thrown in. The current
> interaction of generator.throw(StopIteration) with yield from can't be
> emulated under the PEP's behavior
On Wed, Nov 26, 2014 at 4:45 AM, Isaac Schwabacher
wrote:
> Yield can also raise StopIteration, if it's thrown in. The current
> interaction of generator.throw(StopIteration) with yield from can't be
> emulated under the PEP's behavior, though it's not clear that that's a
> problem.
>
Hrm. I h
On Wed, Nov 26, 2014 at 2:20 AM, Steven D'Aprano wrote:
> I wouldn't interpret it like that.
>
> Calling next() on an empty iterator raises StopIteration. That's not a
> bug indicating a failure, it's the protocol working as expected. Your
> response to that may be to catch the StopIteration and i
On Mon, Nov 24, 2014 at 10:22:54AM +1100, Chris Angelico wrote:
> My point is that doing the same errant operation on a list or a dict
> will give different exceptions. In the same way, calling next() on an
> empty iterator will raise StopIteration normally, but might raise
> RuntimeError instead.
On Mon, Nov 24, 2014 at 4:21 PM, Alexander Belopolsky <
alexander.belopol...@gmail.com> wrote:
>
> On Wed, Nov 19, 2014 at 3:10 PM, Guido van Rossum
> wrote:
>
>> There's a new PEP proposing to change how to treat StopIteration bubbling
>> up out of a generator frame (not caused by a return from
On Wed, Nov 19, 2014 at 3:10 PM, Guido van Rossum wrote:
> There's a new PEP proposing to change how to treat StopIteration bubbling
> up out of a generator frame (not caused by a return from the frame). The
> proposal is to replace such a StopIteration with a RuntimeError (chained to
> the origi
On Sun, Nov 23, 2014 at 08:17:00AM -0800, Ethan Furman wrote:
> While I am in favor of PEP 479, and I have to agree with Raymond that
> this isn't pretty.
>
> Currently, next() accepts an argument of what to return if the
> iterator is empty. Can we enhance that in some way so that the
> over
On Mon, Nov 24, 2014 at 10:18 AM, Ron Adam wrote:
>> The stop hack won't work in either (currently it does work in
>> genexps), but you'd get a different exception type if you attempt it.
>> This is correct. It's broadly similar to this distinction:
>>
> >>>{1:2,3:4}[50]
>>
>> Traceback (most
On 11/23/2014 04:15 PM, Chris Angelico wrote:
On Mon, Nov 24, 2014 at 5:28 AM, Ron Adam wrote:
>With the passage of the PEP, it will change what is different about them
>once it's in full effect. The stop hack won't work in both, and you may get
>a RuntimeError in generator expressions where
On Mon, Nov 24, 2014 at 5:28 AM, Ron Adam wrote:
> With the passage of the PEP, it will change what is different about them
> once it's in full effect. The stop hack won't work in both, and you may get
> a RuntimeError in generator expressions where you would get StopIteration in
> list-comps. (
On 11/23/2014 04:08 AM, Terry Reedy wrote:
On 11/22/2014 5:23 PM, Chris Angelico wrote:
On Sun, Nov 23, 2014 at 8:03 AM, Ron Adam wrote:
Making comprehensions work more like generator expressions
would, IMO, imply making the same change to all for loops: having a
StopIteration raised by the
On 11/22/2014 12:30 PM, Raymond Hettinger wrote:
Pre-PEP 479:
---
> def middleware_generator(source_generator):
> it = source_generator()
> input_value = next(it)
> output_value = do_something_interesting(input_value)
> yield output_value
Post-PEP 479:
On 23 November 2014 at 15:25, Chris Angelico wrote:
> Thank you, it's nice to have a successful one to counterbalance the
> "failure" of PEP 463. (Which, incidentally, never actually got a
> resolution. It's still showing up as 'Draft' status.)
I think it's worth pointing out that both this and P
On Mon, Nov 24, 2014 at 2:11 AM, Ethan Furman wrote:
> On 11/22/2014 08:53 PM, Guido van Rossum wrote:
>>
>> In order to save everyone's breath, I am *accepting* the proposal of PEP
>> 479.
>
> Excellent.
>
> Chris, thank you for your time, effort, and thoroughness in championing this
> PEP.
>
T
On 11/22/2014 08:53 PM, Guido van Rossum wrote:
>
> In order to save everyone's breath, I am *accepting* the proposal of PEP
> 479.
Excellent.
Chris, thank you for your time, effort, and thoroughness in championing this
PEP.
--
~Ethan~
signature.asc
Description: OpenPGP digital signature
___
On 11/22/2014 5:23 PM, Chris Angelico wrote:
On Sun, Nov 23, 2014 at 8:03 AM, Ron Adam wrote:
Making comprehensions work more like generator expressions
would, IMO, imply making the same change to all for loops: having a
StopIteration raised by the body of the loop quietly terminate the
loop.
In order to save everyone's breath, I am *accepting* the proposal of PEP
479. The transition plan is:
- "from __future__ import generator_stop" in 3.5, and a silent deprecation
if StopIteration is allowed to bubble out of a generator (i.e. no warning
is printed unless you explicitly turn it on)
-
On 11/22/2014 07:06 PM, Chris Angelico wrote:
On Sun, Nov 23, 2014 at 11:51 AM, Ron Adam wrote:
>
>
>On 11/22/2014 06:20 PM, Chris Angelico wrote:
>>
>>Hmmm, there's no such thing as tuple comprehensions.
>
>Just didn't think it through quite well enough. But you are correct, that
>would b
On 11/22/2014 05:11 PM, Raymond Hettinger wrote:
>> On Nov 22, 2014, at 2:45 PM, Chris Angelico wrote:
>>
>> Does your middleware_generator work with just a single element,
>> yielding either one output value or none?
>
> I apologize if I didn't make the point clearly. The middleware example was
On Sun, Nov 23, 2014 at 12:11 PM, Raymond Hettinger
wrote:
> The worry is that your proposal intentionally breaks that code which is
> currently
> bug free, clean, fast, stable, and relying on a part of the API that has
> been
> guaranteed and documented from day one.
(I'd just like to mention th
> On Nov 22, 2014, at 2:45 PM, Chris Angelico wrote:
>
> Does your middleware_generator work with just a single element,
> yielding either one output value or none?
I apologize if I didn't make the point clearly. The middleware example was
just simple outline of calling next(), doing some pr
On Sun, Nov 23, 2014 at 11:51 AM, Ron Adam wrote:
>
>
> On 11/22/2014 06:20 PM, Chris Angelico wrote:
>>
>> Hmmm, there's no such thing as tuple comprehensions.
>
> Just didn't think it through quite well enough. But you are correct, that
> would be a generator expression.
>
> One less case to wo
On 11/22/2014 06:20 PM, Chris Angelico wrote:
On Sun, Nov 23, 2014 at 11:05 AM, Ron Adam wrote:
>Se we have these...
>
> Tuple Comprehension (...)
> List Comprehension [...]
> Dict Comprehension {...} Colon make's it different from sets.
> Set Comprehension {...}
>
>I
On Sun, Nov 23, 2014 at 11:05 AM, Ron Adam wrote:
> Se we have these...
>
> Tuple Comprehension (...)
> List Comprehension [...]
> Dict Comprehension {...} Colon make's it different from sets.
> Set Comprehension {...}
>
> I don't think there is any other way to create the
On 11/22/2014 04:23 PM, Chris Angelico wrote:
On Sun, Nov 23, 2014 at 8:03 AM, Ron Adam wrote:
>>Making comprehensions work more like generator expressions
>>would, IMO, imply making the same change to all for loops: having a
>>StopIteration raised by the body of the loop quietly terminate th
On Sun, Nov 23, 2014 at 7:30 AM, Raymond Hettinger
wrote:
> Legitimate Use Cases for Raising StopIteration in a Generator
>
>
> In a producer/consumer generator chain, the input generator signals
> it is done by raising StopIteration and
On Sun, Nov 23, 2014 at 8:03 AM, Ron Adam wrote:
>> Making comprehensions work more like generator expressions
>> would, IMO, imply making the same change to all for loops: having a
>> StopIteration raised by the body of the loop quietly terminate the
>> loop.
>
>
> I'm not suggesting making any c
On 11/22/2014 03:01 PM, Terry Reedy wrote:
Then both a comprehension and a generator expressions can be viewed as
defining iterators,
A comprehension is not an iterator. The above would make a list or set
comprehension the same as feeding a genexp to list() or set().
Correct, but we coul
On 11/22/2014 02:16 PM, Chris Angelico wrote:
On Sun, Nov 23, 2014 at 6:49 AM, Ron Adam wrote:
>
>OPTION 1:
>
>Make comprehensions act more like generator expressions.
>
>It would mean a while loop in the object creation point is converted to a
>for loop. (or something equivalent.)
>
>Then bo
On 11/22/2014 2:49 PM, Ron Adam wrote:
On 11/22/2014 08:31 AM, Nick Coghlan wrote:
I'm definitely coming around to the point of view that, even if we
wouldn't
design it the way it currently works given a blank slate, the alternative
design doesn't provide sufficient benefit to justify the cos
> On Nov 22, 2014, at 6:31 AM, Nick Coghlan wrote:
>
> I'm definitely coming around to the point of view that, even if we wouldn't
> design it the way it currently works given a blank slate, the alternative
> design doesn't provide sufficient benefit to justify the cost of changing the
> beha
On Sun, Nov 23, 2014 at 6:49 AM, Ron Adam wrote:
>
> OPTION 1:
>
> Make comprehensions act more like generator expressions.
>
> It would mean a while loop in the object creation point is converted to a
> for loop. (or something equivalent.)
>
> Then both a comprehension and a generator expressions
On 11/22/2014 06:31 AM, Nick Coghlan wrote:
>
> A particularly relevant variant of the idiom is the approach of writing
> "__iter__" directly as a generator, rather than creating a separate custom
> iterator class. In that context, the similarities between the __iter__
> implementation and the cor
On 11/22/2014 08:31 AM, Nick Coghlan wrote:
On 22 Nov 2014 02:51, "Antoine Pitrou" mailto:solip...@pitrou.net>> wrote:
>
> On Fri, 21 Nov 2014 05:47:58 -0800
> Raymond Hettinger mailto:raymond.hettin...@gmail.com>> wrote:
> >
> > Another issue is that it breaks the way I and others have t
On 22 Nov 2014 02:51, "Antoine Pitrou" wrote:
>
> On Fri, 21 Nov 2014 05:47:58 -0800
> Raymond Hettinger wrote:
> >
> > Another issue is that it breaks the way I and others have taught for
years that generators are a kind of iterator (an object implementing the
iterator protocol) and that a prima
On Fri, Nov 21, 2014 at 9:18 AM, Steven D'Aprano
wrote:
> I fear that there is one specific corner case that will be impossible to
> deal with in a backwards-compatible way supporting both Python 2 and 3
> in one code base: the use of `return value` in a generator.
>
> In Python 2.x through 3.1,
On Fri, Nov 21, 2014 at 8:47 AM, Antoine Pitrou wrote:
> On Fri, 21 Nov 2014 05:47:58 -0800
> Raymond Hettinger wrote:
> >
> > Another issue is that it breaks the way I and others have taught for
> years that generators are a kind of iterator (an object implementing the
> iterator protocol) and
On Thu, Nov 20, 2014 at 11:36:54AM -0800, Guido van Rossum wrote:
[...]
> That said, I think for most people the change won't matter, some people
> will have to apply one of a few simple fixes, and a rare few will have to
> rewrite their code in a non-trivial way (sometimes this will affect
> "cle
On Fri, 21 Nov 2014 05:47:58 -0800
Raymond Hettinger wrote:
>
> Another issue is that it breaks the way I and others have taught for years
> that generators are a kind of iterator (an object implementing the iterator
> protocol) and that a primary motivation for generators is to provide a
> si
On Sat, Nov 22, 2014 at 3:37 AM, Donald Stufft wrote:
> I don’t have an opinion on whether it’s enough of a big deal to actually
> change
> it, but I do find wrapping it with a try: except block and returning easier
> to understand. If you showed me the current code unless I really thought about
> On Nov 21, 2014, at 11:31 AM, Ethan Furman wrote:
>
> On 11/21/2014 05:47 AM, Raymond Hettinger wrote:
>>
>> Also, the proposal breaks a reasonably useful pattern of calling
>> next(subiterator)
>> inside a generator and letting the generator terminate when the data stream
>> ends.
>>
>>
On 11/21/2014 05:47 AM, Raymond Hettinger wrote:
>
> Also, the proposal breaks a reasonably useful pattern of calling
> next(subiterator)
> inside a generator and letting the generator terminate when the data stream
> ends.
>
> Here is an example that I have taught for years:
>
> def [...]
On 21 November 2014 15:58, Steven D'Aprano wrote:
>> > def izip(iterable1, iterable2):
>> > it1 = iter(iterable1)
>> > it2 = iter(iterable2)
>> > while True:
>> > v1 = next(it1)
>> > v2 = next(it2)
>> > yield v1, v2
>>
>> Is it obviou
On Sat, Nov 22, 2014 at 2:58 AM, Steven D'Aprano wrote:
> Since zip() is documented as
> halting on the shorter argument, it can't raise an exception. So what
> other options are there apart from silently consuming the value?
Sure, it's documented as doing that. But imagine something that isn't
a
On Sat, Nov 22, 2014 at 12:53:41AM +1100, Chris Angelico wrote:
> On Sat, Nov 22, 2014 at 12:47 AM, Raymond Hettinger
> wrote:
> > Also, the proposal breaks a reasonably useful pattern of calling
> > next(subiterator) inside a generator and letting the generator terminate
> > when the data stream
On 21 November 2014 13:53, Chris Angelico wrote:
> On Sat, Nov 22, 2014 at 12:47 AM, Raymond Hettinger
> wrote:
>> Also, the proposal breaks a reasonably useful pattern of calling
>> next(subiterator) inside a generator and letting the generator terminate
>> when the data stream ends. Here is a
On Sat, Nov 22, 2014 at 12:47 AM, Raymond Hettinger
wrote:
> Also, the proposal breaks a reasonably useful pattern of calling
> next(subiterator) inside a generator and letting the generator terminate
> when the data stream ends. Here is an example that I have taught for
> years:
>
> def izi
> On Nov 19, 2014, at 12:10 PM, Guido van Rossum wrote:
>
> There's a new PEP proposing to change how to treat StopIteration bubbling up
> out of a generator frame (not caused by a return from the frame). The
> proposal is to replace such a StopIteration with a RuntimeError (chained to
> the
On Fri, Nov 21, 2014 at 10:34 AM, Chris Angelico wrote:
> On Fri, Nov 21, 2014 at 6:36 AM, Guido van Rossum wrote:
>> It would also be useful if we could extend the PEP with some examples of the
>> various categories of fixes that can be applied easily, e.g. a few examples
>> of "raise StopIterat
On Thu, Nov 20, 2014 at 3:13 PM, Antoine Pitrou wrote:
> On Thu, 20 Nov 2014 14:04:24 -0800
> Guido van Rossum wrote:
>
> > On Thu, Nov 20, 2014 at 12:13 PM, Serhiy Storchaka
> > wrote:
> >
> > > On 20.11.14 21:58, Antoine Pitrou wrote:
> > >
> > >> To me "generator_return" sounds like the addi
On Fri, Nov 21, 2014 at 9:04 AM, Guido van Rossum wrote:
> On Thu, Nov 20, 2014 at 12:13 PM, Serhiy Storchaka
> wrote:
>>
>> On 20.11.14 21:58, Antoine Pitrou wrote:
>>>
>>> To me "generator_return" sounds like the addition to generator syntax
>>> allowing for return statements (which was done as
On Fri, Nov 21, 2014 at 6:36 AM, Guido van Rossum wrote:
> It would also be useful if we could extend the PEP with some examples of the
> various categories of fixes that can be applied easily, e.g. a few examples
> of "raise StopIteration" directly in a generator that can be replaced with
> "retu
On 11/20/2014 2:36 PM, Guido van Rossum wrote:
There's still a lively discussion on python-ideas; Steven D'Aprano has
dug up quite a bit of evidence that StopIteration is used quite a bit in
ways that will break under the new behavior, and there also seems to be
quite a bit of third-party inform
On Thu, 20 Nov 2014 14:04:24 -0800
Guido van Rossum wrote:
> On Thu, Nov 20, 2014 at 12:13 PM, Serhiy Storchaka
> wrote:
>
> > On 20.11.14 21:58, Antoine Pitrou wrote:
> >
> >> To me "generator_return" sounds like the addition to generator syntax
> >> allowing for return statements (which was d
On 11/20/2014 5:04 PM, Guido van Rossum wrote:
On Thu, Nov 20, 2014 at 12:13 PM, Serhiy Storchaka mailto:storch...@gmail.com>> wrote:
On 20.11.14 21:58, Antoine Pitrou wrote:
To me "generator_return" sounds like the addition to generator
syntax
allowing for return st
On Thu, Nov 20, 2014 at 12:13 PM, Serhiy Storchaka
wrote:
> On 20.11.14 21:58, Antoine Pitrou wrote:
>
>> To me "generator_return" sounds like the addition to generator syntax
>> allowing for return statements (which was done as part of the "yield
>> from" PEP). How about "generate_escape"?
>>
>
On 20.11.14 21:58, Antoine Pitrou wrote:
To me "generator_return" sounds like the addition to generator syntax
allowing for return statements (which was done as part of the "yield
from" PEP). How about "generate_escape"?
Or may be "generator_stop_iteration"?
__
On Thu, 20 Nov 2014 11:36:54 -0800
Guido van Rossum wrote:
> I've made some updates to the PEP:
>
> - added 19-Nov-2014 to Post-History
> - removed "implicitly-raised" from the abstract
> - changed the __future__ thing to generator_return
To me "generator_return" sounds like the addition to gene
I've made some updates to the PEP:
- added 19-Nov-2014 to Post-History
- removed "implicitly-raised" from the abstract
- changed the __future__ thing to generator_return
- added a clarifying paragraph that Chris added to his own draft
- added a link to http://bugs.python.org/issue22906 which has a
On 20 November 2014 06:15, Benjamin Peterson wrote:
>
> On Wed, Nov 19, 2014, at 15:10, Guido van Rossum wrote:
> > There's a new PEP proposing to change how to treat StopIteration bubbling
> > up out of a generator frame (not caused by a return from the frame). The
> > proposal is to replace suc
On 20 November 2014 06:48, MRAB wrote:
> On 2014-11-19 20:10, Guido van Rossum wrote:
>
>> There's a new PEP proposing to change how to treat StopIteration
>> bubbling up out of a generator frame (not caused by a return from
>> the frame). The proposal is to replace such a StopIteration with a
>>
1 - 100 of 104 matches
Mail list logo
