"Raymond" == Raymond Hettinger <[EMAIL PROTECTED]> 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"...
--
http://mail.python.org/mailman/listinfo/python-list
