why in returns values for array and keys for dictionary

[alex23]

On Aug 26, 2:30 pm, Marc 'BlackJack' Rintsch <bj_... at gmx.net> wrote:
> The OP isn't talking about the ``in`` operator but ``in`` as part of
> ``for … in …``.  So it's actually the question why ``list(a_dict)``
> doesn't return a list of values but a list of keys.

Aaaah! Cheers, Marc, that didn't occur to me.

imanshu: my apologies for the confusion in my original replies, I now
understand what you mean.

I'd hazard to suggest the answer is one of practicality over purity
between object types.

I can actually see there being a perceived advantage in providing a
consistent interface, so that:

for index,value in array('i',[0,1,2]): ...
for index,value in [0,1,2]: ...
for key,value in {'0':0,'1':1,'2':2}: ...

would all produce equivalent results. I'd guess that what is provided
now meets the most common use cases, with convenience functions
readily available for the next most common, ie via enumerate() for
arrays & lists, and .itervalues() or .iteritems() for dicts.

It all comes down to the intent of the data types used. I'm -
generally- more concerned with the values of a list than knowing their
position, especially when the position is implicit in the order
returned. When working with dicts, if I need to modify their contents
I -need- to know the key, as the key isn't an implicit aspect of the
return order of the values, and is the only way distinguish between
identical values.

I'm -still- embarrassed that I missed the existence of the array type,
however :)