Re: [Modeling-users] ModelMasons refactored

[Mario R. <ma...@ru...>]

On vendredi, avr 25, 2003, at 12:17 Europe/Amsterdam, Sebastien Bigaret=20=

wrote:
> Mario Ruggier <ma...@ru...> writes:
>> On mardi, avr 22, 2003, at 15:15 Europe/Amsterdam, Mario Ruggier=20
>> wrote:
>>> On mardi, avr 22, 2003, at 14:07 Europe/Amsterdam, Sebastien Bigaret=20=

>>> wrote:

>>>>>>>   def __init__(self,att1=3DNone,att2=3DNone):
>>>>>> instead of
>>>>>>>   def __init__(self):
>>>>>>
>>>>>>   Are we ok we go for it?
>>
>> A propos de previous post on KeyValueCoding names -- this proposition
>> lacks a minor thing, and that is inside the __init__ body, the
>> attribute values should be set using KeyValueCoding, not to bypass =
any
>> custom code in the get/set methods for each attribute.
>
> That's questionable. KVC mechanisms are handy, but
> time-consuming. Moreover, I'd like to keep as little modeling-specific
> things in the generated code as possible --for the moment being there
> are Modeling.CustomObject  in the inheritance tree, and
> willRead()/willChange() methods [1].
>
>   I'd recommend self.setAtt1(att1) in __init__() rather than
>   self.takeValueForKey(att1, 'att1') in this case.

Yes, you are right ;)

Since last night, i've rethought my little proposal, and I would
now be against it because of (a) if it is done this way, custom property
logic should not be bypassed in my opinion, and (b) if a KVC loop
is to be performed each time any CustomObj is initialised, the
performance price is too high.

But, how about this little compromise, as a utility function that
can be used only when needed:

def updateCustomObject(co,**kwargs):
     for k in kwargs.keys():
         co.setValueForKey(kwargs[k],k)
     return co

It receives an instance =3D=3D>> can be used on new objects
(instantiated on the call) as well as existing instances.

>> Additional proposal ;)
>> How about adding __slots__ to all custom objects?
>> It seems to me that this is exactly the kind of usage that this was
>> intended for, and will reduce memory usage for cases of *many*
>> instances of custom objects. Works only for 2.2, but if present =
should
>> not affect 2.1 instances in any way.
>
> Could you be more specific? I can't see how slots reduce the memory
> footprint.
>
> More on slots: the framework cannot handle them out-of-the-box right
> now, I can see the following problems:
>
>   a. when an EC records an object (either insert or fetch), it =
weakrefs
>      itself and assigns the weakref to the object (see
>      EC.recordObject()) --> this implies that CustomObject must be
>      turned into a new-style class in py2.2, defining __slots__ as=20
> well.
>
>   b. Such an object cannot be weakly references, unless CustomObject
>      adds '__weakref__' in its slots.
>
>   c. An object using slots has no __dict__
>
> [See also: http://www.python.org/2.2.2/descrintro.html for a complete
>  discussion on csqs. of using slots]
>
> a. and b. can be easily solved. However c. is more problematic; this =
is
> an issue that should carefully examined (the impact is on KVC, =
mainly],
> I'm not clear at all on this by now (I've never used new style classes
> until now).

You are right, again ;)
I had not realised that __slots__ implied also these other things.
So this can be put on hold, for possible future consideration.

> -- S=E9bastien.
>
>
> [1] I'm currently working on a integrating the framework w/ the ZODB
>     framework. In this configuration willRead/willChange methods
>     disappears, and CustomObject inherits from ZODB's Persistent =
class.
>     I'll make a branch and an alpha release as soon as possible.

Any implications for those not using ZODB?

mario