(I apologize if this sent twice, my outbox is acting screwy). With regard to point 1: I think that changing the return type of sorted() would cause nasty surprises. If you can no longer assume that calling sorted() on any arbitrary container is going to return an indexed list, then we've lost all the advantages of Python's "duck typing." With regard to point 2: How would this interact with the existing signature of the sorted() function? The sorted() function, as it is right now, is responsible not just for the sort algorithm, but also for defining how comparisons should work. If the comparison keys are changed, then you can't assume any sorting operation is trivial anymore. Consider the following, using a range object:

...

...

import math sorted(range(10), key=math.sin) [5, 4, 6, 0, 3, 9, 7, 1, 2, 8]

Matthew Lefavor From: David Townshend <aquavitae69@gmail.com<mailto:aquavitae69@gmail.com>> Date: Friday, July 20, 2012 12:11 PM To: "python-ideas@python.org<mailto:python-ideas@python.org>" <python-ideas@python.org<mailto:python-ideas@python.org>> Subject: [Python-ideas] __sort__ special member I was quite surprised to find that nobody seems to have suggested this before, because it seems like an obvious idea. Basically, add a special method __sort__ which, if specified, is used when sorted() is called. I can think of two immediate use cases: 1. When an object wants sorted() to return something other than a list, e.g. dict.__sort__ could return an OrderedDict. 2. When there is a more efficient method of sorting a specific sequence. E.g. sorting a range object should be trivial. Is there some obvious reason why nobody has suggested this before? Is it worth pursuing? David.

On Fri, Jul 20, 2012 at 11:23 AM, Oleg Broytman <phd@phdru.name> wrote:

On Fri, Jul 20, 2012 at 06:11:52PM +0200, David Townshend < aquavitae69@gmail.com> wrote:

...

I was quite surprised to find that nobody seems to have suggested this before, because it seems like an obvious idea. Basically, add a special method __sort__ which, if specified, is used when sorted() is called. I can think of two immediate use cases:

1. When an object wants sorted() to return something other than a list, e.g. dict.__sort__ could return an OrderedDict. 2. When there is a more efficient method of sorting a specific sequence. E.g. sorting a range object should be trivial.

Is there some obvious reason why nobody has suggested this before? Is it worth pursuing?

Because it's too application-specific?

What are you talking about. This would solve the issue of ordering for dicts that became contentious a few years ago. If people don't like the arbitrary ordering, they can subclass it.

mark

On Fri, Jul 20, 2012 at 11:44 AM, Mark Adam <dreamingforward@gmail.com>wrote:

On Fri, Jul 20, 2012 at 11:23 AM, Oleg Broytman <phd@phdru.name> wrote:

...

On Fri, Jul 20, 2012 at 06:11:52PM +0200, David Townshend < aquavitae69@gmail.com> wrote:

...

I was quite surprised to find that nobody seems to have suggested this before, because it seems like an obvious idea. Basically, add a special method __sort__ which, if specified, is used when sorted() is called. I can think of two immediate use cases:

1. When an object wants sorted() to return something other than a list, e.g. dict.__sort__ could return an OrderedDict. 2. When there is a more efficient method of sorting a specific sequence. E.g. sorting a range object should be trivial.

Is there some obvious reason why nobody has suggested this before? Is it worth pursuing?

Because it's too application-specific?

What are you talking about. This would solve the issue of ordering for dicts that became contentious a few years ago. If people don't like the arbitrary ordering, they can subclass it.

Sorry, I'll tone down my words. But this makes more sense than sort() as a built-in. In theory, sort is for collections, not just any object. So it could belong to an abstract collections base type. This would allow users to select lexical orderings, for example, rather than ASCII. It seems strange that no one thought of it before(it that true?).

mark

Because the decision of how sorting should occur is up to the consumer, not the provider. sorted() has the contract to produce a list, using an algorithm that makes a lot of guarantees about the results. If objects are allowed to override sorting completely, then those guarantees are no longer possible. -- Sent from my phone, thus the relative brevity :)

On Fri, Jul 20, 2012 at 2:29 PM, Mark Adam <dreamingforward@gmail.com> wrote:

Sorry, I'll tone down my words. But this makes more sense than sort() as a built-in. In theory, sort is for collections, not just any object. So it could belong to an abstract collections base type. This would allow users to select lexical orderings, for example, rather than ASCII. It seems strange that no one thought of it before(it that true?).

FWIW the sort method (as in list.sort()) is polymorphic, just nobody bothers implementing it. And how many interesting specializations are there? At best I can only think of linear-time sorts, but it's pretty rare you'll know your collection only contains discrete values. -- Devin

