Guido van Rossum wrote:
> On 3/23/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
>> Or a view would work just as well, I suppose. Maybe you've just made
>> the argument that it should return an iterable, not an iterator.
>
> Technically an iterator is an iterable, so requiring it to return an
> iterable doesn't solve your problem. Requiring a sequence or a
> collection which may be a view instead of a copy *does* solve it, so I
> propose to go for that. This would also solve the redundancy of having
> iter(d) and iter(d.keys()) return the same thing -- d.keys() would
> return a set (not multiset!) view which has other uses than either d
> or iter(d).
Well, d.keys and d.items would be set views, while d.values would be a
multiset view.
For sequence views (the equivalent of Java's List.subList), maybe it would
make sense to have a separate 'seqview' type that gives a view on an arbitrary
existing sequence. First argument would be the sequence itself, while the
second argument would be an optional slice that limited the visible sequence
elements.
Something like:
>>> data = range(10)
>>> view_all = seqview(data)
>>> view_end = view_all[5:10]
>>> view_end[0] = 10
>>> data[5]
10
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
