[Python-Dev] RE: cloning iterators again
aleaxit at yahoo.com
Mon Oct 27 02:51:02 EST 2003
On Monday 27 October 2003 06:12, Raymond Hettinger wrote:
> My question was more directed toward non-performance issues. Do we
> really have *any* need for more than two iterators running concurrently?
I admit I have no use cases for that. It was probably a case of over-eager
generalization on my part.
I understand and appreciate all of your other explanations on performance,
> > I also note that the current tee() doesn't let you use __copy__ easily
> > (it would be quite messy I think).
> To __copy__ is to tee. Both make two iterators from one.
> They are different names for the same thing.
> Right now, they don't seem comparable because the current tee is only a
> two way split and you think of copy as being a multi-way split for no
> extra cost.
I don't understand this. __copy__ is a special method that a type may
or may not expose. If it does, copy.copy(x) on an instance x of that type
makes and returns one (shallow) copy of x. I just got a PEP number
(323) for Copyable Iterators as recently discussed, and hope to commit
the PEP within today. But, basically, the idea is trivially simple:
iterators which really have a tiny amount of state, such as those on
sequences and dicts, will expose __copy__ and implement it by just
duplicating said tiny amount (one pointer to a container and an index).
But I don't understand how it would be quite messy to take advantage
of this in tee(), either: simply, tee() would start with the equivalent of
it = iter(it)
try: return it, copy.copy(it)
and proceed just like now if this shortcut hasn't worked -- that's all.
More information about the Python-Dev