"Steven Bethard" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Terry Reedy 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. > > True enough, and I also agree with George Sakkis's sentiment that > fromkeys() isn't really necessary now that set() is a builtin.
So perhaps it will disappear in the future. > But if classmethods are intended to provide alternate constructors But I do not remember that being given as a reason for classmethod(). But I am not sure what was. Terry J. Reedy -- http://mail.python.org/mailman/listinfo/python-list
