[Python-Dev] Re: PEP 326 now online (original) (raw)
Guido van Rossum guido at python.org
Wed Jan 7 10:01:35 EST 2004
- Previous message: [Python-Dev] Re: PEP 326 now online
- Next message: [Python-Dev] Re: PEP 326 now online
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> 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/)
- Previous message: [Python-Dev] Re: PEP 326 now online
- Next message: [Python-Dev] Re: PEP 326 now online
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]