generator object, next method

[simonwittber]

gen = iterator()False


What is behind this apparently strange behaviour? (The .next method
seems to alternately bind to two different objects)

Sw.

 

[Peter Otten]

<method-wrapper object at 0x009D1B70>

Behind the scene, gen.next is bound to _, i. e. it cannot be
garbage-collected. Then...

<method-wrapper object at 0x009D1BB0>

a new method wrapper is created and assigned to _, and the previous method
wrapper is now garbage-collected. The memory location is therefore
available for reuse for...

<method-wrapper object at 0x009D1B70>

yet another method wrapper -- and so on.

False


What is behind this apparently strange behaviour? (The .next method
seems to alternately bind to two different objects)

But it isn't. What seems to be the same object are distinct objects at the
same memory location. See what happens if you inhibit garbage-collection by
keeping a reference of the method wrappers:

it = iter("")
[it.next for _ in range(5)]

[<method-wrapper object at 0x4029388c>, <method-wrapper object at
0x402938ec>, <method-wrapper object at 0x402938cc>, <method-wrapper object
at 0x4029390c>, <method-wrapper object at 0x4029392c>]

Peter

 

[Duncan Booth]

False


What is behind this apparently strange behaviour? (The .next method
seems to alternately bind to two different objects)

It is a combination of factors.

1) Every time you access gen.next you create a new method-wrapper object.
2) Typing an expression at the interactive prompt implicitly assigns the
result of the expression to the variable '_'
3) When the method-wrapper is destroyed the memory becomes available to be
reused the next time a method-wrapper (or other object of similar size) is
created.

So in fact you have 6 different objects produced by your 6 accesses to
gen.next although (since you never have more than 3 of them in existence at
a time) there are probably only 3 different memory locations involved.

 

[Paul Rubin]

1) Every time you access gen.next you create a new method-wrapper object.

Why is that? I thought gen.next is a callable and gen.next() actually
advances the iterator. Why shouldn't gen.next always be the same object?

 

[simonwittber]

Why is that? I thought gen.next is a callable and gen.next() actually
advances the iterator. Why shouldn't gen.next always be the same object?

That is, in essence, my question.

Executing the below script, rather than typing at a console, probably
clarifies things a little.

Sw.

#-------------------
def iterator():
yield None

gen = iterator()

#gen.next is bound to x, and therefore, gen.next should not be GC?
x = gen.next
y = gen.next
print x
print y
print gen.next
#-------------------

 

[Diez B. Roggisch]

That is, in essence, my question.

Because bound methods are generated on the fly - google this group,
there have been plenty of discussions about that.

Diez

 

[Duncan Booth]

Why is that? I thought gen.next is a callable and gen.next() actually
advances the iterator. Why shouldn't gen.next always be the same
object?

It is a consequence of allowing methods to be first class objects, so
instead of just calling them you can also save the bound method in a
variable and call it with the 'self' context remembered in the method.

It is easier to see what is happening if you look first at ordinary Python
classes and instances:
def next(self): pass

<unbound method C.next>

Here, 'next' is a method of the class C. You can call the unbound method,
but then you have to explicitly pass the 'self' argument.

Whenever you access the method through an instance it creates a new 'bound
method' object which stores references to both the original function, and
the value to be passed in as the first parameter. Usually this object is
simply called and discarded, but you can also save it for later use.

Python could perhaps bypass the creation of bound method objects when
calling a function directly, but it would still need them for cases where
the method isn't called immediately (and it isn't obvious it would be an
improvement if it tried to optimise this case).

It would be possible for a language such as Python to try to either
generate these bound method objects in advance (which would be horribly
inefficient if you created lots of objects each of which had hundreds of
methods which were never called), or to cache bound method objects so as to
reuse them (which would be inefficient if you have lots of methods called
only once on each object). Python chooses to accept the hit of creating
lots of small objects, but tries to make the overhead of this as low as
possible (which is one reason the memory gets reused immediately).

The next method in a generator works in the same way as bound methods,
although the actual types involved are C coded. You can still access both
the bound and unbound forms of the next method. The bound form carries the
information about the first parameter, and the unbound form has to be given
that information:
'hi'

 

[Terry Reedy]

Why is that? I thought gen.next is a callable and gen.next() actually
advances the iterator. Why shouldn't gen.next always be the same object?

If you explicitly or implicitly (via for loop) calculate gen.next exact
once (as I presume for loops do, and as I would for explicit while loop),
then it is. When you keep a reference to the wrapper, and call it
repeatedly via that wrapper, then all is as you expect.

next_x = genfunc(*args).next
while True:
x = next_x() # same next_x each time
<do something with x>

Terry J. Reedy