On Sun, Nov 16, 2008 at 5:33 PM, Josiah Carlson <span dir="ltr"><<a href="mailto:josiah.carlson@gmail.com">josiah.carlson@gmail.com</a>></span> wrote:<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="Wj3C7c">On Thu, Nov 13, 2008 at 11:25 PM, Scott Dial<br>
<<a href="mailto:scott%2Bpython-ideas@scottdial.com">scott+python-ideas@scottdial.com</a>> wrote:<br>
> George Sakkis wrote:<br>
>> One small side-effect of not being able to compare incompatible types in<br>
>> 3.0 is that None cannot be used any more as the smallest element. Yes<br>
>> this has always been an implementation artifact and a hack, but it was<br>
>> very convenient none the less. Is it maybe the right time to add a<br>
>> builtin Smallest (and also Largest) object, i.e. two singletons so that<br>
>> `Smallest < x` for every x: x is not Smallest and `Largest > x` for<br>
>> every x: x is not Largest ? Although it's not hard to define them in<br>
>> pure Python and one could object with "not every n-liner needs to be a<br>
>> builtin", the main added value is that these will be endorsed as the<br>
>> standard, otherwise we risk mymodule.Smallest clashing with with<br>
>> yourmodule.Smallest.<br>
>><br>
><br>
> You can more-or-less take all of the replies to the thread about a<br>
> blessed "__missing__" object and apply them to "Smallest"/"Largest".<br>
> Using special objects to be lazy with your algorithm will never be wise.</div></div></blockquote><div class="Wj3C7c"><br>s/lazy/elegant<br><br>
> Eventually, someone will use them to mean something else entirely. It's<br>
> almost always better to avoid using special objects or to roll-your-own<br>
> (so that nobody can use it unexpectedly). Furthermore, preloading an<br>
> output value with a nonsense value like "Smallest" or "Largest" is just<br>
> asking for it to get leaked accidentally (the same problem exists with<br>
> preloading None).<br>
><br>
> -1 Let's not provide features for misguided programming idioms.</div><div><br>I don't consider Dijkstra's shortest path algorithm and the others mentioned in PEP 326 as examples of misguided programming idioms.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">See PEP 326.  Unless additional motivations are presented, I'm going<br>
to have to be -1 as well (despite 326 being my PEP).</blockquote><div><br>The additional motivation since the PEP is that the None hack (as equivalent to Smallest) cannot be used anymore in 3.x, and I'm sure I'm not the only one using it. Besides, the reasons for rejection read more like a lukewarm -0 ("not that useful, easily implemented, can't decide on a name"), not a strong "this is silly" -1.<br>
<br>George<br></div></div>