Python 3: dict & dict.keys()
tjreedy at udel.edu
Thu Jul 25 01:45:37 CEST 2013
On 7/24/2013 4:34 PM, Prasad, Ramit wrote:
> I am still not clear on the advantage of views vs. iterators.
A1: Views are iterables that can be iterated more than once. Therefore,
they can be passed to a function that re-iterates its inputs, or to
multiple functions. They support 'x in view' as efficiently as possible.
Think about how you would write the non-view equivalent of '(0,None) in
somedict.views())'. When set-like, views support some set operations.
For .keys, which are always set-like, these operations are easy to
implement as dicts are based on a hashed array of keys.
Q2: What is the advantage of views vs. lists?
A2: They do not take up space that is not needed. They can be converted
to lists, to get all the features of lists, but not vice versa.
> What makes d.viewkeys() better than d.iterkeys()? Why did they decide
> not to rename d.iterkeys() to d.keys() and instead use d.viewkeys()?
This is historically the wrong way to phrase the question. The 2.7
.viewxyz methods were *not* used to make the 3.x .xyz methods. It was
the other way around. 3.0 came out with view methods replacing both list
and iter methods just after 2.6, after a couple of years of design, and
a year and a half before 2.7. The view methods were backported from 3.1
to 2.7, with 'view' added to the name to avoid name conflicts, to make
it easier to write code that would either run on both 2.7 and 3.x or be
converted with 2to3.
A better question is: 'When 3.0 was designed, why were views invented
for the .xyz methods rather than just renaming the .iterxyz methods. The
advantages given above are the answer. View methods replace both list
and iterator methods and are more flexible than either and directly or
indirectly have all the advantages of both.
My question is why some people are fussing so much because Python
developers gave them one thing that is better than either of the two
things it replaces?
The mis-phrased question above illustrates why people new to Python
should use the latest 3.x and ignore 2.x unless they must use 2.x
libraries. 2.7 has all the old stuff, for back compatibility, and as
much of the new stuff in 3.1 as seemed sensible, for forward
compatibility. Thus it has lots of confusing duplication, and in this
Terry Jan Reedy
More information about the Python-list