Python 3: dict & dict.keys()

[Terry Reedy]

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 
case, triplication

-- 
Terry Jan Reedy