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 30 November 2014 at 12:31, Chris Angelico ros...@gmail.com wrote:
On Sun, Nov 30, 2014 at 1:04 PM, Jim J. Jewett jimjjew...@gmail.com 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),
On 11/28/14, Guido van Rossum gu...@python.org 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 ...
On 30 November 2014 at 02:45, Olemis Lang ole...@gmail.com wrote:
On 11/28/14, Guido van Rossum gu...@python.org 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
On Sat, Nov 29, 2014 at 9:07 AM, Nick Coghlan ncogh...@gmail.com 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
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
On Sun, Nov 30, 2014 at 1:04 PM, Jim J. Jewett jimjjew...@gmail.com 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
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(value) to specify a return value;
this works as long as Return is a subclass of StopIteration, but PEP
2014-11-28 10:12 GMT+01:00 Greg Ewing greg.ew...@canterbury.ac.nz:
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
On Fri, Nov 28, 2014 at 8:18 PM, Victor Stinner
victor.stin...@gmail.com wrote:
2014-11-28 10:12 GMT+01:00 Greg Ewing greg.ew...@canterbury.ac.nz:
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
2014-11-28 3:49 GMT+01:00 Nick Coghlan ncogh...@gmail.com:
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
off-topic , not about asyncio but related to the PEP and other things
been discussed in this thread
On 11/28/14, Victor Stinner victor.stin...@gmail.com wrote:
2014-11-28 3:49 GMT+01:00 Nick Coghlan ncogh...@gmail.com:
[...]
So yes, it may help to have a new specialized exception, even if it
correction ...
On 11/28/14, Olemis Lang ole...@gmail.com wrote:
try:
...
except RuntimeError:
return
... should be
{{{#!py
# inside generator function body
try:
...
except StopIteration:
return
}}}
[...]
--
Regards,
Olemis - @olemislc
Apache(tm) Bloodhound contributor
@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
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
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 Thu, Nov 27, 2014 at 10:08 AM, Victor Stinner victor.stin...@gmail.com
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
2014-11-27 20:06 GMT+01:00 Guido van Rossum gu...@python.org:
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
2014-11-27 22:54 GMT+01:00 Victor Stinner victor.stin...@gmail.com:
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
On Fri, Nov 28, 2014 at 8:54 AM, Victor Stinner
victor.stin...@gmail.com 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
On 28 November 2014 at 08:09, Victor Stinner victor.stin...@gmail.com wrote:
2014-11-27 22:54 GMT+01:00 Victor Stinner victor.stin...@gmail.com:
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
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
1 - 100 of 104 matches
Mail list logo
