[Python-Dev] Toowtdi: Datatype conversions

Raymond Hettinger raymond.hettinger at verizon.net
Sat Jan 3 16:27:45 EST 2004


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.

Which is the fastest?  
timeit.Timer() says d.keys() is several times faster.

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

>>> set('banana').elements()
['a', 'b', 'n']

This speeds-up the uniquification use case but comes at the expense
of fattening the API and adding a second way to do it.

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?
set.asdict() would be several times faster than dict.fromkeys(s).

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.  The problem with this idea is that list
creation is separate from list initialization.  list.__init__()
starts with an existing list and replaces its contents with
the initializer.  The precludes returning a list built by d.keys().

The situation for dicts is similar although there is a curious
difference, dict.__init__() updates rather than replaces the
contents of the underlying dictionary.

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.

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__).


Raymond Hettinger




More information about the Python-Dev mailing list