On 11/14/06, Greg Ewing <[EMAIL PROTECTED]> wrote: > George Sakkis wrote: > > > I think I do, though I can't tell the same about the reasons of your > > objections to it. > > Perhaps I can fill in some of the things that Guido > is not explicitly saying.
Indeed, another high quality reply. Thanks for sharing. > You've shown that it *can* be done, but you haven't > provided a compelling reason why it *should* be done. > > The main benefit seems to be that itertools operations > could then be done using method calls instead of > function calls. But that's not automatically better > than what we have now. Python does not follow the > "everything must be a method of something" ideology > found in some other languages such as Java and Ruby. I won't open another can of worms here, but I'll just say that as much as I hate Java's stubborn insistence on OO purity, I am equally disturbed by Python's arbitrary-looking choices on whether some callable ends up a function or a method. When I talk about or introduce Python to outsiders, one of the toughest questions is often something along the lines of "why len() is a function and not a method?" > The itertools functions have generic implementations > that work with any iterator. They don't need access > to the iterator's internals, or need to be dynamically > dispatched for any reason, so there is no obvious > benefit to making them methods instead of stand-alone > functions. Did you look at my implementation ? The only attribute is a reference to the underlying iterator. No access to its internal is needed. > The one technical benefit appears to be the ability > to use operators instead of named functions. But > considering how infrequently itertools operations > are used, having to spell them out doesn't seem > like a great hardship, so this argument is weak. > All other things being equal, it might hold sway, > but other things are not equal. This seems to be the most central, and at the same time most unexpected for me, point of resistance. Given the prominence of iterators, generators, generator comprehensions and generic iterables in Python, I've been considering itertools the module that makes all these "talk" to each other seamlessly and transparently. I am totally amazed that I have itertools in higher esteem than many/most core Python developers. > You claim that duck typing would not be inhibited. > While technically this is true, in practice it would > mean that any iterator that didn't inherit from this > base class would be a second-class citizen, unable > to be used by code that expected it to have all the > "standard" itertools methods. The promotion from second class to first would require 6 extra characters: Iter(x) (or iter(x) if it's ok to augment the existing iter()). Just spelling "itertools" takes more than that, let alone importing a function or two. The runtime cost would be negligible too since Iter is a thinnest wrapper around x (or it could be x itself if it was already "first-class"). > Finally, consider that there are infinitely many > possible functions of the kind that are found in > the itertools module. As stand-alone functions, > they all have equal status -- new ones can be added > and used in the same way by any code on any > iterator. Some good arguments would have to be > put forward as to why some particular ones should > be picked out and elevated to the status of methods. I'm not sure I understand your point here. If something was deemed useful enough to make it to itertools, it would be a candidate for being a method to a base Iter type. I don't have any strong feelings on the exact set of methods that I want to see included apart from the most basic ones (chain as +, islice as [], izip as zip and enumerate - yes, I count enumerate as an iter tool). Besides, types, like modules, are not carved in stone. It's not as if no builtin type or function in Python has ever grown (in a backwards compatible way) more methods, extra named arguments, etc. I guess the good arguments to be put forward for every candidate method would be similar to the ones that elevated enumerate() and reversed() to builtin status. George _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
