This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author elliot.gorokhovsky
Recipients elliot.gorokhovsky, mdk, ppperry, serhiy.storchaka, tim.peters, vstinner
Date 2017-03-11.00:31:27
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
Your code changes __class__, not type, which would remain equal to
"instance". (my understanding, could be wrong). The docs say the following:
> Like its identity, an object’s type is also unchangeable. [1]
> [1] It is possible in some cases to change an object’s type, under
certain controlled conditions.
> It generally isn’t a good idea though, since it can lead to some very
strange behavior if it is
> handled incorrectly.

So I think it's safe to assume that type doesn't change; if you change
type, you get undefined ("very strange") behavior. Based on the comment in
the footnote, other code clearly assumes that type doesn't change, so I
don't see why list.sort() should be any different.

On Fri, Mar 10, 2017 at 5:08 PM ppperry <> wrote:

> ppperry added the comment:
> Does this work with wacky code like this?
>         @functools.total_ordering
>         class ClassAssignmentCanBreakChecks():
>                 def __init__(self, i):
>                         self._i = i
>                 def __lt__ (self, other):
>                         last.__class__ = OrdinaryOldInteger
>                         return self._i < (other._i if hasattr(other, '_i')
> else other)
>         @functools.total_ordering
>         class OrdinaryOldInteger:
>                 def __init__(self, i):
>                         self._i = i
>                 def __lt__(self, other):
>                         return self._i < (other._i if hasattr(other, '_i')
> else other)
>         lst = [ClassAssignmentCanBreakChecks(i) for i in range(10)]
>         random.shuffle(lst)
>         last = lst[-1]
>         lst.sort()
> It looks like it will initially say that all are the same type, and
> attempt that optimization, which will probably lead to unexpected results
> as that condition is no longer true after the first compare.
> ----------
> nosy: +ppperry
> _______________________________________
> Python tracker <>
> <>
> _______________________________________
Date User Action Args
2017-03-11 00:31:27elliot.gorokhovskysetrecipients: + elliot.gorokhovsky, tim.peters, vstinner, serhiy.storchaka, ppperry, mdk
2017-03-11 00:31:27elliot.gorokhovskylinkissue28685 messages
2017-03-11 00:31:27elliot.gorokhovskycreate