On 23/03/22 11:44 am, Rathmann wrote:
So that sounds like the original CPython implementation had an
O(depth) component, but with a lower constant factor than the current
version?
Yes, but so much lower that I would expect it to be unmeasurable.
--
Greg
--
https://mail.python.org/mailman/list
> On 19 Mar 2022, at 03:07, Greg Ewing wrote:
>
> On 19/03/22 9:40 am, Rathmann wrote:
>> The other challenge/question would be to see if there is a way to implement
>> this basic approach with lower overhead.
>
> My original implementation of yield-from didn't
> On 19 Mar 2022, at 03:07, Greg Ewing wrote:
>
> On 19/03/22 9:40 am, Rathmann wrote:
>> The other challenge/question would be to see if there is a way to implement
>> this basic approach with lower overhead.
>
> My original implementation of yield-from didn
On Sat, 19 Mar 2022 at 14:06, Greg Ewing wrote:
>
> On 19/03/22 9:40 am, Rathmann wrote:
> > The other challenge/question would be to see if there is a way to implement
> > this basic approach with lower overhead.
>
> My original implementation of yield-from didn't ha
On 19/03/22 9:40 am, Rathmann wrote:
The other challenge/question would be to see if there is a way to implement
this basic approach with lower overhead.
My original implementation of yield-from didn't have this problem,
because it didn't enter any of the intermediate frames -- i
toon. I was not aware of macropy. It certainly seems
like a macro could automate the process of switching the "yield from"
to yield forms. That is already pretty easy to do by hand, though.
The driver itself could be packaged as a decorator using just the
facilities available in regular Pyt
ration:
stack.pop()
if len(stack) == 0:
return
```
and the modified tree traverser is just
```python
def inorder_traverse_mod(node):
"""ONLY for use with recursive_generator_driver"""
k, l, r = node
if l:
the
"yield from" syntax which provides a technique for generators to
delegate to other generators, including recursively.
The trouble is that recursion and generators don't necessarily play
all that well together from a performance point of view. As Greg
Ewing noted in PEP 380:
On 03/03/2021 01:01, Cameron Simpson wrote:
On 02Mar2021 15:06, Larry Martell wrote:
I discovered something new (to me) yesterday. Was writing a unit test
for generator function and I found that none of the function got
executed at all until I iterated on the return value.
Aye. Generators are
over
> >>> the subboxes. For MDAT that is implemented like this:
> >>>
> >>> def __iter__(self):
> >>> yield from ()
> >>
> >> Sorry, a bit OT but I'm curious. I haven't seen
> >> this before:
> >>
t;>>
>>> def __iter__(self):
>>> yield from ()
>>
>> Sorry, a bit OT but I'm curious. I haven't seen
>> this before:
>>
>> yield from ()
>>
>> What is it doing?
>> What do the () represent in this context?
>
>
On 02Mar2021 15:06, Larry Martell wrote:
>I discovered something new (to me) yesterday. Was writing a unit test
>for generator function and I found that none of the function got
>executed at all until I iterated on the return value.
Aye. Generators are lazy - they don't run at all until you ask f
> > > the subboxes. For MDAT that is implemented like this:
> > >
> > > def __iter__(self):
> > > yield from ()
> >
> > Sorry, a bit OT but I'm curious. I haven't seen
> > this before:
> >
> > yield from ()
>
On Mon, 1 Mar 2021 at 19:51, Alan Gauld via Python-list
wrote:
> Sorry, a bit OT but I'm curious. I haven't seen
> this before:
>
> yield from ()
>
> What is it doing?
> What do the () represent in this context?
It's the empty tuple.
--
https://mail.python.org/mailman/listinfo/python-list
__iter__(self):
> > yield from ()
>
> Sorry, a bit OT but I'm curious. I haven't seen
> this before:
>
> yield from ()
>
> What is it doing?
> What do the () represent in this context?
>
It's yielding all the elements in an empty tuple. W
On 28/02/2021 23:47, Alan Gauld via Python-list wrote:
> On 28/02/2021 00:17, Cameron Simpson wrote:
>
>> BUT... It also has a __iter__ value, which like any Box iterates over
>> the subboxes. For MDAT that is implemented like this:
>>
>> def __iter_
On Wed, Mar 3, 2021 at 8:21 AM Dieter Maurer wrote:
>
> Alan Gauld wrote at 2021-2-28 23:47 +0000:
> >yield from ()
>
> "yield from iterator" is similar to "for i in iterator: yield i" (with
> special handling when data/exceptions are injected into the g
Alan Gauld wrote at 2021-2-28 23:47 +:
>yield from ()
"yield from iterator" is similar to "for i in iterator: yield i" (with
special handling when data/exceptions are injected into the generator).
Thus, "yield from ()" does essentially nothing with th
On 01/03/2021 00:47, Alan Gauld via Python-list wrote:
On 28/02/2021 00:17, Cameron Simpson wrote:
BUT... It also has a __iter__ value, which like any Box iterates over
the subboxes. For MDAT that is implemented like this:
def __iter__(self):
yield from ()
Sorry, a bit OT but
On 28Feb2021 23:47, Alan Gauld wrote:
>On 28/02/2021 00:17, Cameron Simpson wrote:
>> BUT... It also has a __iter__ value, which like any Box iterates over
>> the subboxes. For MDAT that is implemented like this:
>>
>> def __iter__(self):
>> yield f
On 28/02/2021 00:17, Cameron Simpson wrote:
> BUT... It also has a __iter__ value, which like any Box iterates over
> the subboxes. For MDAT that is implemented like this:
>
> def __iter__(self):
> yield from ()
Sorry, a bit OT but I'm curious. I haven't
On Wed, Mar 25, 2020 at 10:08 AM Dan Stromberg wrote:
>
> Some time ago, when I first heard about yield from, it wasn't faster than a
> for loop yielding.
>
> Has that improved?
It's not about speed. It's about correctness, and the way it delegates
everything, no
Some time ago, when I first heard about yield from, it wasn't faster than a
for loop yielding.
Has that improved?
--
https://mail.python.org/mailman/listinfo/python-list
Makoto Kuwata wrote:
> Question about 'yield from'.
>
> I understand that::
>
> yield from xs
>
> is syntax suger of::
>
> for x in xs:
> yield x
Not quite syntactic sugar. For simple cases, it does exactly the same thing.
For more co
On Thu, Aug 14, 2014 at 7:02 PM, Chris Angelico wrote:
> On Thu, Aug 14, 2014 at 7:59 PM, Makoto Kuwata wrote:
> > I understand that 'val = yield from xs' is completely different from::
> >
> >for x in xs:
> > ret = yield x
> >va
Makoto Kuwata :
> Thank you. It seems too complicated...
I recommend you stop trying to associate the "old" yield with the "new"
yield.
Asyncio coroutines "abuse" "yield from" for a specific effect. The
classic purpose of "yield" was to spo
On Thu, Aug 14, 2014 at 7:59 PM, Makoto Kuwata wrote:
> I understand that 'val = yield from xs' is completely different from::
>
>for x in xs:
> ret = yield x
>val = x
>
> Return value is propagated by StopIteration, like:
>
>i
Makoto Kuwata :
> val = yield from xs
>
> is same as::
>
> for x in xs:
> ret = yield x
> val = ret
>
> Is it true? Do I understand correctly?
The return value is not one of the yielded values. Instead, it's the
value returned by the genera
On Thu, Aug 14, 2014 at 6:38 PM, Chris Angelico wrote:
> On Thu, Aug 14, 2014 at 7:35 PM, Makoto Kuwata wrote:
> > I understand that::
> >
> > yield from xs
> >
> > is syntax suger of::
> >
> > for x in xs:
> > yield x
>
>
On Thu, Aug 14, 2014 at 7:35 PM, Makoto Kuwata wrote:
> I understand that::
>
> yield from xs
>
> is syntax suger of::
>
> for x in xs:
> yield x
Not just. It's like that for simple cases, but there are edge cases
that are much more complicated to do m
Question about 'yield from'.
I understand that::
yield from xs
is syntax suger of::
for x in xs:
yield x
And::
val = yield from xs
is same as::
for x in xs:
ret = yield x
val = ret
Is it true? Do I understand correctly?
quote from
https://docs.
Regarding http://www.python.org/dev/peps/pep-0380/,
"Syntax for Delegating to a Subgenerator":
The first call can only be .next(), there's no way to provide an initial
value to .send(). That matches common use, but an initial .send() is
possible if .next() was called before &quo
32 matches
Mail list logo
