Nathaniel Smith added the comment:

Wow, Mark, why so hostile? What's so wrong with my proposed less-intrusive 
patch that you feel the need to call for reversion while condescendingly 
pointing me to a non-solution? Of course I know about six. There was a whole 
python-dev thread about how neither its tricks nor any of the other tricks that 
python 3.4 allows actually do what we need.

Let me try again.

We all agree that this bug is a bug and that numbers should be immutable.

Our old rules for __class__ assignment were also buggy; it was just an accident 
that they were buggy in a way that happened to prevent a different bug, ie this 
one. The proper way to enforce the immutability of immutable builtins is to 
enforce the immutability of immutable builtins, not to enforce the immutability 
of a bunch of random types based on an implementation detail (that happens to 
include the immutable builtins). Reverting the patch gives us the latter, which 
is why I don't think it's the proper fix.

Now maybe we don't have time for a proper fix. I'm not sure why not -- AFAICT 
there would not be any disaster if this fix waited for 3.5.1. This is a scary 
looking bug, but the effect is that it takes something that used to require 3 
obscure lines involving ctypes and makes it into 1 obscure line not involving 
ctypes. Which is bad. But we're hardly going to see an epidemic of people using 
this loophole to change the type of 1 and then complaining to python-dev that 
they changed the type of 1, any more than we saw such an epidemic when ctypes 
was introduced. So we have time to take a deep breath and come up with a proper 
fix, is all I'm saying. But of course this is Larry's call.

If it is crucial to get a fix in for 3.5.0, then the least intrusive solution 
is not to revert the patch wholesale, but rather to add a (hacky but safe) 
guard to object_set_class. The guard I suggested above is stricter than 
necessary for correctness, but it catches all the problems described in this 
bug report, and the cases where it's over-strict are all cases where 3.4 was 
also over-strict, so there's minimal chance of it causing any regressions.

Like I said, I'm not sure that's what we want to do. But if it is then I can 
throw a patch together in a few minutes.

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue24912>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to