[Python-Dev] Toowtdi: Datatype conversions (original) (raw)

Martin v. Loewis martin at v.loewis.de
Sat Jan 3 16:39:30 EST 2004

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

More information about the Python-Dev mailing list