Incomparable abominations (was: python-dev Summary)

[John Roth]

"Jeremy Fincher" <tweedgeezer at hotmail.com> wrote in message
news:698f09f8.0303202158.511534e8 at posting.google.com...
> "John Roth" <johnroth at ameritech.net> wrote in message
news:<v7krnnm82qdi98 at news.supernews.com>...
> > "Jeremy Fincher" <tweedgeezer at hotmail.com> wrote in message
> > news:698f09f8.0303201041.6b69619d at posting.google.com...
> > > If something like this was added, so there was a total ordering on
> > > Python objects during sorts, I'd be completely happy with the
> > > comparison operators </>/<=/>= being changed to only work between
> > > consistent types.  In fact, I'd prefer it that way.
> > >
> > > Of course, == and != would still work between inconsistent types.
> >
> > I think that's probably the way is *should* have been from the
> > beginning. However, I'd be against changing it at this point; it
would
> > break programs. Save the change for Python 3000.
>
> If the sort() method on lists was changed to use this total ordering
> on Python objects (using before()), then changing the relational
> operators to raise exceptions on type-invalid code wouldn't break any
> of *my* code, so I'd be fine with the change :)
>
> (And what code it did break, mine or not, would almost certainly be
> either a bug or a place that would need to use before() instead of <;
> I can't imagine the latter case occuring all that often.)

But that's not the issue. Suggested changes to Python won't happen
if there's any likelihood of breaking people's code. Incompatible
changes need a lot of justification and quite a bit of work to show
that the error cases are unlikely. Assertions don't do it; actual
surveys
of working code are needed.

Even then it would have to be transitioned in over several releases,
with warning messages for illegal usage.

John Roth

>
> Jeremy