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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4