"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.
But if classmethods are intended to provide alternate constructors then one could argue that the functions in itertools are appropriate as they all produce iterators and are thus something like alternate iter constructors. Of course you don't want every function that produces an iterator as a member of the iter type, just like you don't want every function that produces a dict as a member of the dict type. But I could see that it might be reasonable to put some of the more commonly used "alternate constructors" there...
STeVe -- http://mail.python.org/mailman/listinfo/python-list
