<div dir="ltr">On Thu, Oct 16, 2008 at 8:27 PM, Terry Reedy <span dir="ltr"><<a href="mailto:tjreedy@udel.edu">tjreedy@udel.edu</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 class="Ih2E3d">George Sakkis wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
        I think we've done as much as I am comfortable with doing *by<br>
        default*<br>
        (i.e. when inheriting from object). The rest should be provided via<br>
        mix-ins. But even those mix-ins should wait until 3.1.<br>
<br>
<br>
    After posting and then thinking some more, I came to the same<br>
    conclusion, that anything more should be by explicit request.  <br>
<br>
Can you expand on how you reached this conclusion ?<br>
</blockquote>
<br></div>
Some related reasons/feelings:<br>
<br>
3.0 perhaps completes a major revision of comparisons from default
compare to default not compare and from __cmp__ based to 6 __xx__s
based.  But I suspect the full ramifications of this are yet to be
seen.  And there may or may not be refinements yet to me made.  (Greg's
point also.)<br>
<br>
I am not yet convinced that anything more automatic would be completely safe.</blockquote><div><br>Neither is the current behavior, and I haven't seen a use case where the proposal makes things less safe than they already are.<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;">
It seems like possibly one bit of magic too much.</blockquote><div><br>Having total ordering just work by default is too magic ?<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;">

If there are multiple sensible magics, better to let the programmer import and choose.<br>
<br>
It is hard to take things away once built in.</blockquote><div><br>That's
what I take from the whole skepticism, and there's nothing wrong to
becoming more conservative as the language matures. Still It's rather
ironic that the main motivation of introducing rich comparisons in the first
place was to support Numpy, a 3rd party package which most users will
never need, while there is resistance to a feature that will benefit
the majority.<br><br>Let's focus then on putting out an explicit
approach first (for 2.7 and 3.1) and make it automatic later if there
are no side effects. My prediction is that this will follow a path
similar to class decorators, which also didn't make it initially for 2.4 but
were added eventually (yay!).<br><br>George<br></div></div></div>