On Oct 29, 9:35 pm, Michael L Torrie <[EMAIL PROTECTED]> wrote: > brad wrote: > > Not complaining. len is simple and understandable and IMO fits nicely > > with split(), strip(), etc... that's why I used it as an example, but > > list(), etc. could be used as examples as well: > > > a_string.list() instead of list(a_string) > > This is a great example of why list() needs to be a singleton and *not* > a method of any particular class.
The whole discussion about list() is moot since it's not a function anyway, it's a type. As long as a list knows hows to initialize itself given any iterable, it would be useless to require it as a method to the iterables as well (unless perhaps there are significant performance improvements when one can create a list much faster than iterating through it). > Saying list() should be a method only of something iterable is not only > foolish, but wasteful. Why should I burden every iterable object with > redundant code? Does the same argument apply for len() ? Nope, you still have to define __len__. Having a builtin len() that calls the method __len__ seems (using your words) "not only foolish but wasteful". > In short, making list() a method is wrong-thinking. Reminds me of java. > Ugg. Agreed, but you're beating a dead horse with list(). > If find Python to be more OO through and through than Java. Once you > understand that functions are objects, and duck-typing, things like > len() being a function rather than a method make perfect sense. Does the fact that index() or split() are methods make perfect sense as well? I guess after some time using Python it does, but for most unbiased users the distinction seems arbitrary. George -- http://mail.python.org/mailman/listinfo/python-list