[Python-Dev] Re: PEP 326 now online (original) (raw)

Terry Reedy tjreedy at udel.edu
Tue Jan 6 12:50:13 EST 2004

"Andrew P. Lentvorski, Jr." <bsder at allcaps.org> wrote in message news:20040106044418.E59742 at mail.allcaps.org...

On Mon, 5 Jan 2004, Raymond Hettinger wrote:

> +1 It would occasionally be useful to have ready access to an object > whose sole purpose is to compare higher or lower than everything else.

I am to far from being a Python newbie to know whether such would expect such a t thing or find is surprising or even puzzling.

> Robert Brewer's idea to use spelled-out names, cmp.high and cmp.low, is > easy to remember, better for non-native English speakers, and reasonably > compact.

What about cmp.Max and cmp.Min? Non-native English speakers already have to know max() and min() and what they do, this might be easier to understand.

I proposed cmp.lo and cmp.hi as a trial balloon for the idea of using specific public function attributes (as opposed to generic implementation attributes) as a 'low-cost' alternative to builtin names for something that is useful but not so central as None, True, and False. I had no thought then of non-native-English users or much attachment to the specifics except for the shortness. Capitalizing the constants' names would follow precedence. Using Min and Max reuses existing knowledge, so this would be OK by me.

However, it might make things a little more confusing for native English speakers.

?? I have no idea how.

As for use cases, this stuff often comes up in the multitude of spatial data structures used for range searching. Segment trees, R-trees, k-d trees, database keys, etc. would all make use of this. The issue is that a range can be open on one side and does not always have an initialized case.

The solutions I have seen are to either overload None as the extremum or use an arbitrary large magnitude number. Overloading None means that the builtins can't really be used without special case checks to work around the undefined (or "wrongly defined") ordering of None. These checks tend

to swamp the nice performance of builtins like max() and min().

Choosing a large magnitude number throws away the ability of Python to cope with arbitrarily large integers and introduces a potential source of overrun/underrun bugs.

More grist for the Motivation section. Thanks.

Terry J. Reedy

More information about the Python-Dev mailing list