Revert enthought/traits#373: instance traits are no longer pickleable #462
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
#373 made instance traits (not
Instance
traits![*]) pickleable. While the aim was a good one, the change introduced a variety of unintended consequences and breakages, so I'm reverting it here. We may be able to do it again properly one day.The main issues are:
Pickling instance traits requires that the corresponding
TraitType
objects are pickleable (whereas for class-level traits, we only need to pickle the trait values). ManyTraitType
objects currently aren't pickleable, especially in Python 2. That could certainly be fixed: see Make some previously-unpickleable trait types pickleable. #457 for some work in that direction, but there's much more to do.Even in the absence of use of
add_trait
(which is relatively rare in most Traits projects), the_instance_traits
dictionary has entries added to it whenever a listener is attached to a class trait on aHasTraits
object: the instance trait acts as the place to register listeners that are specific to that instance. This meant that Resolve pickling and deepcopying bug with dynamically added traits #373 resulted in attempts to pickle various (as it turns out unpickleable) class-level traits, breaking existing code. This again, could be fixed, at the cost of some work and some restructuring.Point 2 is what causes the unexpected breakage of previously working code.
I'll re-open the various issues that were closed by #373.
[*] Not "Instance" traits! This issue is about traits added directly to an object (e.g., with
HasTraits.add_trait
), as opposed to traits declared at class level.Closes #452