Michael H. Goldwasser wrote:
On Monday June 1, 2009, Scott David Daniels wrote:
Michael H. Goldwasser wrote:
> .... I'll accept the "small price for flexibility" that you
> note, if necessary. However, I still desire a cleaner solution.
You seem to think that "deepcopy" is a well-defined concept. ....
It is clear from my original statement of the question that there is
a need for classes to be able to customize their own semantics for
supporting the deepcopy function. That is why the deepcopy function
looks for a __deepcopy__ method within a class as a hook.
My concern involves the challenge of providing a valid
implementation for __deepcopy__ at one level of inheritance without
being overly dependent on the internal mechanism used by ancestor
classes in supporting deepcopy. I don't see how your comments
address that question.
I only meant to say, if you are looking for something neater,
consider whether there is such a thing. Issues with deepcopy
may be (and I suspect are) inherently messy. Further,
inheritance usually provides (in practice) a "built from"
relationship, not an "is a" relationship. "Liskov
Substitutability," is a design goal, honored except in corner
cases and where inconvenient.
--Scott David Daniels
scott.dani...@acm.org
--
http://mail.python.org/mailman/listinfo/python-list
