[Python-Dev] Toowtdi: Datatype conversions

[Martin v. Loewis]

Raymond Hettinger wrote:
> Choosing between:
> 
>     list(d)  or   d.keys()
> 
> Which is the one obvious way of turning a dictionary into a list?  
> IMO, list(d) is it.

Neither. There is no obvious way to turn a dictionary into a list;
lists and dictionaries are completely different things.

Dictionaries are similar to sets; in fact, Smalltalk as an
Association class (Assocation key: value:), and Dictionary
is a set of associations. Then, assuming there is an obvious
way to convert a set into a list, the most obvious way to
convert a dictionary into a list is

   d.items()

> So, one question is whether set() and frozenset() should grow an
> analogue to the keys() method:

But this is a completely different issue! For sets, there is an
obvious way (if you accept that the list will have the same elements
in arbitrary order), then

   list(a_set)

is the most obvious way, and it should work fastest.

> Another question is whether there should be a method for conversion
> to a dictionary.  Given the absence of use cases, the answer is no, 
> but assuming there were, what would be the right way to go?

There is no obvious way to convert a set into a dictionary, as you
don't know what the values should be (refuse the temptation to
guess).

If there was a use case, that use case would indicate what the
values should be, and, from the use case, it would be clear
what the method name would be. It would not be "asdict".

> One bright idea is to make the constructors a little bit smarter
> so that list(d) would automagically invoke d.keys() whenever
> d is a dictionary.  

But who needs list(d)?

> Another bright idea is to support faster datatype conversion
> by adding an optional __len__() method to the iteration 
> protocol so that list(), tuple(), dict(), and set() could
> allocate sufficient space for loading any iterable that
> knows its own length.

That is useful, also for list comprehension.

> The advantages are faster type conversion (by avoiding resizing),
> keeping the APIs decoupled, and keeping the visible API thin.
> This disadvantage is that it clutters the C code with special
> case handling and that it doesn't work with generators or
> custom iterators (unless they add support for __len__).

I see no reason why it should not work for custom iterators.
For generators, you typically don't know how many results you
will get in the end, so it is no loss that you cannot specify
that.

Regards,
Martin