[Python-Dev] decorate-sort-undecorate
Ian Bicking
ianb at colorstudy.com
Wed Oct 15 15:48:04 EDT 2003
More information about the Python-Dev mailing list
Wed Oct 15 15:48:04 EDT 2003
- Previous message: [Python-Dev] decorate-sort-undecorate
- Next message: [Python-Dev] decorate-sort-undecorate
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Wednesday, October 15, 2003, at 12:35 PM, Barry Warsaw wrote: > While we're hacking on [].sort(), how horrible would it be if we > modified it to return self instead of None? I don't mind the > sort-in-place behavior, but it's just so inconvenient that it doesn't > return anything useful. I know it would be better if it returned a new > list, but practicality beats purity. <wink> When doing DSU sorting, the in-place sorting isn't really a performance win, is it? You already have to allocate and populate an entire alternate list with the sort keys, though I suppose you could have those mini key structs point to the original list. Anyway, while it's obviously in bad taste to propose .sort change its return value based on the presence of a key, wouldn't it be good if we had access to the new sorted list, instead of always clobbering the original list? Otherwise people's sorted() functions will end up copying lists unnecessarily. Okay, really I'm just hoping for [x for x in l sortby key(x)], if not now then someday -- if only there was a decent way of expressing that without a keyword... [...in l : key(x)] is the only thing I can think of that would be syntactically possible (without introducing a new keyword, new punctuation, or reusing a wholely inappropriate existing keyword). Or ";" instead of ":", but neither is very good. Sigh... -- Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org
- Previous message: [Python-Dev] decorate-sort-undecorate
- Next message: [Python-Dev] decorate-sort-undecorate
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list