[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 

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.



More information about the Grok-dev mailing list