[Grok-dev] class-level versus instance-level attributes for schema
Martijn Faassen
faassen at infrae.com
Fri Oct 20 07:21:04 EDT 2006
Philipp von Weitershausen wrote:
> Martijn Faassen wrote:
>> I see now that the __new__ in the schema support is gone. Reading the
>> code, I see that the attributes for the fields are added on
>> class-level instead of on instance-level. I wonder whether we can or
>> should change this.
>>
>> The current approach has the benefit of:
>>
>> * no __init__ necessary, so you can write your own
>>
>> An instance-level approach has the benefit of:
>>
>> * instance-level attributes are more inline with normal Python
>> approaches. class-level attributes are relatively rare.
>>
>> * we could hook in an __init__ that takes the schema names as
>> (optional) arguments.
>
> And if not specified, it sets them as default values as specified by the
> schema?
Yes, that sounds good.
>> But we'd need to poke in a custom __init__ into the class during
>> grok-time, which could be considered icky (then again, poking in
>> class-level attributes could be considered as icky as well).
>
> Why don't me make that the default grok.Model.__init__? In the rare case
> that people need to do their own initialization, they can choose to use
> super() (or not).
That sounds like a reasonable strategy, though I'd like to explore some
alternatives:
An alternative would be to have a separate SchemaModel object and do it
in the __init__ there, but another source of confusion could arise:
people using class fields on a non-schema model and having it not working.
What we could also do is create an __init__ based on the form, but only
poke it in if the grok.Model is not defining one itself. That might be
too magic however.
Regards,
Martijn
More information about the Grok-dev
mailing list