[Python-Dev] decimal.Context.copy() shallow or deep? (original) (raw)
Tim Peters tim.peters at gmail.com
Sun Aug 8 04:53:40 CEST 2004
- Previous message: [Python-Dev] decimal.Context.copy() shallow or deep?
- Next message: [Python-Dev] decimal.Context.copy() shallow or deep?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[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 shallowcopy and replace the original with a deep version for the public API.
Any thoughts?
Whatever works .
- Previous message: [Python-Dev] decimal.Context.copy() shallow or deep?
- Next message: [Python-Dev] decimal.Context.copy() shallow or deep?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]