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

[Steven Bethard]

Terry Reedy wrote:
> "Steven Bethard" <steven.bethard at gmail.com> wrote in message 
> news:t8GdnWcs-9J6AdTfRVn-hw at comcast.com...
> 
>>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