[Python-Dev] Re: PEP 326 now online

[Terry Reedy]

"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