Author njs
Recipients Mark.Shannon, benjamin.peterson, larry, njs, pitrou, serhiy.storchaka
Date 2015-08-30.16:49:35
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1440953376.13.0.223900181425.issue24912@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2015-08-30 16:49:36njssetrecipients: + njs, pitrou, larry, benjamin.peterson, Mark.Shannon, serhiy.storchaka
2015-08-30 16:49:36njssetmessageid: <1440953376.13.0.223900181425.issue24912@psf.upfronthosting.co.za>
2015-08-30 16:49:36njslinkissue24912 messages
2015-08-30 16:49:35njscreate