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 6 December 2014 at 04:42, Guido van Rossum gu...@python.org 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.
On 27 November 2014 at 09:50, Guido van Rossum gu...@python.org wrote:
On Wed, Nov 26, 2014 at 3:15 PM, Nick Coghlan ncogh...@gmail.com wrote:
This is actually the second iteration of this bug: the original
implementation *always* suppressed StopIteration. PJE caught that one before
Python 2.5
On 11/26/14, Nick Coghlan wrote:
On 26 November 2014 at 04:04, Guido van Rossum gu...@python.org 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
ischwabac...@wisc.edu wrote:
Yield can also raise
On 11/26/14, Nick Coghlan wrote:
On 26 November 2014 at 04:04, Guido van Rossum gu...@python.org 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
ischwabac...@wisc.edu wrote:
Yield can also raise
On 26 November 2014 at 16:24, Isaac Schwabacher ischwabac...@wisc.edu 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
On Wed, Nov 26, 2014 at 8:54 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 26 November 2014 at 16:24, Isaac Schwabacher ischwabac...@wisc.edu
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
On 26 November 2014 at 17:19, Guido van Rossum gu...@python.org 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
On 11/26/2014 08:54 AM, Paul Moore wrote:
On 26 November 2014 at 16:24, Isaac Schwabacher ischwabac...@wisc.edu 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
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 ischwabac...@wisc.edu
wrote:
On 14-11-26, Guido van Rossum wrote:
On Wed, Nov 26, 2014 at 8:54 AM, Paul Moore wrote:
On 26
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 needs to go
On 27 Nov 2014 03:58, Paul Moore p.f.mo...@gmail.com wrote:
On 26 November 2014 at 17:19, Guido van Rossum gu...@python.org 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
You can use the README here: https://github.com/Rosuav/GenStopIter
On Wed, Nov 26, 2014 at 1:57 PM, Isaac Schwabacher ischwabac...@wisc.edu
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
On Wed, Nov 26, 2014 at 3:15 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 27 Nov 2014 03:58, Paul Moore p.f.mo...@gmail.com wrote:
On 26 November 2014 at 17:19, Guido van Rossum gu...@python.org wrote:
It's hard to use as an example because the behavior of contextlib is an
integral
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
On Thu, Nov 27, 2014 at 8:57 AM, Isaac Schwabacher
ischwabac...@wisc.edu 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.
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 Wed, Nov 26, 2014 at 2:20 AM, Steven D'Aprano st...@pearwood.info 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
On Wed, Nov 26, 2014 at 4:45 AM, Isaac Schwabacher
ischwabac...@wisc.edu 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
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
ischwabac...@wisc.edu wrote:
Yield can also raise StopIteration, if it's thrown in. The current
interaction of generator.throw(StopIteration) with yield from can't be
On 11/25/14, Guido van Rossum wrote:
On Tue, Nov 25, 2014 at 9:49 AM, Chris Angelico ischwabac...@wisc.edu
ros...@gmail.com') target=1ros...@gmail.com wrote:
On Wed, Nov 26, 2014 at 4:45 AM, Isaac Schwabacher
python.org/~guido(javascript:main.compose('new',
't=ischwabac...@wisc.edu
On Tue, Nov 25, 2014 at 10:12 AM, Isaac Schwabacher ischwabac...@wisc.edu
wrote:
On 11/25/14, Guido van Rossum wrote:
On Tue, Nov 25, 2014 at 9:49 AM, Chris Angelico ischwabac...@wisc.edu
ros...@gmail.com') target=1ros...@gmail.com wrote:
On Wed, Nov 26, 2014 at 4:45 AM, Isaac
On 11/25/14, Chris Angelico wrote:
On Wed, Nov 26, 2014 at 2:20 AM, Steven D'Aprano st...@pearwood.info 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
On 26 November 2014 at 04:04, Guido van Rossum gu...@python.org 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
ischwabac...@wisc.edu wrote:
Yield can also raise StopIteration, if it's thrown in. The current
On Wed, Nov 19, 2014 at 3:10 PM, Guido van Rossum gu...@python.org 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
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 gu...@python.org
wrote:
There's a new PEP proposing to change how to treat StopIteration bubbling
up out of a generator frame (not caused by a
On 11/22/2014 5:23 PM, Chris Angelico wrote:
On Sun, Nov 23, 2014 at 8:03 AM, Ron Adam ron3...@gmail.com 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
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 Mon, Nov 24, 2014 at 2:11 AM, Ethan Furman et...@stoneleaf.us 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
On 23 November 2014 at 15:25, Chris Angelico ros...@gmail.com 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
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 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 ron3...@gmail.com wrote:
Making comprehensions work more like generator expressions
would, IMO, imply making the same change to all for loops: having a
On Mon, Nov 24, 2014 at 5:28 AM, Ron Adam ron3...@gmail.com 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
On 11/23/2014 04:15 PM, Chris Angelico wrote:
On Mon, Nov 24, 2014 at 5:28 AM, Ron Adamron3...@gmail.com 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
On Mon, Nov 24, 2014 at 10:18 AM, Ron Adam ron3...@gmail.com 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 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
overall
On 22 Nov 2014 02:51, Antoine Pitrou solip...@pitrou.net wrote:
On Fri, 21 Nov 2014 05:47:58 -0800
Raymond Hettinger raymond.hettin...@gmail.com 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
On 11/22/2014 08:31 AM, Nick Coghlan wrote:
On 22 Nov 2014 02:51, Antoine Pitrou solip...@pitrou.net
mailto:solip...@pitrou.net wrote:
On Fri, 21 Nov 2014 05:47:58 -0800
Raymond Hettinger raymond.hettin...@gmail.com
mailto:raymond.hettin...@gmail.com wrote:
Another issue is that
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
On Sun, Nov 23, 2014 at 6:49 AM, Ron Adam ron3...@gmail.com 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
On Nov 22, 2014, at 6:31 AM, Nick Coghlan ncogh...@gmail.com 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
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
On 11/22/2014 02:16 PM, Chris Angelico wrote:
On Sun, Nov 23, 2014 at 6:49 AM, Ron Adamron3...@gmail.com 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.)
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
On Sun, Nov 23, 2014 at 8:03 AM, Ron Adam ron3...@gmail.com 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
On Sun, Nov 23, 2014 at 7:30 AM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
Legitimate Use Cases for Raising StopIteration in a Generator
In a producer/consumer generator chain, the input generator signals
it is done by
On 11/22/2014 04:23 PM, Chris Angelico wrote:
On Sun, Nov 23, 2014 at 8:03 AM, Ron Adamron3...@gmail.com 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
On Sun, Nov 23, 2014 at 11:05 AM, Ron Adam ron3...@gmail.com 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
On 11/22/2014 06:20 PM, Chris Angelico wrote:
On Sun, Nov 23, 2014 at 11:05 AM, Ron Adamron3...@gmail.com wrote:
Se we have these...
Tuple Comprehension (...)
List Comprehension [...]
Dict Comprehension {...} Colon make's it different from sets.
Set Comprehension
On Sun, Nov 23, 2014 at 11:51 AM, Ron Adam ron3...@gmail.com 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
On Nov 22, 2014, at 2:45 PM, Chris Angelico ros...@gmail.com 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(),
On Sun, Nov 23, 2014 at 12:11 PM, Raymond Hettinger
raymond.hettin...@gmail.com 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
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
just
On 11/22/2014 07:06 PM, Chris Angelico wrote:
On Sun, Nov 23, 2014 at 11:51 AM, Ron Adamron3...@gmail.com 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
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 Nov 19, 2014, at 12:10 PM, Guido van Rossum gu...@python.org 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
On Sat, Nov 22, 2014 at 12:47 AM, Raymond Hettinger
raymond.hettin...@gmail.com 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
On 21 November 2014 13:53, Chris Angelico ros...@gmail.com wrote:
On Sat, Nov 22, 2014 at 12:47 AM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
Also, the proposal breaks a reasonably useful pattern of calling
next(subiterator) inside a generator and letting the generator terminate
On Sat, Nov 22, 2014 at 12:53:41AM +1100, Chris Angelico wrote:
On Sat, Nov 22, 2014 at 12:47 AM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
Also, the proposal breaks a reasonably useful pattern of calling
next(subiterator) inside a generator and letting the generator terminate
On Sat, Nov 22, 2014 at 2:58 AM, Steven D'Aprano st...@pearwood.info 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
On 21 November 2014 15:58, Steven D'Aprano st...@pearwood.info wrote:
def izip(iterable1, iterable2):
it1 = iter(iterable1)
it2 = iter(iterable2)
while True:
v1 = next(it1)
v2 = next(it2)
yield v1, v2
Is it obvious to
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 Nov 21, 2014, at 11:31 AM, Ethan Furman et...@stoneleaf.us 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 Sat, Nov 22, 2014 at 3:37 AM, Donald Stufft don...@stufft.io 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
On Fri, 21 Nov 2014 05:47:58 -0800
Raymond Hettinger raymond.hettin...@gmail.com 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
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
clever
On Fri, Nov 21, 2014 at 8:47 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Fri, 21 Nov 2014 05:47:58 -0800
Raymond Hettinger raymond.hettin...@gmail.com 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
On Fri, Nov 21, 2014 at 9:18 AM, Steven D'Aprano st...@pearwood.info
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
On 20 November 2014 06:48, MRAB pyt...@mrabarnett.plus.com 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
On 20 November 2014 06:15, Benjamin Peterson benja...@python.org 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
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 Thu, 20 Nov 2014 11:36:54 -0800
Guido van Rossum gu...@python.org 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
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, Nov 20, 2014 at 12:13 PM, Serhiy Storchaka 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 statements (which was done as part of the yield
from PEP). How about generate_escape?
On 11/20/2014 5:04 PM, Guido van Rossum wrote:
On Thu, Nov 20, 2014 at 12:13 PM, Serhiy Storchaka storch...@gmail.com
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
On Thu, 20 Nov 2014 14:04:24 -0800
Guido van Rossum gu...@python.org wrote:
On Thu, Nov 20, 2014 at 12:13 PM, Serhiy Storchaka 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
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
On Fri, Nov 21, 2014 at 6:36 AM, Guido van Rossum gu...@python.org 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
On Fri, Nov 21, 2014 at 9:04 AM, Guido van Rossum gu...@python.org wrote:
On Thu, Nov 20, 2014 at 12:13 PM, Serhiy Storchaka 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 statements
On Thu, Nov 20, 2014 at 3:13 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Thu, 20 Nov 2014 14:04:24 -0800
Guido van Rossum gu...@python.org wrote:
On Thu, Nov 20, 2014 at 12:13 PM, Serhiy Storchaka storch...@gmail.com
wrote:
On 20.11.14 21:58, Antoine Pitrou wrote:
To me
On Fri, Nov 21, 2014 at 10:34 AM, Chris Angelico ros...@gmail.com wrote:
On Fri, Nov 21, 2014 at 6:36 AM, Guido van Rossum gu...@python.org 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
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 original StopIteration), so that only *returning* from a generator (or
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 such a StopIteration with a RuntimeError (chained
to
the original
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
RuntimeError (chained to the original StopIteration),
On Thu, Nov 20, 2014 at 7:48 AM, MRAB pyt...@mrabarnett.plus.com wrote:
The PEP says any generator that depends on an implicitly-raised
StopIteration to terminate it will have to be rewritten to either catch
that exception or use a for-loop
Shouldn't that be ... explicitly-raised ..., because
85 matches
Mail list logo
