[Python-Dev] Re: PEP 326 now online

[Guido van Rossum]

> > Not to me.  Random reuses like this would make Python into a
> > mysterious language.
> 
> The reuse isn't random.  It would be random if int compared smaller than
> everything and float compared larger than everything, or even if the
> strings "little" and "big" did the same.
> 
> 
> Using min and max to be the smallest and largest objects, as well as
> being functions that can be called to find the smallest or largest value
> in a sequence, seems to be intuitive.  But lets get past that for a
> moment.

If that's "intuitive" to you, our ideas about language design must be
so different that I have low hopes for something useful coming out of
this.

> Let us just pretend, for sake of argument, that min and max were to
> become the smallest and largest values.  The only place this would
> effect pre-existing code is if someone were ordering functions based on
> '<' or '>' comparisons, IE: they would have to be sorting functions,
> specifically, min and max.

That is *not* the point at all.

The point is that using min() and max() as functions is several orders
of magnitude more common than using an infinity value.  Most people
quickly forget features or details they don't need.  So it is likely
that many Python users would only be familiar with the function usage,
and if they say code that passed max in the meaning of infinity,
they'd scratch their head and wonder whether it was used as a
callback, or whether there was a local variable max, or whether it was
simply a bug.

> If it is desireable to warn programmers who have been doing this, it
> would be relatively easy to produce a warning when this happens (to warn
> those that had been previously sorting functions).  Making the warning
> removable by using a __future__ import for those of us who know about
> this behavior:
> from __future__ import minmax
> And subsequently removing the warnings in later Python versions.
> 
> 
> > Not from me -- don't waste your time.
> 
> Are you against the *idea* of a top and bottom value, its location, or
> both?

So far *all* of the names that have been proposed for the concept
suck, starting with "Some" and "Any", and now various ways to abuse
builtins.

I am not against the concept of a universal extreme by itself, but
IMO their use is fairly infrequent (except in your mind perhaps,
because you've clearly become obsessed with it), so it should not be a
builtin, nor disguised as a builtin.

How about you write the Python code to implement proper universal
extremes, put it in a module, and submit that module for inclusion
of the standard library.  Then my resistence would be a lot less
(until Raymond Hettinger offers to reimplement it in C :-).

Hey, universalextremes.py seems a fine name for that module, and
UniversalMaximum and UniversalMinimum seem fine names for the two
objects in that module.  If you find those names too long, you can
always write

  from universalextremes import UnivsersalMaximum as UMax

--Guido van Rossum (home page: http://www.python.org/~guido/)