Paul Moore wrote:
> I still think my earlier analysis is important - for loops have no
> direct access to the iterator/view/whatever, and inline code has
> access to the original object. So the *only* relevant use cases are
> those where people are writing functions which take "extended
> iterator" arguments, where those functions cannot reasonably take
> either an additional argument which is the original object, or take
> the original object (an iterable) *instead* of an iterator.
The problem I thought the deletable-iterator proposal
was addressing was that it's often awkward to iterate
over something and delete selected items from it.
Even if you have the original object, you have to
either make a copy of it to iterate over while deleting
from the original, or keep a list of items to be
deleted and then delete them afterwards, both of
which are memory-inefficient.
If you knew you had a sequence that produces
deletable iterators, you could do
diter = iter(myseq)
for item in diter:
if is_nasty(item):
diter.delete()
If it were a general principle that mutable
containers produce deletable iterators, then
code such as the above would work on most
mutable containers.
So I think the idea does have some possible
merit, as an orthogonal issue to views.
--
Greg
_______________________________________________
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
