"Terry Reedy" <[EMAIL PROTECTED]> wrote: > > "Steven Bethard" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > 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. George -- http://mail.python.org/mailman/listinfo/python-list
