Question about consistency in python language

[Kay Schluehr]

Terry Reedy wrote:
> "Kay Schluehr" <kay.schluehr at gmx.net> wrote in message
> news:1126247836.678936.233170 at o13g2000cwo.googlegroups.com...
> > 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