I complete agree that by
x = (z for z in y)
I create and assign a generator object to x.


I'm afraid I disagree about "not a doc bug".
The documentation for "for" reads:

===
for_stmt ::=  "for" target_list "in" expression_list ":" suite
              ["else" ":" suite]

The expression list is evaluated once; it should yield an iterable
object. An iterator is created for the result of the expression_list.
===
(http://docs.python.org/3.0/reference/compound_stmts.html#the-for-statement)

This ("an iterator is created") suggests that a new iterator is created
for the generator object (the iterable).

I was actually surprised to find that the __iter__() function of a
generator object returns the generator object itself. 


If generator objects behave as they do, I'm probably going to file a
feature request for something like "reusable" generators.

In fact, with the attached file I'm trying to extract a column from a
matrix and use it for several computations. Since I don't want to copy
the values of a column (imagine a huge matrix), I want to create a
reusable generator object that repeatedly returns a generator object
that enumerates the values of a single column.

My impression was that generator expressions are useful for just this
type of application.

Therefore, the attached file now as a small class ReusableGenerator that
implements this behavior. However, the "ugly" part is that in order to
create it, you have to pass it a function that returns a generator
object, not the generator object itself.

Another attempt by deep-copying completely fails, and I don't understand
why this is the case; probably there's a good reason.