Terry Reedy wrote: > "Kay Schluehr" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > On the other hand there exists no sorted() method for tuples or lists > > like join() for strings but it is implemented as a function in Python24 > > that returns a new sorted container. I consider this as an > > inconsistency across builtin types. > > The sorted function is not a list method because it is not only a list > function or even only a tuple and list function or even only a string, > tuple, list, array, or dict function. Its input is **any** iterable. The > only way to have it both be general and a method would be to have an > iterable type and to require that all iterables inherit from that type to > reap the benefit of being an iterable. All the itertools functions are > also functions and not methods of a hypothetical iterable type. 'Iterable' > is a duck type and hence functions thereof must be functions and not > methods. > > Terry J. Reedy
So what? Then an iterable class providing the __iter__ method may be factored out as Mike reasonably suggested ( I was wrong with my remark about duck-typing. The __iter__ method may be the interface I claimed not being aware of ). Or a sortable trait gets used as I would slightly prefer - but it's not necassary. To be honest I'm not sure what all the BDFLs Javaesque interfaces and optional static typing blabla for Py3K should matter if it's not even possible to create obvious inheritance hierarchies in favour for accidental generic functions? Kay -- http://mail.python.org/mailman/listinfo/python-list