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 ncoghlan
Recipients ncoghlan
Date 2016-01-09.12:56:10
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1452344171.87.0.895462140972.issue26060@psf.upfronthosting.co.za>
In-reply-to
Content
Dave Beazley found some odd behaviour in Python 3.4.1+, where the order of the keys in a class dictionary can be changed by assigning a new value to an existing key: https://gist.github.com/dabeaz/617a5b0542d57e003433

Dave's original reproducer showed a case where iterating over class attributes replacing some of them with new values worked correctly as a class decorator on a normal instance of type, but was unreliable when the same operation was called from a metaclass __new__ or __init__ method.

Further investigation showed that it wasn't the timing of the assignment that mattered, but rather the use of a subclass of type rather than type itself as the metaclass.

Checking between 3.4.0 and 3.4.1 with hg bisect using the simpler attached script as the reproducer identified the enabling of key sharing with subclass instances in #20637 as the apparent culprit.

My current theory is that from 3.3.0 to 3.4.0, keys weren't being shared between instances of type and instances of type subclasses at all, and changing that in 3.4.1 broke a subtle assumption somewhere in type_new.
History
Date User Action Args
2016-01-09 12:56:11ncoghlansetrecipients: + ncoghlan
2016-01-09 12:56:11ncoghlansetmessageid: <1452344171.87.0.895462140972.issue26060@psf.upfronthosting.co.za>
2016-01-09 12:56:11ncoghlanlinkissue26060 messages
2016-01-09 12:56:11ncoghlancreate