Guido rethinking removal of cmp from sort method

[geremy condra]

On Fri, Apr 1, 2011 at 5:41 PM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> On Fri, 01 Apr 2011 14:31:09 -0700, geremy condra wrote:
>
>> On Wed, Mar 30, 2011 at 7:13 PM, Steven D'Aprano
>> <steve+comp.lang.python at pearwood.info> wrote:
>>
>> <snip>
>>
>>> Or, an alternative approach would be for one of the cmp-supporters to
>>> take the code for Python's sort routine, and implement your own
>>> sort-with- cmp (in C, of course, a pure Python solution will likely be
>>> unusable) and offer it as a download. For anyone who knows how to do C
>>> extensions, this shouldn't be hard: just grab the code in Python 2.7
>>> and make it a stand- alone function that can be imported.
>>>
>>> If you get lots of community interest in this, that is a good sign that
>>> the solution is useful and practical, and then you can push to have it
>>> included in the standard library or even as a built-in.
>>>
>>> And if not, well, at least you will be able to continue using cmp in
>>> your own code.
>>
>> I don't have a horse in this race, but I do wonder how much of Python
>> could actually survive this test. My first (uneducated) guess is "not
>> very much"- we would almost certainly lose large pieces of the string
>> API and other builtins, and I have no doubt at all that a really
>> significant chunk of the standard library would vanish as well. In fact,
>> looking at the data I took from PyPI a while back, it's pretty clear
>> that Python's feature set would look very different overall if we
>> applied this test to everything.
>
>
> I don't understand what you mean by "this test".

I mean testing whether a feature should be in Python based on whether
it can meet some undefined standard of popularity if implemented as a
third-party module or extension.

> I'm certainly not suggesting that we strip every built-in of all methods
> and make everything a third-party C extension. That would be insane.

Granted, but I think the implication is clear: that only those
features which could be successful if implemented and distributed by a
third party should be in Python. My argument is that there are many
features currently in Python that I doubt would pass that test, but
which should probably be in anyway. The conclusion I draw from that is
that this isn't a particularly good way to determine whether something
should be in standard Python.

> Nor do I mean that every feature in the standard library should be forced
> to prove itself or be removed. The features removed from Python 3 were
> deliberately few and conservative, and it was a one-off change (at least
> until Python 4000 in the indefinite future). If something is in Python 3
> *now*, you can assume that it won't be removed any time soon.

I may have been unclear, so let me reiterate: I'm not under the
impression that you're advocating this as a course of action. I'm just
pointing out that the standard for inclusion you're advocating is
probably not a particularly good one, especially in this case, and
engaging in a bit of a thought experiment about what would happen if
other parts of Python were similarly scrutinized.

> What I'm saying is this: cmp is already removed from sorting, and we
> can't change the past. Regardless of whether this was a mistake or not,
> the fact is that it is gone, and therefore re-adding it is a new feature
> request. Those who want cmp functionality in Python 3 have three broad
> choices:

I might quibble over whether re-adding is the same as a new feature
request, but as I said- I don't care about cmp.

> (1) suck it up and give up the fight; the battle is lost, move on;
>
> (2) keep arguing until they either wear down the Python developers or get
> kill-filed; never give up, never surrender;
>
> (3) port the feature that they want into a third-party module, so that
> they can actually use it in code, and then when they have evidence that
> the community needs and/or wants this feature, then try to have it re-
> added to the language.
>
> I'm suggesting that #3 is a more practical, useful approach than writing
> another hundred thousand words complaining about what a terrible mistake
> it was. Having to do:
>
> from sorting import csort
>
> as a prerequisite for using a comparison function is not an onerous
> requirement for developers. If fans of functional programming can live
> with "from functools import reduce", fans of cmp can live with that.

And that's fine, as I said I don't have a horse in this race. My point
is just that I don't think the standard you're using is a good one-
ISTM that if it *had* been applied evenly we would have wound up with
a much less complete (and much less awesome) Python than we have
today. That indicates that there are a reasonable number of real-world
cases where it hasn't and shouldn't apply.

Geremy Condra