(I apologize if this sent twice, my outbox is acting screwy). With regard to point 1: I think that changing the return type of sorted() would cause nasty surprises. If you can no longer assume that calling sorted() on any arbitrary container is going to return an indexed list, then we've lost all the advantages of Python's "duck typing." With regard to point 2: How would this interact with the existing signature of the sorted() function? The sorted() function, as it is right now, is responsible not just for the sort algorithm, but also for defining how comparisons should work. If the comparison keys are changed, then you can't assume any sorting operation is trivial anymore. Consider the following, using a range object:

...

...

import math sorted(range(10), key=math.sin) [5, 4, 6, 0, 3, 9, 7, 1, 2, 8]

Matthew Lefavor From: David Townshend <aquavitae69@gmail.com<mailto:aquavitae69@gmail.com>> Date: Friday, July 20, 2012 12:11 PM To: "python-ideas@python.org<mailto:python-ideas@python.org>" <python-ideas@python.org<mailto:python-ideas@python.org>> Subject: [Python-ideas] __sort__ special member I was quite surprised to find that nobody seems to have suggested this before, because it seems like an obvious idea. Basically, add a special method __sort__ which, if specified, is used when sorted() is called. I can think of two immediate use cases: 1. When an object wants sorted() to return something other than a list, e.g. dict.__sort__ could return an OrderedDict. 2. When there is a more efficient method of sorting a specific sequence. E.g. sorting a range object should be trivial. Is there some obvious reason why nobody has suggested this before? Is it worth pursuing? David.

On Fri, Jul 20, 2012 at 11:23 AM, Oleg Broytman <phd@phdru.name> wrote:

On Fri, Jul 20, 2012 at 06:11:52PM +0200, David Townshend < aquavitae69@gmail.com> wrote:

...

I was quite surprised to find that nobody seems to have suggested this before, because it seems like an obvious idea. Basically, add a special method __sort__ which, if specified, is used when sorted() is called. I can think of two immediate use cases:

1. When an object wants sorted() to return something other than a list, e.g. dict.__sort__ could return an OrderedDict. 2. When there is a more efficient method of sorting a specific sequence. E.g. sorting a range object should be trivial.

Is there some obvious reason why nobody has suggested this before? Is it worth pursuing?

Because it's too application-specific?

What are you talking about. This would solve the issue of ordering for dicts that became contentious a few years ago. If people don't like the arbitrary ordering, they can subclass it.

mark

On Fri, Jul 20, 2012 at 11:44 AM, Mark Adam <dreamingforward@gmail.com>wrote:

On Fri, Jul 20, 2012 at 11:23 AM, Oleg Broytman <phd@phdru.name> wrote:

...

On Fri, Jul 20, 2012 at 06:11:52PM +0200, David Townshend < aquavitae69@gmail.com> wrote:

...

I was quite surprised to find that nobody seems to have suggested this before, because it seems like an obvious idea. Basically, add a special method __sort__ which, if specified, is used when sorted() is called. I can think of two immediate use cases:

1. When an object wants sorted() to return something other than a list, e.g. dict.__sort__ could return an OrderedDict. 2. When there is a more efficient method of sorting a specific sequence. E.g. sorting a range object should be trivial.

Is there some obvious reason why nobody has suggested this before? Is it worth pursuing?

Because it's too application-specific?

What are you talking about. This would solve the issue of ordering for dicts that became contentious a few years ago. If people don't like the arbitrary ordering, they can subclass it.

Sorry, I'll tone down my words. But this makes more sense than sort() as a built-in. In theory, sort is for collections, not just any object. So it could belong to an abstract collections base type. This would allow users to select lexical orderings, for example, rather than ASCII. It seems strange that no one thought of it before(it that true?).

mark

Because the decision of how sorting should occur is up to the consumer, not the provider. sorted() has the contract to produce a list, using an algorithm that makes a lot of guarantees about the results. If objects are allowed to override sorting completely, then those guarantees are no longer possible. -- Sent from my phone, thus the relative brevity :)

On Fri, Jul 20, 2012 at 2:29 PM, Mark Adam <dreamingforward@gmail.com> wrote:

Sorry, I'll tone down my words. But this makes more sense than sort() as a built-in. In theory, sort is for collections, not just any object. So it could belong to an abstract collections base type. This would allow users to select lexical orderings, for example, rather than ASCII. It seems strange that no one thought of it before(it that true?).

FWIW the sort method (as in list.sort()) is polymorphic, just nobody bothers implementing it. And how many interesting specializations are there? At best I can only think of linear-time sorts, but it's pretty rare you'll know your collection only contains discrete values. -- Devin