decimal.Context.copy() shallow or deep?
Currently, the copy() method for Context objects makes a shallow copy of the context. To get a deepcopy, you have to use copy.deepcopy(thecontext). Though, copies are usually shallow and deepcopies are deep, I'm now having misgivings about the copy method. I would think that a deep copy is almost invariably what you would want and expect, (i.e. the copy doesn't share traps and flags with the original). Do you guys think it should be left alone (shallow) or changed (made deep)? The wrinkle in all this is that internally the module makes many uses of copy and expects it to be shallow (or least, tests fail in droves when copy is made deep). So I would have to rename the current copy to _shallow_copy and replace the original with a deep version for the public API. Any thoughts? Raymond
[Raymond Hettinger]
Currently, the copy() method for Context objects makes a shallow copy of the context. To get a deepcopy, you have to use copy.deepcopy(thecontext).
Though, copies are usually shallow and deepcopies are deep, I'm now having misgivings about the copy method. I would think that a deep copy is almost invariably what you would want and expect, (i.e. the copy doesn't share traps and flags with the original).
Hmm. In my head (which I'm sure doesn't match reality, else you wouldn't be saying this), sets of trap-enabled and it-happened sticky flags are just integers with meanings assigned to the bits, as they are in hardware and most APIs for controlling and querying FPU status. Then there's no difference between shallow and deep copying.
Do you guys think it should be left alone (shallow) or changed (made deep)?
A user-visible copy certainly should not share mutable state with the original. It's possible that really argues for a simpler internal representation of such state, though.
The wrinkle in all this is that internally the module makes many uses of copy and expects it to be shallow (or least, tests fail in droves when copy is made deep). So I would have to rename the current copy to _shallow_copy and replace the original with a deep version for the public API.
Any thoughts?
Whatever works <wink>.
Do you guys think it should be left alone (shallow) or changed (made deep)?
A user-visible copy certainly should not share mutable state with the original.
I was afraid of that. What a PITA.
It's possible that really argues for a simpler internal representation of such state, though.
No doubt that would be the right thing to do (doubly so because that is how you would do it in C). Unfortunately, there a ton of code that has to change to get to an integer and bitmask approach. Also, you have to expose constants for masking. Then, you still have to deal with the underlying code liking the shallow copies.
The wrinkle in all this is that internally the module makes many uses of copy and expects it to be shallow (or least, tests fail in droves when copy is made deep). So I would have to rename the current copy to _shallow_copy and replace the original with a deep version for the public API.
Any thoughts?
Whatever works <wink>.
Done fast, right, and cheap -- pick any two. Raymond
participants (3)
-
Raymond Hettinger -
Raymond Hettinger -
Tim Peters