Taro Ogawa wrote:
> [Originally misposted to python-dev]
> Nick Coghlan <ncoghlan <at> gmail.com> writes:
>> There are three big use cases:
>> dict.keys
>> dict.values
>> dict.items
>> Currently these all return lists, which may be expensive in terms of copying.
>> They all have iter* variants which while memory efficient, are far less
>> convenient to work with.
> <delurk>
> Is there any reason why they can't be view objects - a dictionary has keys,
> has values, has items - rather than methods returning view objects:
> for k in mydict.keys:
> ...
> for v in mydict.values:
> ...
> for k, v in mydict.items:
> ...
> For backward compatibility with Py2.x, calling them would raise a
> DeprecationWarning and return a list. This could even be introduced in 2.x
> (with a PendingDeprecationWarning instead?).
Too much pain for not enough gain, IMO. The only real benefit is avoiding
typing a couple of parentheses, but we'd be breaking an awful lot more code
than the change of data type will break. One of the great joys of duck-typing
is that so long as what we return is sufficiently containerish, a lot of code
will continue to just work.
It's only code that requires an *actual* list (e.g. by indexing, slicing or
sorting the result directly) that will need to change to wrap the method call
in either list() or sorted().
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
