In article ,
Michael H. Goldwasser wrote:
>On June 2, 2009, Aahz wrote:
>>Michael Goldwasser:
>>>
>>>class A(object):
>>>def __init__(self, aTag):
>>>self.__aTag = aTag
>>>self.__aList = []
>>
>>IMO, your problem starts right here. Not only are you using customized
On June 2, 2009, Aahz wrote:
>>class A(object):
>>def __init__(self, aTag):
>>self.__aTag = aTag
>>self.__aList = []
>
>IMO, your problem starts right here. Not only are you using customized
>attributes for each class, you're using class-private
In article ,
Michael H. Goldwasser wrote:
>
>Assume that class B inherits from class A, and that class A has
>legitimately customized its deepcopy semantics (but in a way that is
>not known to class B). If we want a deepcopy of B to be defined so
>that relevant state inherited from A is copied a
En Tue, 02 Jun 2009 07:34:43 -0300, Lie Ryan escribió:
Gabriel Genellina wrote:
En Mon, 01 Jun 2009 14:19:19 -0300, Michael H. Goldwasser
escribió:
I can examine the inherited slots to see which special methods are
there, and to implement my own __deepcopy__ accordingly. But to do
so
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
Gabriel Genellina wrote:
> En Mon, 01 Jun 2009 14:19:19 -0300, Michael H. Goldwasser
> escribió:
>
>> I can examine the inherited slots to see which special methods are
>> there, and to implement my own __deepcopy__ accordingly. But to do
>> so well seems to essentially require reimplementi
En Mon, 01 Jun 2009 14:19:19 -0300, Michael H. Goldwasser
escribió:
I can examine the inherited slots to see which special methods are
there, and to implement my own __deepcopy__ accordingly. But to do
so well seems to essentially require reimplementing the complicated
logic of the co
On Monday June 1, 2009, Scott David Daniels wrote:
>Michael H. Goldwasser wrote:
>> Chris,
>>
>> Thanks for your well-written reply. Your analogy to the
>> complexities of other special methods is well noted. I'll accept
>> the "small price for flexibility" that
Michael H. Goldwasser wrote:
Chris,
Thanks for your well-written reply. Your analogy to the
complexities of other special methods is well noted. I'll accept
the "small price for flexibility" that you note, if necessary.
However, I still desire a cleaner solution.
You seem to think th
Chris,
Thanks for your well-written reply. Your analogy to the
complexities of other special methods is well noted. I'll accept
the "small price for flexibility" that you note, if necessary.
However, I still desire a cleaner solution.
I can examine the inherited slots to see which sp
En Mon, 01 Jun 2009 00:28:12 -0300, Michael H. Goldwasser
escribió:
Hi Kent,
Thanks for your thoughts.
For the original example code, you are correct that we could make it
work by having B provide the one-arg constructor to match A's
constructor signature. But I don't see this as a general s
Hi Kent,
Thanks for your thoughts.
For the original example code, you are correct that we could make it
work by having B provide the one-arg constructor to match A's
constructor signature. But I don't see this as a general solution.
Having B.__deepcopy__() make a call to A.__deepcopy__() assu
I've been playing around recently with customizing the deepcopy
semantics within an inheritance hierarchy, and run across the
following hurdle.
Assume that class B inherits from class A, and that class A has
legitimately customized its deepcopy semantics (but in a way that is
not known to class B
13 matches
Mail list logo
