"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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4