[Python-Dev] Re: Re: PEP 326 now online

[Terry Reedy]

"Guido van Rossum" <guido at python.org> wrote in various messages

(I wrote)
> > 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. ....  Using
> > Min and Max reuses existing knowledge, so this would be OK by me.
>
> Hm.  cmp is a *builtin function*.

I know ;-)  Which means that it is immediately available without an import.

>  That seems an exceedingly odd place  to stick arbitrary constants

Yes, this is an 'innovative' suggestion in that regard (hence 'trial
balloon').
Cmp does, of course, already have the standard default set of special
attributes and methods, so giving it two public attributes is not
completely odd.

My position:
Extreme values are useful/needed for certain types of algorithms.
By current standards, they are not generally useful enough to go in
builtins.
They *are* plausibly useful enough to be included in the standard language
if such can be done unobstrusively.
Doing so will aid writing and teaching the algorithms that need them.

If one accepts point three, at least hypothetically, the question is where
to 'unobtrusively' put them.  After considering other possibilities, I came
up with the cmp suggestion, which seems easy enough both to document and
remember.

>  -- much more so than type objects

some of which are now callable factories, which as deterministic mappings
are functions in the mathematical sense.  In an alternate universe in which
entry to builtins was even more restricted, True and False might have been
introduced as bool.True and bool.False.  And 'cmp' might be a callable int
subtype, like bool is now, returning Less, Equal, More == -1, 0 1.

> make[ing] them attributes of object has the unfortunate side effect
> that they will be attributes of *all* objects and that doesn't seem a
good idea.

While I considered and mentioned this possibility, I rejected it and looked
further for precisely that reason.

> Module attributes make sense

The negatives being the need to import (minor) and the need to pick one
(but which?)

>The math module is only appropriate if this is primarily about float
numbers.

Which is why I keep looking.  The extreme values should work with anything
except a user class which defines competing extremes.

>Why two subclasses?  Shouldn't one with two instances suffice?

Definitely, and that is my proposal.  Or, if a new class were not desired,
perhaps even two new instances of NoneType if that would work and not break
anything.  I considered the specific implementation unimportant as long as
it is unobtrusive.

Terry J. Reedy