Hello! I'm brand new to Django, and it's exciting! Thought I'd pop in on this conversation...
* For what it's worth, at OSAF we recently switched object/relational declarations for Chandler to a class atrribute syntax somewhat like SQLObject's. For example, see http://viewcvs.osafoundation.org/chandler/trunk/chandler/parcels/osaf/pim/items.py?view=markup * Jacob, good point that mixing up instance and class variables is odd. However, Python does that funny mixup anyway -- which I don't like, but it's that way already. Class attributes appear as attributes attached to individual objects. class C(object): classVar = 5 def meth(self): print self.classVar * I understand the question to be: should class attributes in the model declarations be (1) Django metainformation (the current system: 'fields', 'admin', etc.), or (2) Python attributes (like SQLObject or Chandler schema) ? * One thing about django that confuses me is whether you're supposed to put backend ("business") logic inside model classes. Can I add lots of new methods to a model class and expect to intensively use them? The django docs show __repr__ and get_absolute_url(), but I could imagine wanting to add lots more that might have to do more database queries on other tables and such. This is suggested by http://www.djangoproject.com/documentation/models/custom_methods/ If it's the case that this type of use should be supported, I'd think that the model class' syntax should be as much like a normal python class as possible. For one thing, you want normal support for global variables and such (e.g. my oh-so-quickly-shot-down http://code.djangoproject.com/ticket/382 :) ). But also for this discussion, I'd think I would get confused seeing that admin=() and other metainfo aren't really class variables at all. If, on the other hand, model classes are supposed to be very bare object wrappers around the RDBMS, then the current model syntax might be alright, since it discourages using models like normal python classes. The inner "class Meta" for what's currently in ('admin', 'db_table', etc.) seems like a decent syntax to me... it has the benefit of not mixing together class attributes of types (1) and (2). Brendan Matthew Marshall wrote: > On Wednesday 17 August 2005 10:32 pm, Jacob Kaplan-Moss wrote: > > Howdy everyone -- > > Hey Jacob! > > > I think I was the driving force behind rejecting this ticket -- > > Adrian's still 50/50 as far as I know -- so let me explain why I > > don't like it. > > I think that just about everything can be answered :) > > > The first problem I have with the new syntax for models is that it > > makes it unclear what's a field and what's metadata:: > [snip] > > Yes, that was a problem. But, as already mentioned, it was fixed a while ago. > > > Second, what if I want a field named "admin"? > [snip] > > ditto > > > Third, from a semantic point of view it's just wrong. Consider:: > > > > class RegularOldPythonClass: > > classVar = 14 > > > > def __init__(self): > > self.instanceVar = 77 > > > > In the above example, ``classVar`` is, obviously, a class member and > > ``instanceVar`` is a member of *an instance* of the class. There's > > an important semantic distinction between instance variables and > > class variables that I don't think I need to point out to everyone. > > > > Unfortunately, the proposed model syntax subverts this. In the > > example above, ``field1`` is not a member of the Model class (try it > > -- ``Model.field1`` will raise an ``AttributeError``); it's a member > > of an *instance* of the ``Model`` class. So why are we defining it > > as if it were a class variable? On the other hand, ``fields`` *is* a > > class variable, so it makes sense to define it at the class level. > > Hmm... I guess this is really a matter of personal taste. > > If this really is a big deal, one way to fix it would be to place all of the > fields in their own subclass, instead of the metadata. (This was proposed > earlier.) > > > Finally, there's the "magic" aspects of dealing with something like:: > > > > class Model(meta.Model): > > field = meta.CharField(...) > > meta.ForeignKey(...) > > > > The "unadorned" ``ForeignKey`` simply doesn't make sense if you don't > > understand the magic going on underneath, whereas a list of fields > > makes perfect sense. I'm honestly less concerned with the crazyness > > of the code than I am with the weird and non-standard syntax. > > Nowhere else in Python does a non-assignment in a class result in a > > class member being created. > > Blame Adrian for that one :-D Anyway, during the IRC discussion, everyone > voted to take that out, so I guess it's not an issue. > > > In Python there's always a tension between clarity and the > > conciseness you can achieve by doing cool tricks with metaclasses. > > I'm all for getting rid of as much boilerplate code as possible -- > > that's why Django exists in the first place -- but not at the expense > > of clarity. I'd rather be more verbose and more clear than concise > > and confusing (again, if I wanted concise I'd use Perl). > > I fully agree with you that readability is more important than writeability. > However, I personally find this new method to be more readable. It makes the > fieldnames stand out more, and greatly cuts down on the amount of > non-alphanumeric characters. > > For myself, I don't care much whether it makes it into django or not. As I > mentioned before, I would just use it via a wrapper. I _would_ like to see > it included, however, because I think it will make things easier for others > using django. IMHO, it also looks better to those checking the framework > out :) > > So, it's really very subjective :P > > MWM
