> "Paul" == Paul Moore <[EMAIL PROTECTED]> writes:
Paul> You can work around the need for something like yield_all,
Paul> or explicit loops, by defining an "iflatten" generator,
Paul> which yields every element of its (iterable) argument,
Paul> unless the element is a generator
On Thu, 03 Mar 2005 20:47:42 +, Paul Moore wrote:
> This can probably be tidied up and improved, but it may be a
> reasonable workaround for something like the original example.
This is why even though in some sense I'd love to see yield *expr, I can't
imagine it's going to get into the langua
Skip Montanaro <[EMAIL PROTECTED]> writes:
> Doug>def foogen(arg1):
>
> Doug> def foogen1(arg2):
> Doug> # Some code here
>
> Doug> # Some code here
> Doug> yield_all foogen1(arg3)
> Doug> # Some code here
> Doug> yield_all foo
Jeremy Bowers wrote:
At first I liked this, but the reason that is a syntax error is that it is
"supposed" to be
def f():
yield (x for x in gen1(arg))
which today on 2.4 returns a generator instance which will in turn
yield one generator instance from the genexp
And it would continue to do so i
Douglas Alan wrote:
Wouldn't
yield *(x for x in gen1(arg))
be sufficient, and would already be supported by the proposal at
hand?
It would, but, as Steven pointed out, the * in func(*args) results in
tuple(args) being passed to the underlying function.
So I see no reason to expect "yield *iter
Le mercredi 2 Mars 2005 21:32, Skip Montanaro a écrit :
> def f():
> yield from (x for x in gen1(arg))
>
> Skip
This suggestion had been made in a previous posting and it has my preference :
def f():
yield from gen1(arg)
Regards
Francis
--
http://mail.python.org/mailman/listinfo/python
Jeremy> At first I liked this, but the reason that is a syntax error is
Jeremy> that it is "supposed" to be
Jeremy> def f():
Jeremy> yield (x for x in gen1(arg))
Jeremy> which today on 2.4 returns a generator instance which will in
Jeremy> turn yield one generator ins
On Wed, 02 Mar 2005 22:54:14 +1000, Nick Coghlan wrote:
> Douglas Alan wrote:
>> Steve Holden <[EMAIL PROTECTED]> writes:
>>>Guido has generally observed a parsimony about the introduction of
>>>features such as the one you suggest into Python, and in particular
>>>he is reluctant to add new keywo
Nick Coghlan <[EMAIL PROTECTED]> writes:
> If you do write a PEP, try to get genexp syntax supported by the
> yield keyword.
> That is, the following currently triggers a syntax error:
>def f():
> yield x for x in gen1(arg)
Wouldn't
yield *(x for x in gen1(arg))
be sufficient, and
Terry Reedy wrote:
"Steven Bethard" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
My suspicion is that if he doesn't like the * syntax when there's a close
parallel to the argument parsing usage, he's not likely to like it when
there isn't one.
Hmm. My impression is that Guido did
"Steven Bethard" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Douglas Alan wrote:
>> In this case, that is great, since I'd much prefer
>>
>>yield *gen1(arg)
>>
>> than
>>
>>yield_all gen1(arg)
>
> I'm guessing the * syntax is pretty unlikely to win Guido's approval.
> T
Douglas Alan wrote:
Steven Bethard <[EMAIL PROTECTED]> writes:
I'm guessing the * syntax is pretty unlikely to win Guido's
approval. There have been a number of requests[1][2][3] for syntax
like:
x, y, *rest = iterable
Oh, it is so wrong that Guido objects to the above. Python needs
fully des
Douglas Alan wrote:
Steve Holden <[EMAIL PROTECTED]> writes:
Guido has generally observed a parsimony about the introduction of
features such as the one you suggest into Python, and in particular
he is reluctant to add new keywords - even in cases like decorators
that cried out for a keyword rathe
> "Douglas" == Douglas Alan <[EMAIL PROTECTED]> writes:
Douglas> If you actually try doing this, you will see why I want
Douglas> "yield_all".
Oh... I see your point.
I was about to suggest that the code in my posts before should be made
to work somehow. I mean, if in
def fun1(x)
Isaac To <[EMAIL PROTECTED]> writes:
>> "Isaac" == Isaac To <[EMAIL PROTECTED]> writes:
>
> def gen_all(gen):
> for e in gen:
> yield e
>
> def foogen(arg1):
> def foogen1(arg2):
> # Some code here
> # Some code here
> gen_all(arg3)
> ^ I mean foogen
> "Isaac" == Isaac To <[EMAIL PROTECTED]> writes:
def gen_all(gen):
for e in gen:
yield e
def foogen(arg1):
def foogen1(arg2):
# Some code here
# Some code here
gen_all(arg3)
^ I mean foogen1(arg3), obviously, and similar for below
# Some code h
> "Douglas" == Douglas Alan <[EMAIL PROTECTED]> writes:
Douglas> If you'll reread what I wrote, you'll see that I'm not
Douglas> concerned with performance, but rather my concern is that
Douglas> I want the syntactic sugar. I'm tired of writing code
Douglas> that looks like
Steven Bethard <[EMAIL PROTECTED]> writes:
> I'm guessing the * syntax is pretty unlikely to win Guido's
> approval. There have been a number of requests[1][2][3] for syntax
> like:
> x, y, *rest = iterable
Oh, it is so wrong that Guido objects to the above. Python needs
fully destructurin
Douglas Alan wrote:
In this case, that is great, since I'd much prefer
yield *gen1(arg)
than
yield_all gen1(arg)
I'm guessing the * syntax is pretty unlikely to win Guido's approval.
There have been a number of requests[1][2][3] for syntax like:
x, y, *rest = iterable
for unpacking a va
Steve Holden <[EMAIL PROTECTED]> writes:
> Guido has generally observed a parsimony about the introduction of
> features such as the one you suggest into Python, and in particular
> he is reluctant to add new keywords - even in cases like decorators
> that cried out for a keyword rather than the u
Douglas Alan wrote:
David Eppstein <[EMAIL PROTECTED]> writes:
In article <[EMAIL PROTECTED]>,
Douglas Alan <[EMAIL PROTECTED]> wrote:
Cetainly, if == , I don't see how anything
is gained except for a few keystrokes.
What's gained is making one's code more readable and maintainable,
which is t
David Eppstein <[EMAIL PROTECTED]> writes:
> In article <[EMAIL PROTECTED]>,
> Douglas Alan <[EMAIL PROTECTED]> wrote:
>> > Cetainly, if > > iterator> == , I don't see how anything
>> > is gained except for a few keystrokes.
>> What's gained is making one's code more readable and maintainable,
Francis Girard <[EMAIL PROTECTED]> writes:
> Therefore, the suggestion you make, or something similar, would have
> actually ease my learning, at least for me.
Yes, I agree 100%. Not having something like "yield_all" hurt my
ability to learn to use Python's generators quickly because I figured
t
Oops. I meant "without having" instead of "with having" which is a syntax
error.
Regards
Le mardi 1 Mars 2005 22:53, Francis Girard a ÃcritÂ:
> No, this won't do. What is needed is a way to yield the results of a
> generator from inside another generator with having to do a for-yield-loop
> insi
Hi,
No, this won't do. What is needed is a way to yield the results of a generator
from inside another generator with having to do a for-yield-loop inside the
outter generator.
Regards,
Francis Girard
Le mardi 1 Mars 2005 22:35, Adam Przybyla a ÃcritÂ:
> ... mayby that way:
> ython 2.
Douglas Alan <[EMAIL PROTECTED]> wrote:
> While writing a generator, I was just thinking how Python needs a
> "yield_all" statement. With the help of Google, I found a
> pre-existing discussion on this from a while back in the Lightweight
> Languages mailing list. I'll repost it here in order to
In article <[EMAIL PROTECTED]>,
Douglas Alan <[EMAIL PROTECTED]> wrote:
> > Cetainly, if > iterator> == , I don't see how anything
> > is gained except for a few keystrokes.
>
> What's gained is making one's code more readable and maintainable,
> which is the one of the primary reasons that I u
Mike C. Fletcher wrote:
... it nicely encapsulates the learning of "generators" so that
when you see yield up front you know something generatish is going on.
+1 for "generatish" as VOTW (Vocabulation of the Week). =)
STeVe
--
http://mail.python.org/mailman/listinfo/python-list
Skip Montanaro wrote:
...
If this idea advances I'd rather see extra syntactic sugar introduced to
complement the current yield statement instead of adding a new keyword.
It's a bit clumsy to come up with something that will work syntactically
since the next token following the yield keyword can be
Hi,
You absolutely and definitively have my vote.
When I first learned the generators , I was even wondering if there was
something wrong in what I do when faced with the sub-generators problem you
describe. I was wondering "why am I doing this extra for-loop ? Is there
something wrong ? Can
On Tue, 01 Mar 2005 12:42:51 -0600, Skip Montanaro wrote:
> yield
yield *
(Mu-hu-ha-ha-ha!)
--
http://mail.python.org/mailman/listinfo/python-list
Doug>def foogen(arg1):
Doug> def foogen1(arg2):
Doug> # Some code here
Doug> # Some code here
Doug> yield_all foogen1(arg3)
Doug> # Some code here
Doug> yield_all foogen1(arg4)
Doug> # Some code here
Doug>
Duncan Booth <[EMAIL PROTECTED]> writes:
> Douglas Alan wrote:
>> "Terry Reedy" <[EMAIL PROTECTED]> writes:
>>> Cetainly, if >> iterator> == , I don't see how anything
>>> is gained except for a few keystrokes.
>> What's gained is making one's code more readable and maintainable,
>> which is th
Douglas Alan wrote:
> "Terry Reedy" <[EMAIL PROTECTED]> writes:
>
>> Cetainly, if > iterator> == , I don't see how anything
>> is gained except for a few keystrokes.
>
> What's gained is making one's code more readable and maintainable,
> which is the one of the primary reasons that I use Python
"Terry Reedy" <[EMAIL PROTECTED]> writes:
> Cetainly, if iterator> == , I don't see how anything
> is gained except for a few keystrokes.
What's gained is making one's code more readable and maintainable,
which is the one of the primary reasons that I use Python.
|>oug
--
http://mail.python.or
Andrew Dalke <[EMAIL PROTECTED]> writes:
> On Mon, 28 Feb 2005 18:25:51 -0500, Douglas Alan wrote:
>> While writing a generator, I was just thinking how Python needs a
>> "yield_all" statement. With the help of Google, I found a
>> pre-existing discussion on this from a while back in the
>> Ligh
Op 2005-03-01, Steve Holden schreef <[EMAIL PROTECTED]>:
> Terry Reedy wrote:
>> "Douglas Alan" <[EMAIL PROTECTED]> wrote in message
>> news:[EMAIL PROTECTED]
>>
>>>We can shorten the code--and make it run in O(N) time--by adding a
>>>new
>>>keyword to replace the "for v in ...: yield v"
Terry Reedy wrote:
"Douglas Alan" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
We can shorten the code--and make it run in O(N) time--by adding a
new
keyword to replace the "for v in ...: yield v" pattern:
Maybe. Until you define the semantics of yield_all and at least out
"Douglas Alan" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> We can shorten the code--and make it run in O(N) time--by adding a
> new
> keyword to replace the "for v in ...: yield v" pattern:
Maybe. Until you define the semantics of yield_all and at least outline an
im
On Mon, 28 Feb 2005 18:25:51 -0500, Douglas Alan wrote:
> While writing a generator, I was just thinking how Python needs a
> "yield_all" statement. With the help of Google, I found a pre-existing
> discussion on this from a while back in the Lightweight Languages
> mailing list. I'll repost it h
While writing a generator, I was just thinking how Python needs a
"yield_all" statement. With the help of Google, I found a
pre-existing discussion on this from a while back in the Lightweight
Languages mailing list. I'll repost it here in order to improve the
chances of this enhancement actually
41 matches
Mail list logo
