On Saturday 18 October 2003 11:44 am, Mark Russell wrote: > On Sat, 2003-10-18 at 07:07, Brett C. wrote: > > I'm -1 as well. Lists do not need to grow a method for something that > > only replaces two lines of code that are not tricky in any form of the > > word. > > And don't forget that the trivial function will sort any iterable, not > just lists. I think > > for member in copysort(someset): > > is better than > > for member in list(someset).copysort(): > > I'm against list.copysort(), and for either leaving things unchanged or > adding copysort() as a builtin (especially if it can use the reference > count trick to avoid unnecessary copies). The trick would need to check that the argument is a list, of course, as well as checking that the reference to it on the stack is the only one around. But given this, yes, I guess a built-in would be "better" by occasionally saving the need to type a few extra characters (though maybe "worse" by enlarging the built-in module rather than remaining inside the smaller namespace of the list type...?). The built-in, or method, 'copysort', would have to accept the same optional arguments as the sort method of lists has just grown, of course. Alex
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