RetroSearch Browse

Mon Oct 27 02:51:02 EST 2003 · https://mail.python.org/pipermail/python-dev/2003-October/039608.html

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,
except one:

> > 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)
    except TypeError:pass
and proceed just like now if this shortcut hasn't worked -- that's all.

Alex

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2003-October/039608.html below:

[Python-Dev] RE: cloning iterators again