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
f
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 orig
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 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 returning rai
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
>>
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
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 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
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
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 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, 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 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 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 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 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 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 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 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 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: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 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 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 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 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 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 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 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, 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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: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 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 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 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 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
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 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.
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 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 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 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 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 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: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 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 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 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 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 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 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 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 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 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 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, 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 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/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 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 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 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 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
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 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
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
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 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
> 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 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
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
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 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
85 matches
Mail list logo
