itertools to iter transition (WAS: Pre-PEP: Dictionaryaccumulator methods)

George Sakkis gsakkis at
Wed Mar 30 05:47:12 CEST 2005

"Terry Reedy" <tjreedy at> wrote:
> "Steven Bethard" <steven.bethard at> wrote in message
> news:t8GdnWcs-9J6AdTfRVn-hw at
> > True it's not a huge win.  But I'd argue that for the same reasons that
> > dict.fromkeys is a dict classmethod, the itertools methods could be iter
> > classmethods (or staticmethods).
> As near as I could tell from the doc, .fromkeys is the only dict method
> that is a classmethod (better, typemethod) rather than an instance method.
> And all list methods are instance methods.  And I believe the same is true
> of all number operations (and the corresponding special methods).  So
> .fromkeys seems to be an anomaly.
> I believe the reason for its existence is that the signature for dict()
> itself was already pretty well 'used up' and Guido preferred to add an
> alternate constructor as a method rather than further complicate the
> signature of dict() by adding a fromkeys flag to signal an alternate
> interpretation of the first and possibly the second parameter.
> Terry J. Reedy

Apart from the anomaly you mention, it's hard to justify dict.fromkeys' existence in today's python.
For one thing, how often does one need to initialize a dict with a bunch of keys mapped to the same
value ? I imagine this would be handy, for example, in ad-hoc implementations of sets before
python2.3, where the set elements were stored internally as keys in a dict and the values were not
used. Even when initializing with the same value is necessary, this can be accomplished in 2.4 with
essentially the same performance in one line (dict((i,value) for i in iterable)). The few more
keystrokes are just not worth an extra rarely used method. It looks like an a easy target for
removal in python 3K.


More information about the Python-list mailing list