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
