Guido rethinking removal of cmp from sort method

[Raymond Hettinger]

On Mar 26, 4:39 am, Mark Dickinson <dicki... at gmail.com> wrote:
> On Mar 25, 2:00 pm, Stefan Behnel <stefan... at behnel.de> wrote:
>
>
>
>
>
>
>
>
>
> > Westley Martínez, 25.03.2011 14:39:
>
> > > On Fri, 2011-03-25 at 07:11 +0100, Stefan Behnel wrote:
> > >> Steven D'Aprano, 25.03.2011 06:46:
> > >>> On Thu, 24 Mar 2011 18:32:11 -0700, Carl Banks wrote:
>
> > >>>> It's probably the least justified builtin other than pow.
>
> > >>> I don't know about that. Correctly, efficiently and *quickly*
> > >>> implementing the three-argument version of pow is exactly the sort of
> > >>> thing that should be in the built-ins, or at least the standard library.
>
> > >> I think that touches it already. We have a "math" module, so why is there a
> > >> *builtin* for doing special math? How much code is there really that only
> > >> uses pow() and does not import "math"?
>
> > > pow() and math.pow() are different.
>
> > I don't find that a good excuse for pow() being a builtin. Why not just
> > rename it to "math.powmod" instead?
>
> +1 (modulo bikeshedding about the name).  I've long thought that three-
> argument pow belongs in the standard library rather than the core.
> And then the existence of the ** operator obviates the need for two-
> argument pow.

IMO, there is far too much willingness to churn long-standing APIs for
nearly zero benefit.  In my decade as a core Python developer, I've
come view deprecations as things that cause unnecessary pain for users
and is partially to blame for so many organizations staying with
older, unmaintained versions of Python.

When it comes to moving pow() to another module or changing the
signature for the __pow__ magic method, there's not much of a win to
be had, but it will affect tons of existing code (including examples
in printed books where pow() is commonly used in examples).

I think we (as a group) need to develop a strong aversion to breaking
existing APIs and instead focus on making existing APIs more robust or
giving them useful extensions.

The Python language is not like a personal library where changing APIs
has limited (and predictable costs).

Raymond