> From: Greg Ewing [mailto:greg@cosc.canterbury.ac.nz]
>
> pinard@iro.umontreal.ca (=?iso-8859-1?q?Fran=E7ois?= Pinard):
>
> > The advantage is that the `.sorted()' method fits well within how
> > Python has evolved recently, offering more concise and legible
> > writings for frequent idioms.
>
> To support specialised non-in-place sorting algorithms,
> it could check whether its argument has a sorted()
> method, and if not, fall back on the general implementation.
Hmm - this actually suggests a couple more magic methods:
__sort__
__isort__
corresponding to "sort a copy" and "sort in-place".
Defining the rules for how these would be called requires a bit more thought
however. Do you want a sort() function to prefer __sort__ or __isort__?
def sort (seq, in_place=1):
if in_place:
return seq.__isort__()
try:
return seq.__sort__()
except:
pass
seq = list(seq)
seq.sort()
return seq
So - if an in-place sort is specified, try to do one, throwing an exception
if it's not possible. Otherwise sort a copy.
This would allow a generic mechanism for objects to ort copies of
themselves, rather than blindly changing them to a list.
Would two methods be better for in-place and copy sort?
Tim Delaney
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