Ravi Teja wrote: > Fredrik Lundh wrote: > > Ravi Teja wrote: > > > > > Web frameworks, which seem to be the rage now in Python community could > > > have benefited tremendously from Macro capabilities since they have a > > > lot of boiler plate. > > > > they do? methinks you haven't done much web programming lately... > > > > </F> > > You blogged on Django. Let's use that. Don't you think model creation > in Django can be represented better, given that it is done often > enough?
Actually, no, it's not done that much. Creating and managing tables isn't something done lightly. It's essential to building a new application, but (at least in my experience, in similar systems) the database models stabalize early and you don't spend that much time with them. Especially not with the DSL aspects. I add and remove methods often, but I am loathe to add and remove columns. Now, this might seem like I'm being pedantic, but in my experience lots of seemingly obvious DSLs end up not being that obvious. XML generation, for instance. It's nice to have a good syntax -- and you can get a pretty good syntax in Python (e.g., HTMLGen, stan, etc). But efforts that go further are generally misplaced, because it's actually not a very hard or common thing to do, even when you are slinging around lots of XML. Or... maybe to be more specific, the hard work later on goes into *code*. If you are enhancing your model, you do so with methods on the model classes, and those methods don't effect the DSL, they are just "code". You create some raw XML in the beginning, but quickly it's just a matter of gluing those pieces together, using functions instead of DSLs, and that's just "code". > Let's take an example from the official tutorial > from > http://www.djangoproject.com/documentation/tutorial1/#creating-models > > class Poll(models.Model): > question = models.CharField(maxlength=200) > pub_date = models.DateTimeField('date published') > > class Choice(models.Model): > poll = models.ForeignKey(Poll) > choice = models.CharField(maxlength=200) > votes = models.IntegerField() > > I don't use Django and I made this up quickly, so please don't pick on > subtleties. > > @Poll: > question: char length 200 > pub_date('date published'): date > > @Choice: > poll -> Poll > choice: char length 200 > votes: int That doesn't look that much better. How do you create it programmatically? I know how to pass a variable to CharField(maxlength=200); can I pass a variable to "char length 200" just as easily? Can I use **kw? Can I read it from a CSV file and construct the class that way? Maybe, but only by recreating all the native patterns that I can infer easily looking at the Django class. > The following is my rationale. Annoted variables, symbols and code > layout visually cue more efficiently to the object nature than do > explicit text definitions. Of course, this is only sensible when there > aren't too many of any of those. In that case, the cognitive cost of > notation outweighs the representational cost of text. Words are great. Python is light on symbols, and that is good. Python is not perfect when it comes to expressing data structures (the more I think about it, the more PEP 359 grows on me), but real DSLs are questionable to me. Even the Lisps stick to an incredibly homogenous syntax (far more homogeneous than Python) to make macros feel familiar. > Representational minimalism is troublesome in general code (ala Perl), > but not so in a DSL where the context is constrained. Constrained context is a step backward! How do you add methods? How do you do looping? How do you write *code*? If you aren't going to allow those things, then just make a parser and build the structure from the file, and make it a DSL implemented entirely external to Python. That's completely okay, though in my experience it's not very satisfying for something like a model definition (see MiddleKit for an example of an ORM that doesn't use Python code). Ian -- http://mail.python.org/mailman/listinfo/python-list
