George Sakkis wrote:
> And for those objecting to touching the existing iter() or bloating
> the builtin namespace with yet another builtin, let me mention that we
> can get rid of *two* existing functions which for some reason were
> promoted to builtin status, although they conceptually belong in
> itertools: enumerate and reversed.
FWIW, reversed isn't based on the iterator protocol - it needs a real sequence
(i.e. provides __getitem__ supporting indices from 0 to len(seq)-1), or
something that implements the __reversed__ special method. enumerate() was
made a builtin as it is a direct replacement for the zip(range(len(x)), x)
idiom.
As far as the 'flexible iterator' idea goes, I've had a rough implementation
of such a beast sitting on my hard drive for the last year and a half (since
shortly after that January '05 thread I linked to earlier in this discussion).
My conclusion from writing it was that depending on the implementation choices
you make in developing the class you will end up in one of two situations:
either 1. The entire iterator is soon loaded into memory as you manipulate it
or 2. The underlying iterator is consumed unexpectedly as you manipulate it
Which lead me to the conclusion that if you want richer access than the
iterator protocol provides then your best option is to dump the contents of
the iterator into an appropriate container and work with the container instead
of the iterator (possible segmenting the retrieval of values if you want to
limit peak memory usage).
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
