Finally, a reason to use Python 3 ;-)
Chris
On 13/01/2012 16:00, Guido van Rossum wrote:
AWESOME!!!
On Fri, Jan 13, 2012 at 4:14 AM, Nick Coghlan mailto:ncogh...@gmail.com>> wrote:
I marked PEP 380 as Final this evening, after pushing the tested and
documented implementation to hg.pyt
On 1/13/2012 7:14 AM, Nick Coghlan wrote:
print("\n".join(list((lambda:(yield from ("Cheers,", "Nick")))(
I pulled, rebuilt, and it indeed works (on Win 7).
I just remembered that Tim Peters somewhere (generator.c?) left a large
comment with examples of recursive generators, such as knigh
On Fri, 13 Jan 2012 22:14:43 +1000
Nick Coghlan wrote:
> I marked PEP 380 as Final this evening, after pushing the tested and
> documented implementation to hg.python.org:
> http://hg.python.org/cpython/rev/d64ac9ab4cd0
I don't know if this is supposed to work, but the exception looks wrong:
>>>
AWESOME!!!
On Fri, Jan 13, 2012 at 4:14 AM, Nick Coghlan wrote:
> I marked PEP 380 as Final this evening, after pushing the tested and
> documented implementation to hg.python.org:
> http://hg.python.org/cpython/rev/d64ac9ab4cd0
>
> As the list of names in the NEWS and What's New entries suggest
Great work Nick, I've been looking forward to this one. Thanks all for
putting the effort in.
On Fri, Jan 13, 2012 at 11:14 PM, Nick Coghlan wrote:
> I marked PEP 380 as Final this evening, after pushing the tested and
> documented implementation to hg.python.org:
> http://hg.python.org/cpython/r
I marked PEP 380 as Final this evening, after pushing the tested and
documented implementation to hg.python.org:
http://hg.python.org/cpython/rev/d64ac9ab4cd0
As the list of names in the NEWS and What's New entries suggests, it
was quite a collaborative effort to get this one over the line, and
th
On 26/11/2011 07:46, Maciej Fijalkowski wrote:
On Sat, Nov 26, 2011 at 6:39 AM, Nick Coghlan wrote:
On Sat, Nov 26, 2011 at 8:14 AM, Michael Foord
wrote:
On 24 Nov 2011, at 04:06, Nick Coghlan wrote:
On Thu, Nov 24, 2011 at 10:28 AM, Guido van Rossum wrote:
Mea culpa for not keeping trac
On Sat, Nov 26, 2011 at 6:39 AM, Nick Coghlan wrote:
> On Sat, Nov 26, 2011 at 8:14 AM, Michael Foord
> wrote:
>>
>> On 24 Nov 2011, at 04:06, Nick Coghlan wrote:
>>
>>> On Thu, Nov 24, 2011 at 10:28 AM, Guido van Rossum wrote:
Mea culpa for not keeping track, but what's the status of PEP 3
On Sat, Nov 26, 2011 at 8:14 AM, Michael Foord
wrote:
>
> On 24 Nov 2011, at 04:06, Nick Coghlan wrote:
>
>> On Thu, Nov 24, 2011 at 10:28 AM, Guido van Rossum wrote:
>>> Mea culpa for not keeping track, but what's the status of PEP 380? I
>>> really want this in Python 3.3!
>>
>> There are two r
On 24 Nov 2011, at 04:06, Nick Coghlan wrote:
> On Thu, Nov 24, 2011 at 10:28 AM, Guido van Rossum wrote:
>> Mea culpa for not keeping track, but what's the status of PEP 380? I
>> really want this in Python 3.3!
>
> There are two relevant tracker issues (both with me for the moment).
>
> The
On Thu, Nov 24, 2011 at 10:28 AM, Guido van Rossum wrote:
> Mea culpa for not keeping track, but what's the status of PEP 380? I
> really want this in Python 3.3!
There are two relevant tracker issues (both with me for the moment).
The main tracker issue for PEP 380 is here: http://bugs.python.o
Mea culpa for not keeping track, but what's the status of PEP 380? I
really want this in Python 3.3!
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscri
Nick Coghlan gmail.com> writes:
>
> On Tue, Jun 28, 2011 at 1:09 AM, renaud gmail.com> wrote:
> > Nick Coghlan gmail.com> writes:
> >
> >> I hit a snag with this. The real tests of the PEP 380 functionality
> >> aren't currently part of the patch - they're a big set of "golden
> >> output" tes
On Tue, Jun 28, 2011 at 1:09 AM, renaud wrote:
> Nick Coghlan gmail.com> writes:
>
>> I hit a snag with this. The real tests of the PEP 380 functionality
>> aren't currently part of the patch - they're a big set of "golden
>> output" tests in the zipfile hosted on Greg's site. Those need to be
>>
Nick Coghlan gmail.com> writes:
> I hit a snag with this. The real tests of the PEP 380 functionality
> aren't currently part of the patch - they're a big set of "golden
> output" tests in the zipfile hosted on Greg's site. Those need to be
> refactored into proper unittest or doctest based addit
On Sun, Jun 26, 2011 at 1:16 PM, Nick Coghlan wrote:
> On Sun, Jun 26, 2011 at 2:44 AM, Guido van Rossum wrote:
>> Let me cut this short. PEP 380 is pretty much approved. I know there
>> are a few details worth quibbling over, but they are not going to
>> jeopardize acceptance of the PEP. We are
On Sun, Jun 26, 2011 at 2:44 AM, Guido van Rossum wrote:
> Let me cut this short. PEP 380 is pretty much approved. I know there
> are a few details worth quibbling over, but they are not going to
> jeopardize acceptance of the PEP. We are waiting for an implementation
> in Python 3.3. In fact, I w
P.J. Eby wrote:
I would like to reiterate (no pun intended) the suggestion of a special
syntactic form for the return
Allowing a return
value, but then having that value silently disappear, seems like it
would delay ... learning
If I remember correctly, all these arguments were made at th
On 7/24/2010 11:21 PM, Guido van Rossum wrote:
On Sat, Jul 24, 2010 at 6:51 PM, P.J. Eby wrote:
By the way, the PEP's "optimized" implementation could probably be done just
by making generator functions containing yield-from statements return an
object of a different type than the standard ge
At 08:21 PM 7/24/2010 -0700, Guido van Rossum wrote:
FWIW, the thing that was harder to debug when I tried to write some
code involving generators and a trampoline recently, was thinking of a
function as a generator without actually putting a yield in it
(because a particular version of a corouti
On Sat, Jul 24, 2010 at 6:51 PM, P.J. Eby wrote:
> At 07:08 AM 7/24/2010 -0700, Guido van Rossum wrote:
>>
>> - After seeing Raymond's talk about monocle (search for it on PyPI) I
>> am getting excited again about PEP 380 (yield from, return values from
>> generators). Having read the PEP on the p
At 07:08 AM 7/24/2010 -0700, Guido van Rossum wrote:
- After seeing Raymond's talk about monocle (search for it on PyPI) I
am getting excited again about PEP 380 (yield from, return values from
generators). Having read the PEP on the plane back home I didn't see
anything wrong with it, so it coul
Ron Adam wrote:
P.J. Eby wrote:
Sure. But right now, the return value of a generator function *is the
generator*. And you're free to ignore that, sure.
But this is a "second" return value that only goes to a special place
with special syntax -- without that syntax, you can't access it.
P.J. Eby wrote:
Sure. But right now, the return value of a generator function *is the
generator*. And you're free to ignore that, sure.
But this is a "second" return value that only goes to a special place
with special syntax -- without that syntax, you can't access it.
But in the use c
On Sat, Mar 28, 2009 at 8:14 PM, Nick Coghlan wrote:
> Greg Ewing wrote:
>> Guido van Rossum wrote:
>>> But it's been answered already -- we can't change the meaning of
>>> StopIteration() with a value unequal to None, so it has to be a
>>> separate exception, and it should not derive from StopIte
Greg Ewing wrote:
> Guido van Rossum wrote:
>
>> But it's been answered already -- we can't change the meaning of
>> StopIteration() with a value unequal to None, so it has to be a
>> separate exception, and it should not derive from StopIteration.
>
> How about having StopIteration be a subclass
Guido van Rossum wrote:
But it's been answered already -- we can't change the meaning of
StopIteration() with a value unequal to None, so it has to be a
separate exception, and it should not derive from StopIteration.
How about having StopIteration be a subclass of the
new exception? Then thin
On Sat, Mar 28, 2009 at 4:37 PM, Greg Ewing wrote:
> Guido van Rossum wrote:
>
I think in either case a check in
PyIter_Next() would cover most cases
>>
>>> If that's acceptable, then the check might as well
>>> be for None as the StopIteration value, and there's
>>> no need for a new ex
Guido van Rossum wrote:
I think in either case a check in
PyIter_Next() would cover most cases
If that's acceptable, then the check might as well
be for None as the StopIteration value, and there's
no need for a new exception.
I don't understand this.
Maybe I misunderstood what you were s
At 06:52 AM 3/28/2009 -0500, Guido van Rossum wrote:
> 2. In addition to the "yield from" syntax for delegating to a
> subgenerator, also add new syntax for returning values from
> subgenerators so that the basic "return X" can continue to trigger
> SyntaxError.
>
> Since option 2 would most like
On Sat, Mar 28, 2009 at 4:34 AM, Nick Coghlan wrote:
> I still think raise is out due to the fact that it would trigger
> subsequent except clauses. Guido has (sensibly) ruled out raising
> StopIteration and complaining if it has value in old code, since there
> is too much code which cases StopIt
On Sat, Mar 28, 2009 at 1:36 AM, Greg Ewing wrote:
> Guido van Rossum wrote:
>
>> The new exception could either be a designated (built-in) subclass of
>> StopIteration, or not;
>
> I think it would have to not be; otherwise any existing
> code that catches StopIteration would catch the new
> exce
Michele Simionato wrote:
> On Fri, Mar 27, 2009 at 1:33 PM, Jesse Noller wrote:
>> Antoine Pitrou:
>>> As a matter of fact, the people whom this PEP is supposed to benefit haven't
>>> expressed a lot of enthusiasm right now. That's why it looks so academic.
>> That's because most of us who might l
Guido van Rossum wrote:
The new exception could either be a designated (built-in) subclass of
StopIteration, or not;
I think it would have to not be; otherwise any existing
code that catches StopIteration would catch the new
exception as well without complaint.
Using a different exception rai
On Fri, Mar 27, 2009 at 1:33 PM, Jesse Noller wrote:
> Antoine Pitrou:
>> As a matter of fact, the people whom this PEP is supposed to benefit haven't
>> expressed a lot of enthusiasm right now. That's why it looks so academic.
> That's because most of us who might like this have been patently
> a
On Fri, Mar 27, 2009 at 8:45 PM, P.J. Eby wrote:
> At 12:53 PM 3/28/2009 +1200, Greg Ewing wrote:
>> Guido van Rossum wrote:
>>> Perhaps the crux is that *if* you accidentally use "return " in
>>> a vanilla generator expecting the value to show up somewhere, you are
>>> probably enough of a newbie
At 12:53 PM 3/28/2009 +1200, Greg Ewing wrote:
Guido van Rossum wrote:
Perhaps the crux is that *if* you accidentally use "return " in
a vanilla generator expecting the value to show up somewhere, you are
probably enough of a newbie that debugging this will be quite hard.
I'd like not to have s
Guido van Rossum wrote:
Perhaps the crux is that *if* you accidentally use "return " in
a vanilla generator expecting the value to show up somewhere, you are
probably enough of a newbie that debugging this will be quite hard.
I'd like not to have such a newbie trap lying around.
Okay, so would
On Fri, Mar 27, 2009 at 1:06 AM, Greg Ewing wrote:
> P.J. Eby wrote:
>
>> Could we at least have some syntax like 'return from yield with 43', to
>> distinguish it from a regular return, clarify that it's returning a value to
>> a yield-from statement, and emphasize that you need a yield-from to c
On Fri, Mar 27, 2009 at 12:53 AM, Greg Ewing
wrote:
> Guido van Rossum wrote:
>
>> That +0 could turn into a +1 if there was a way to flag this as an
>> error (at runtime), at least if the return is actually executed:
>>
>> def g():
>> yield 42
>> return 43
>>
>> for x in g():
>> print x
At 03:28 AM 3/27/2009 -0400, Scott Dial wrote:
P.J. Eby wrote:
> One remaining quirk or missing piece: ISTM there needs to be a way to
> extract the return value without using a yield-from statement. I mean,
> you could write a utility function like:
>
>def unyield(geniter):
>try:
>
2009/3/27 Jesse Noller :
> That's because most of us who might like this have been patently
> avoiding this thread.
>
> I like the syntax, I'm iffy on the exception other than stop iteration
> (but I lost track on what was decided on this) and I would like to see
> this go in. I think this is going
On Fri, Mar 27, 2009 at 5:56 AM, Antoine Pitrou wrote:
> Greg Ewing canterbury.ac.nz> writes:
>>
>> It's not really about doing away with trampolines anyway.
>> You still need at least one trampoline-like thing at the
>> top. What you do away with is the need for creating
>> special objects to yi
Greg Ewing canterbury.ac.nz> writes:
>
> It's not really about doing away with trampolines anyway.
> You still need at least one trampoline-like thing at the
> top. What you do away with is the need for creating
> special objects to yield, and the attendant syntactic
> clumisiness and inefficienc
on 2009-03-27 05:17 P.J. Eby said the following:
At 04:08 PM 3/27/2009 +1300, Greg Ewing wrote:
You can't expect to improve something like that by
stuffing yield-from into the existing framework, because
the point of yield-from is to render the framework
itself unnecessary.
But it doesn't. Yo
Steve Holden wrote:
I am a *bit* concerned, without really being able to put my finger on
it, that the "yield from" expression's value comes from inside (the
"return" from the nested generator) while the "yield from" expression's
value comes from "outside" (the value passed to a .send() method c
P.J. Eby wrote:
> One remaining quirk or missing piece: ISTM there needs to be a way to
> extract the return value without using a yield-from statement. I mean,
> you could write a utility function like:
>
>def unyield(geniter):
>try:
>while 1: geniter.next()
>exce
Greg Ewing wrote:
> Guido van Rossum wrote:
>
>> That +0 could turn into a +1 if there was a way to flag this as an
>> error (at runtime), at least if the return is actually executed:
>>
>> def g():
>> yield 42
>> return 43
>>
>> for x in g():
>> print x# probably expected to print
Guido van Rossum wrote:
[...] (There could be good reasons not to
> complexificate it this way too.)
>
You've been 'Mercanized. This is the most worstest English I have ever
seen you write.
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC
Greg Ewing wrote:
> Guido van Rossum wrote:
>
>> (Well here is Greg's requested use case for .send(). :-)
>
> There was a complaint that my return-value-with-send
> example was too much of a coroutine scenario, so I
> was hoping to find something un-coroutine-like. But
> if coroutines are the mai
P.J. Eby wrote:
Could we at least have some syntax like 'return from yield with 43', to
distinguish it from a regular return, clarify that it's returning a
value to a yield-from statement, and emphasize that you need a
yield-from to call it?
You don't, though -- yield-from just happens to be
Guido van Rossum wrote:
That +0 could turn into a +1 if there was a way to flag this as an
error (at runtime), at least if the return is actually executed:
def g():
yield 42
return 43
for x in g():
print x# probably expected to print 42 and then 43
Perhaps the exception used i
P.J. Eby wrote:
In particular, it should explain why these choices are so costly as to
justify new syntax and a complex implementation:
If avoiding trampolines was the only reason for
yield-from, that mightn't be enough justification
on its own. But it addresses several other use
cases as well.
P.J. Eby wrote:
And they *still* wouldn't be able to do away with their trampolines --
It's not really about doing away with trampolines anyway.
You still need at least one trampoline-like thing at the
top. What you do away with is the need for creating
special objects to yield, and the attend
Guido van Rossum wrote:
(Well here is Greg's requested use case for .send(). :-)
There was a complaint that my return-value-with-send
example was too much of a coroutine scenario, so I
was hoping to find something un-coroutine-like. But
if coroutines are the main uses for send in the first
pla
At 04:08 PM 3/27/2009 +1300, Greg Ewing wrote:
You can't expect to improve something like that by
stuffing yield-from into the existing framework, because
the point of yield-from is to render the framework
itself unnecessary.
But it doesn't. You still need *something* that processes the
yield
At 10:39 PM 3/26/2009 -0500, Guido van Rossum wrote:
That +0 could turn into a +1 if there was a way to flag this as an
error (at runtime), at least if the return is actually executed:
def g():
yield 42
return 43
for x in g():
print x# probably expected to print 42 and then 43
On Thu, Mar 26, 2009 at 4:19 PM, P.J. Eby wrote:
> At 12:27 PM 3/26/2009 -0700, Guido van Rossum wrote:
>> There is some clear low-hanging fruit for Greg's proposal
>> where no trampoline or helpers are needed -- but where currently
>> refactoring complex code containing many yield statements is
>
Antoine Pitrou wrote:
There seems to be a misunderstanding as to how generators
are used in Twisted. There isn't a global "trampoline" to schedule generators
around. Instead, generators are wrapped with a decorator (*) which collects each
yielded value (it's a Deferred object) and attaches to it
At 12:27 PM 3/26/2009 -0700, Guido van Rossum wrote:
There is some clear low-hanging fruit for Greg's proposal
where no trampoline or helpers are needed -- but where currently
refactoring complex code containing many yield statements is
cumbersome due to the nee to write each "subroutine" call as
At 12:20 PM 3/26/2009 -0700, Guido van Rossum wrote:
By brittle I meant again having to be aware of those details of the
mechanism that exist because of syntactic limitations, e.g.
accidentally writing "return X" instead of "yield Return(X)".
In that case, you'd either have a syntax error under
On Thu, Mar 26, 2009 at 10:19 AM, P.J. Eby wrote:
> At 10:56 AM 3/26/2009 +, Antoine Pitrou wrote:
>>
>> Guido van Rossum python.org> writes:
>> >
>> > That's stating it a little too strongly. Phillip has shown how with
>> > judicious use of decorators and helper classes you can get a
>> > re
On Thu, Mar 26, 2009 at 10:07 AM, P.J. Eby wrote:
> At 09:24 PM 3/25/2009 -0700, Guido van Rossum wrote:
>> ISTR that the motivation for adding new syntax is that the best you
>> can do using a trampoline library is still pretty cumbersome to use
>> when you have to write a lot of tasks and subtas
At 10:56 AM 3/26/2009 +, Antoine Pitrou wrote:
Guido van Rossum python.org> writes:
>
> That's stating it a little too strongly. Phillip has shown how with
> judicious use of decorators and helper classes you can get a
> reasonable approximation, and I think Twisted uses something like
> thi
At 08:43 PM 3/26/2009 +1200, Greg Ewing wrote:
Trying to think of a better usage example that
combines send() with returning values, I've realized
that part of the problem is that I don't actually
know of any realistic uses for send() in the first
place.
Can anyone point me to any? Maybe it will
At 09:24 PM 3/25/2009 -0700, Guido van Rossum wrote:
ISTR that the motivation for adding new syntax is that the best you
can do using a trampoline library is still pretty cumbersome to use
when you have to write a lot of tasks and subtasks, and when using
tasks is just a tool for getting things d
Guido van Rossum python.org> writes:
>
> That's stating it a little too strongly. Phillip has shown how with
> judicious use of decorators and helper classes you can get a
> reasonable approximation, and I think Twisted uses something like
> this, so it's not just theory. I think the best you can
Greg Ewing wrote:
> Nick Coghlan wrote:
>
>> Although the PEP may still want to mention how one would write *tests*
>> for these things. Will the test drivers themselves need to be generators
>> participating in some kind of trampoline setup?
>
> I don't see that tests are fundamentally different
Trying to think of a better usage example that
combines send() with returning values, I've realized
that part of the problem is that I don't actually
know of any realistic uses for send() in the first
place.
Can anyone point me to any? Maybe it will help
to inspire a better example.
--
Greg
Nick Coghlan wrote:
Although the PEP may still want to mention how one would write *tests*
for these things. Will the test drivers themselves need to be generators
participating in some kind of trampoline setup?
I don't see that tests are fundamentally different
from any other code that wants
Guido van Rossum wrote:
That's all good. I just don't think that a presentation in terms of
code in-lining is a good idea.
I was trying to describe it in a way that would give
some insight into *why* the various aspects of the
formal definition are the way they are. The inlining
concept seemed
Guido van Rossum wrote:
> On Wed, Mar 25, 2009 at 6:22 AM, Nick Coghlan wrote:
>> It could perhaps be done by enhancing the part of the
>>> 'for' loop that gets executed upon normal termination
>>> of the iterator.
>>>
>>> for x in my_iter:
>>> do_something_with(x)
>>> else v:
>>> hand
On Tue, Mar 24, 2009 at 11:03 PM, Greg Ewing
wrote:
> Guido van Rossum wrote:
>
>> The way I think of it, that refactoring has nothing to do with
>> yield-from.
>
> I'm not sure what you mean by that. Currently it's
> *impossible* to factor out code containing a yield.
That's stating it a little
On Wed, Mar 25, 2009 at 6:22 AM, Nick Coghlan wrote:
> Greg Ewing wrote:
>> Would you be happier if some syntactic way to do that
>> were provided?
>>
>> It could perhaps be done by enhancing the part of the
>> 'for' loop that gets executed upon normal termination
>> of the iterator.
>>
>> for x
ISTR that the motivation for adding new syntax is that the best you
can do using a trampoline library is still pretty cumbersome to use
when you have to write a lot of tasks and subtasks, and when using
tasks is just a tool for getting things done rather than an end goal
in itself. I agree that the
At 06:03 PM 3/25/2009 +1200, Greg Ewing wrote:
I wanted a way of writing suspendable functions that
can call each other easily. (You may remember I
originally wanted to call it "call".) Then I noticed
that it would also happen to provide the functionality
of earlier "yield from" suggestions, so I
Nick Coghlan wrote:
> With those two ideas combined, the PEP's "yield from" expansion could
> then look like:
>
> for x in EXPR:
> _v = yield x
> if _v is not None:
> continue _v
> else _r:
> RESULT = _r
Oops, got a little carried away there. Obviously, that doesn't handle
t
Greg Ewing wrote:
> Would you be happier if some syntactic way to do that
> were provided?
>
> It could perhaps be done by enhancing the part of the
> 'for' loop that gets executed upon normal termination
> of the iterator.
>
> for x in my_iter:
> do_something_with(x)
> else v:
> hand
P.J. Eby wrote:
Now, if somebody came up with a different way to spell the extra value
return, I wouldn't object as much to that part. I can just see people
inadvertently writing 'return x' as a shortcut for 'yield x; return',
Well, they need to be educated not to do that. I'm
not sure they
Guido van Rossum wrote:
The way I think of it, that refactoring has nothing to do with
yield-from.
I'm not sure what you mean by that. Currently it's
*impossible* to factor out code containing a yield.
Providing a way to do that is what led me to invent
this particular version of yield-from in
Steve Holden wrote:
What about extending the syntax somewhat to
yield expr for x from X
I can't see much advantage that would give you
over writing
for x in X:
yield expr
There would be little or no speed advantage,
since you would no longer be able to shortcut
the intermediate gener
On Tue, Mar 24, 2009 at 8:35 PM, P.J. Eby wrote:
> Now, if somebody came up with a different way to spell the extra value
> return, I wouldn't object as much to that part. I can just see people
> inadvertently writing 'return x' as a shortcut for 'yield x; return', and
> then having what seem lik
At 10:22 PM 3/24/2009 -0400, Steve Holden wrote:
There is one non-trivial extension that I've been chewing over for a
while. What if you want to yield not the values from the generator but
some function of those values? The present proposal appears to have no
way to specify that. What about exten
Greg Ewing wrote:
> Guido van Rossum wrote:
>
>> I really don't like to have things whose semantics is
>> defined in terms of code inlining -- even if you don't mean that as
>> the formal semantics but just as a mnemonic hint.
>
> Think about it the other way around, then. Take any chunk
> of cod
On Tue, Mar 24, 2009 at 4:02 PM, Greg Ewing wrote:
> Guido van Rossum wrote:
>> I really don't like to have things whose semantics is
>> defined in terms of code inlining -- even if you don't mean that as
>> the formal semantics but just as a mnemonic hint.
>
> Think about it the other way around,
Guido van Rossum wrote:
I really don't like to have things whose semantics is
defined in terms of code inlining -- even if you don't mean that as
the formal semantics but just as a mnemonic hint.
Think about it the other way around, then. Take any chunk
of code containing a yield, factor it ou
On Sat, Mar 21, 2009 at 2:54 PM, Greg Ewing wrote:
> Antoine Pitrou wrote:
>
>> Do we really want to add a syntactic feature which has such a complicated
>> expansion? I fear it will make code using "yield from" much more difficult
>> to
>> understand and audit.
>
> As I've said before, I don't th
Greg Ewing wrote:
As for confusion, we ignore the return values of function
calls all the time, without worrying that someone might be
confused by the fact that their return value doesn't go
anywhere. And that's the right way to think of a yield-from
expression -- as a kind of function call, not
Antoine Pitrou wrote:
If it's really enough to understand and debug all corner cases of using "yield
from", then fair enough.
In the case where the subiterator is another generator and
isn't shared, it's intended to be a precise and complete
specification. That covers the vast majority of the
At 08:11 PM 3/22/2009 +1200, Greg Ewing wrote:
P.J. Eby wrote:
(I'm thus finding it hard to believe there's a non-contrived
example that's not doing I/O, scheduling, or some other form of
co-operative multitasking.)
Have you seen my xml parser example?
http://www.cosc.canterbury.ac.nz/greg.
Greg Ewing canterbury.ac.nz> writes:
>
> "When the iterator is another generator, the effect is the same as if
> the body of the subgenerator were inlined at the point of the ``yield
> from`` expression. Furthermore, the subgenerator is allowed to execute
> a ``return`` statement with a value, an
On Sun Mar 22 09:11:29 CET 2009 Greg Ewing wrote:
As for confusion, we ignore the return values of function
calls all the time, without worrying that someone might be
confused by the fact that their return value doesn't go
anywhere. And that's the right way to think of a yield-from
expression --
P.J. Eby wrote:
(I'm thus finding it hard
to believe there's a non-contrived example that's not doing I/O,
scheduling, or some other form of co-operative multitasking.)
Have you seen my xml parser example?
http://www.cosc.canterbury.ac.nz/greg.ewing/python/yield-from/
Whether you'll conside
At 10:21 AM 3/22/2009 +1200, Greg Ewing wrote:
P.J. Eby wrote:
My concern is that allowing 'return value' in generators is going
to be confusing, since it effectively causes the return value to
"disappear" if you're not using it in this special way with some
framework that takes advantage.
2009/3/21 Greg Ewing :
> P.J. Eby wrote:
>
>> My concern is that allowing 'return value' in generators is going to be
>> confusing, since it effectively causes the return value to "disappear" if
>> you're not using it in this special way with some framework that takes
>> advantage.
>
> But part of
P.J. Eby wrote:
My concern is that allowing 'return value' in generators is going to be
confusing, since it effectively causes the return value to "disappear"
if you're not using it in this special way with some framework that
takes advantage.
But part of all this is that you *don't* need a
Antoine Pitrou wrote:
Do we really want to add a syntactic feature which has such a complicated
expansion? I fear it will make code using "yield from" much more difficult to
understand and audit.
As I've said before, I don't think the feature itself is
difficult to understand. You're not meant
At 04:45 PM 3/21/2009 +1000, Nick Coghlan wrote:
I really like the PEP - it's a solid extension of the ideas introduced
by PEP 342.
(Replying to you since I haven't seen any other thread on this)
My concern is that allowing 'return value' in generators is going to
be confusing, since it effec
Nick Coghlan gmail.com> writes:
>
> Whether or not different people will find code using "yield from"
> difficult to understand or not will have more to do with their grasp of
> the concepts of cooperative multitasking in general more so than the
> underlying trickery involved in allowing truly n
Antoine Pitrou wrote:
> Nick Coghlan gmail.com> writes:
>> And that it formally expanded to:
>>
>> conditionals>
>
> Do we really want to add a syntactic feature which has such a complicated
> expansion? I fear it will make code using "yield from" much more difficult to
> understand and audit.
1 - 100 of 102 matches
Mail list logo
