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

[Michael Spencer]

Steven Bethard wrote:
> Ville Vainio wrote:
> 
>>>>>>> "Raymond" == Raymond Hettinger <vze4rx4y at verizon.net> writes:
>>
>>
>>
>>     Raymond> If the experience works out, then all you're left with is
>>     Raymond> the trivial matter of convincing Guido that function
>>     Raymond> attributes are a sure cure for the burden of typing
>>     Raymond> import statements.
>>
>> For one thing, it would make it harder to find the functions from the
>> docs. It's easy to find the doc for 'itertools', but iter object
>> methods would require browsing that infamous Chapter 2 of the
>> documentation...
> 
> 
> Well, it would only make them as hard to find as, say, dict.fromkeys, 
> which is probably the best parallel here.  Of course iter would have to 
> be documented as a builtin type.  I don't find the argument "builtin 
> type methods are hard to find" convincing -- the solution here is to fix 
> the documentation, not refuse to add builtin types.
> 
>> Apart from that, I don't really see the advantage in moving away from
>> itertools.
> 
> 
> 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).  The basic idea being that it's nice to 
> place the methods associated with a type in that type's definiton.  The 
> parallel's a little weaker here because calling iter doesn't always 
> produce objects of type iter:
> 
> py> class C(object):
> ...     def __iter__(self):
> ...         yield 1
> ...
> py> iter(C())
> <generator object at 0x011805A8>
> 
> But note that iter does produce 'iterator' objects for the old 
> __getitem__ protocol:
> 
> py> class C(object):
> ...     def __getitem__(self, index):
> ...         if index > 5:
> ...             raise IndexError
> ...         return index
> ...
> py> iter(C())
> <iterator object at 0x01162EF0>
> 
> I guess the real questions are[1]:
> * How much does iter feel like a type?
> * How closely are the itertools functions associated with iter?
> 
> STeVe
> 
> [1] There's also the question of how much you believe in OO tenets like 
> "functions closely associated with a type should be members of that 
> type"...
While we're on the topic, what do you think of having unary, non-summary 
builtins automatically map themselves when called with an iterable that would 
otherwise be an illegal argument:

e.g.,
int(iterable) -> (int(i) for i in iterable)
ord(iterable) -> (ord(i) for i in iterable)


This would be unambiguous, I think, in the cases of bool, int, callable, chr, 
float, hex, id, long, oct, ord, vars...

It would shorten the common cases of:
for char in somestring:
     ordchar =  ord(char)
     # do something with ordchar, but not char
to
for ordchar in ord(somestring):
     ...

It would not work for summarizing functions or those that can accept an iterable 
today e.g., len, repr

Michael