Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #2422

Re: Guido rethinking removal of cmp from sort method

Show key headers only | View raw

On Fri, Apr 1, 2011 at 5:41 PM, Steven D'Aprano
<steve+comp.lang.python@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@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

Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: Guido rethinking removal of cmp from sort method Antoon Pardon <Antoon.Pardon@rece.vub.ac.be> - 2011-03-30 11:06 +0200
  Re: Guido rethinking removal of cmp from sort method Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-03-31 02:13 +0000
    Re: Guido rethinking removal of cmp from sort method Antoon Pardon <Antoon.Pardon@rece.vub.ac.be> - 2011-03-31 11:41 +0200
      Re: Guido rethinking removal of cmp from sort method Paul Rubin <no.email@nospam.invalid> - 2011-03-31 04:59 -0700
    Re: Guido rethinking removal of cmp from sort method geremy condra <debatem1@gmail.com> - 2011-04-01 14:31 -0700
      Re: Guido rethinking removal of cmp from sort method Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-04-02 00:41 +0000
        Re: Guido rethinking removal of cmp from sort method geremy condra <debatem1@gmail.com> - 2011-04-01 18:22 -0700
          Re: Guido rethinking removal of cmp from sort method Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-04-02 11:01 +0000
            Re: Guido rethinking removal of cmp from sort method geremy condra <debatem1@gmail.com> - 2011-04-02 23:22 -0700
            Re: Guido rethinking removal of cmp from sort method Brian Quinlan <brian@sweetapp.com> - 2011-04-03 16:34 +1000
              Re: Guido rethinking removal of cmp from sort method Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-04-03 10:21 +0000
                Re: Guido rethinking removal of cmp from sort method geremy condra <debatem1@gmail.com> - 2011-04-03 12:58 -0700
        Re: Guido rethinking removal of cmp from sort method Paul Rubin <no.email@nospam.invalid> - 2011-04-01 19:29 -0700
          Re: Guido rethinking removal of cmp from sort method Chris Angelico <rosuav@gmail.com> - 2011-04-02 13:43 +1100
          Re: Guido rethinking removal of cmp from sort method Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-04-02 11:27 +0000

csiph-web