On 11/14/06, George Sakkis <[EMAIL PROTECTED]> wrote: > 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?"
I came to Python from Java and originally thought this. The answer I received was as I described: methods are for a certain class hierarchy, while functions are for an unknown number of potential types that exhibit a certain behavior. So you can call len() on both lists and strings. Here Java has an inconsistency: array.length vs String.length(). This in itself illustrates my point. Different types necessarily have different implementations. But if the left hand isn't watching closely what the right hand is doing, you end up with cross-class inconsistencies and incompatibilities. len() here is a unifier: it says "thou shalt do this, .__len__ method, or users will be pissed that len() doesn't work on your type". Python made mistakes along the way in terms of method/function distribution, but these are gradually being corrected. The most notorious were string functions. Who wants to call string.find(s, sub) or string.split(s)? But these have long been replaced by methods. My work on a Path object is along the same lines. The #1 complaint I hear about Python from non-users is indentation, not too many functions. People generally praise Python's clean method interface in its file objects, list/str/dict objects, and its stdlib namespaces. These aren't perfect but they're better than many languages. I was very pleased that typecasting in Python is as straightforward as int() and str(), and calling a function instantiates it. Much more straightforward than " Foo x = new Foo()". > I am totally > amazed that I have itertools in higher esteem than many/most core > Python developers. I esteem itertools, I just don't have much need for those operations. I'm glad it's there because it has better (less memory intensive) implementations than I'd likely make on my own, and it shows ways to use iterators that I'd never considered. > > 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. That's a good point, the overhead of adding a method is not really worse than adding a function. I wouldn't object to an iter() function that returns a SuperIterator, able to slice tall iterables in a single bound, er, cut. But I'm not a core developer so I don't understand all the ramifications it might have. That's a point worth pressing though: what's the harm in having iter() return an object that's "sma-a-a-rter than your average bear!", er, than your average iterator. > 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. Actually, it's easier to add a method or package function than to add a builtin. Every additional builtin makes it harder to keep all the builtins in your head, and runs the risk of colliding with a variable in existing code. And as Cheetah discovered, it's not safe to autogenerate Python code based on what the builtins are, because a future version of Python will add ones you can't predict. enumerate() and zip() were added because they solve extremely widespread problems. I can't say I like sorted() and reversed(), but they're there because somebody thought they'd be very widely used. -- Mike Orr <[EMAIL PROTECTED]> _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
