I really like the PEP - it's a solid extension of the ideas introduced
by PEP 342.
The two changes I would suggest is that the PEP be made more explicit
regarding the fact that the try/finally block only enclose the yield
expression itself (i.e. no other parts of the containing statement) and
that
Nick Coghlan gmail.com> writes:
>
> And that it formally expanded to:
>
>
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.
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.
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
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
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
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
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
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.
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
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 --
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
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.
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
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
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
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 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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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
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
>
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
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
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
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
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.
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:
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
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
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:
>
>> 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
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
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
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
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
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
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
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:
>
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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.
80 matches
Mail list logo
