On Aug 26, 2:30 pm, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> 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 :) -- http://mail.python.org/mailman/listinfo/python-list