[Python-ideas] Smallest/Largest singletons

[Josiah Carlson]

On Thu, Nov 13, 2008 at 11:25 PM, Scott Dial
<scott+python-ideas at scottdial.com> wrote:
> George Sakkis wrote:
>> One small side-effect of not being able to compare incompatible types in
>> 3.0 is that None cannot be used any more as the smallest element. Yes
>> this has always been an implementation artifact and a hack, but it was
>> very convenient none the less. Is it maybe the right time to add a
>> builtin Smallest (and also Largest) object, i.e. two singletons so that
>> `Smallest < x` for every x: x is not Smallest and `Largest > x` for
>> every x: x is not Largest ? Although it's not hard to define them in
>> pure Python and one could object with "not every n-liner needs to be a
>> builtin", the main added value is that these will be endorsed as the
>> standard, otherwise we risk mymodule.Smallest clashing with with
>> yourmodule.Smallest.
>>
>
> You can more-or-less take all of the replies to the thread about a
> blessed "__missing__" object and apply them to "Smallest"/"Largest".
> Using special objects to be lazy with your algorithm will never be wise.
> Eventually, someone will use them to mean something else entirely. It's
> almost always better to avoid using special objects or to roll-your-own
> (so that nobody can use it unexpectedly). Furthermore, preloading an
> output value with a nonsense value like "Smallest" or "Largest" is just
> asking for it to get leaked accidentally (the same problem exists with
> preloading None).
>
> -1 Let's not provide features for misguided programming idioms.

See PEP 326.  Unless additional motivations are presented, I'm going
to have to be -1 as well (despite 326 being my PEP).

 - Josiah