Frameworks

[Emmanuel Surleau]

> Emmanuel Surleau a écrit :
> >>>>> It still manages to retain flexibility, but you're basically stuck
> >>>>> with Django's ORM
> >>>>
> >>>> You're by no way "stuck" with Django's ORM - you are perfectly free
> >>>> not to use it. But then you'll obviously loose quite a lot of useful
> >>>> features and 3rd part apps...
> >>>
> >>> You lose most of what makes it worth using Django,
> >>
> >> Mmmm... I beg to disagree. You still have the core framework (request /
> >> response handling, sessions etc), the templating system, the form API
> >> etc. As far as I'm concerned, it's quite enough to "make it worth".
> >
> > The form API is pretty good, but I don't think the rest makes it stand
> > out that much, compared to other frameworks.
> 
> I don't care if it "stand out that much" - it works fine and is well
> documented. Given that for most web apps, Django's ORM is a good enough
> tool, I don't see the point in using 3 or more "different" frameworks
> that basically do the same things in slightly different ways, each with
> it's own strong and weak points.

I think we'd be lucky to have just 3 :) But there are obviously advantages to 
something more modular like Pylons, and Tornado looks interesting as well 
(haven't used it yet, though). That's open-source for you.

> > To me, the notion of reusable apps
> > and the application ecosystem it allows is Django's most compelling
> > feature.
> 
> +1.

Thinking about it, that's where modularity can hurt, eg, Pylons. Developing a 
"reusable app" like Django's is more difficult if you don't know what ORM or 
templating system is being used. Unless you stick to the most popular choices, 
but this removes, in practice, flexibility for developers who need such apps.

> > You are, of course, welcome to disagree.
> 
> I'm not saying that Django is "better" than Pylons or web.py or (insert
> yur favorite framework here) - and to be true, I think Pylons is
> globally smarter than Django -, I'm saying that it do the job, and do it
> well enough to be worth using. Sorry for being so pragmatic.
> 
> >>> Having to implement a mini-parser for
> >>> each single tag
> >>
> >> Most of the "mini-parser" stuff is so very easily factored out I'm
> >> afraid I won't buy your argument.
> >
> > You'll at least agree that in terms of line of codes necessary to
> > implement a custom tag, it's very far from optimal, I hope?
> 
> I also agree that in terms of LOCs necessary to implement a log file
> parser, Python is also very far from optimal, at least compared to Perl !-)

I think that depends on how many regular expressions you use in your code. 
Think about all these lines with } you don't need any more. As far as 
languages go, Python strikes a good balance between readability and concision, 
really.

> How many Django custom tags did you write, exactly ? And of which level
> of complexity ? Once again, I'm not pretending Django is the best thing
> ever, but most of your remarks remind me of what I once could have say -
> that is, before having enough experience writing and maintaining Django
> apps. One of the greatest features of Django - and possibly what finally
> makes it so pythonic - is that it doesn't try to be *too* smart - just
> smart enough.

I'll grant you I don't have a huge experience with Django custom tags (or 
Django in general). Should I do more Django in the future, custom tags would 
irk me less (after all, I even got used to ASP, so...). This still does not 
make them particularly practical, though I agree that they are not a huge 
inconvenience.