Greg Ewing wrote:
> Guido van Rossum wrote:
>
>> Its maps have methods to
>> return keys, values and items, but these return neither new lists nor
>> iterators; they return "views" which obey set (or multiset, in the
>> case of items) semantics.
>
>> I'd like to explore this as an alternative to making keys() etc.
>> return iterators.
>
> This sounds like a really really good idea!
>
> It would solve Jim's problem, because the result of
> d.keys() would print out just like a real list, and
> then he could backspace over the .keys() and do
> something else.
If these things returned iterables rather than actual iterators (i.e. similar
to what xrange currently does), it would also address the fact that caching
references to iterators just doesn't work.
For example:
keys = d.keys()
big_key = max(keys)
little_key = max(keys)
If keys() returns a list or other iterable, all is good. If it returns an
actual iterator though. . .
I do find it somewhat interesting that we're considering moving the standard
containers to a more numpy-ish view of the world, though (i.e. one where
multiple mutable views of a data structure are common in order to avoid
unnecessary copying)
Would that philosophy be extended to slicing operations, though?
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
