Yup, I was completely wrong.

If your classes were defined in pure-Python, this would raise an exception
(since the pure-Python operators/functions check for bad types, correct me
if I'm wrong). However, if you defined your compares at the C API level,
you could get a segfault. There are much easier ways to get segfaults using
the C API, however :)

Overall, I feel like if you're mutating the objects while they're being
sorted, you should be prepared for undefined behavior. Specifically, in the
current implementation, the sort result can be incorrect if you mutate as
you sort; no sort algorithm will recheck comparisons periodically to see if
you've tried to fool it.

Anyway, here's what Tim Peters said on the Github PR comments, where I
asked about the issue you raised:

> About the __class__-changing example, I don't care provided it doesn't >
blow up. But someone else should weigh in on that. I hope we can get, >
e.g., Raymond Hettinger to stare at this issue too.

Either way, great catch! Thanks for the feedback.

On Fri, Mar 10, 2017 at 6:15 PM ppperry <report@bugs.python.org> wrote:

>
> ppperry added the comment:
>
> >
> > Elliot Gorokhovsky added the comment:
> >
> > Your code changes __class__, not type, which would remain equal to
> > "instance". (my understanding, could be wrong). The docs say the
> > following:
> >
> Nope:
>     class A:pass
>     class B:pass
>     a = A()
>     a.__class__ = B
>     type(a)
> returns "<class '__main__.B'>"
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue28685>
> _______________________________________
>