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? 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 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. Representational minimalism is troublesome in general code (ala Perl), but not so in a DSL where the context is constrained. I would also like to symbolize field types since they occur so commonly in a definition file and only a few of them are commonly used. I admit though that I find the code below a bit visually jarring and I might use something else. But it serves to illustrate the point. I chose the respective symbols based on their colloquial use and association with the field types. @Poll: $question: length 200 %pub_date('date published') @Choice: poll -> Poll $choice: length 200 #votes Since you are on thread and are a prominent and involved member of the Python community, I would like it if you (or any such other) can provide feedback on the rest of my previous post rather than be dismissive by just a small portion of it. Perhaps, that will give me some insight how these language design decisions are rationally made (I am not strictly a programmer by profession, much less a language designer). -- http://mail.python.org/mailman/listinfo/python-list
