[EMAIL PROTECTED] wrote:
> Consider this example:
> 
>>>> X = range(5)
>>>> Y = iter(X)
>>>> Z = iter(Y)
> 
> As you can see, X is a container, and Y is an iterator.
> They are simliar in that "iter" works on them both.
> 
> Cristoph claims that this causes confusion.
> Why? Because "iter" doesn't have the same meaning for both of them.
> For X it always returns an iterator that yields the same set of values.
> For Y it returns an iterator yielding different values each time.

As an aside, perhaps iter(Y) should be returning a deeper 
copy of Y.  As it stands, I see 'Z=Y' giving the same effect:

 >>> y=iter(x)
 >>> z=iter(y)
 >>> zip(y, z)
[(0, 1), (2, 3)]
 >>> y=iter(x)
 >>> z=y
 >>> zip(y, z)
[(0, 1), (2, 3)]

[ ... ]

> But changing "iter" to have the same meaning for containers and
> iterables is impossible.
> You cannot, conceptually, reiterate an iterator.
> So what Cristoph is suggesting - is to add an exception for the cases
> in which iterators and collections behave differently.
> Somewhat similar to this:

But the end, raising StopIteration is not where the 
difference is.  The difference is in iter(some_object).

iter(some_container) creates a brand new iterator, standing 
at the starting line and ready to run.

iter(some_listiterator), it seems, just returns a reference 
to some_listiterator, with some of its history possibly 
behind it.

Iterators are used in the same syntactic places as general 
iterables, but especially once people start giving them 
names and handing them around, the real differences show up.

The short-range solution is Know What You're Doing.  Duck 
typing is a fine thing, but it works best for programmers 
who keep scrupulous track of their objects' types.

         Cheers,        Mel.
-- 
http://mail.python.org/mailman/listinfo/python-list

Reply via email to