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

[Terry Reedy]

"Steven Bethard" <steven.bethard at gmail.com> wrote in message 
news:UvSdnQOHBJMWpNffRVn-sA at comcast.com...
> 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.

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