Pylons gets out of the way, and stays out of the way. It lets me use SQLAlchemy, the best Python ORM available. It lets me do things the right way, and it always lets me do things my way. It doesn't hold my hand, and I don't want it to.
For example, from the Django documentation:
django.middleware.common.CommonMiddleware handles ETags based on the USE_ETAGS setting. If USE_ETAGS is set to True, Django will calculate an ETag for each request by MD5-hashing the page content, and it’ll take care of sending Not Modified responses, if appropriate.This means that your django application most likely needs to talk to a database, process some code, parse and render a template before it can generate an etag. If you want to fix this behavior... best of luck to you.
With Pylons, I can do one lookup on the database and generate an etag, short circuiting the whole operation, shaving CPU time and RAM requirements. Sure, I had to write this code myself (2 lines including the db lookup) for each relevant controller method. However, my web service will scale much better because of it.
It is small details like this, and the tweakability of a Pylons installation that make it a much better framework for HTTP and REST nuts.
Now, I'm betting that most web developers out there don't really care about etags. If this is you, then perhaps django is the right tool for you. However, with a tad more effort and learning, Pylons will let you write better software.
12 comments:
And just think, if you start using Twisted, with just a little more effort and learning, you'll really be writing better software. Plus you'll get to utilize the fact that the internet is not just HTTP!
Which part of the above is could not be done via Django?
I recommend that you read this:
http://adam.gomaa.us/blog/frameworks-exist-for-conceptual-integrity/
one of the best post on Pylons that I have ever read.
As long as one works with the 'garage shop' mentality Pylons works well. If you don't have that luxury then you are in trouble.
If you want to fix Django's ETag behaviour... you can fix it in exactly the same amount of code it took you to fix it in Pylons. Just because the ETag middleware exists doesn't mean you should use it if it doesn't fit your needs. You can use Django's ETag middleware as guidance: http://code.djangoproject.com/browser/django/trunk/django/middleware/common.py#L106
Pylons also supports easy_install a little better than Django. This way you can "hook" into many other applications from a single Pylons app easier.
"easy_install 'Django==0.96'" installed a broken build of django (the template dirs were missing from contrib modules) on my python 2.5 setup the other day. I was going to submit a bug but while digging into django's setup file I wasn't sure it was actually a bug or not. Anyway, python setup.py install worked fine and it just suggests that not much effort is put into supporting setuptools in django.
Fortunately the "garage shop" mentality is very appropriate in many situations, for example, reddit.com, where Pylons and Mako and all its open-endedness is just what they were looking for.
Django is great and all but I wish its userbase would understand that its just *one* way of doing things, which does not suit the entire python community equally. This is the only issue I've ever had with Django; the "there should be one true framework" mentality that constantly seems to emanate from its community. There should not. Djangoers needn't be concerned with the existence of other web framework approaches.
"Garage shop mentality". I like that phrase. It seems to contain the point I'm trying to make. Different frameworks suit different situations and applications.
If I could continue the garage shop metaphor... I guess Django is great at churning out pre-fab consumer vehicles, where Pylons is aimed more at delivering racing vehicles, where every part of the machine is finely crafted and tuned.
You can paint a house with Django, or you can create a piece of art with Pylons.
Simon: with respect, you haven't responded to my earlier comment. The example you used in your post (ETag support) is flawed: it's no harder to implement ETags correctly in Django than it is in Pylons, and Django does nothing to discourage you from doing so (unless you found Django's ETag middleware documentation to be misleading, in which case this is a documentation bug which we should definitely fix). There are many reasons that you might prefer Pylons to Django, but support for custom ETag logic should not be one of them.
The etag code I mentioned is a fairly trivial example. My point was really about default behavior.
In Pylons, the default behavior is to do nothing. You have to think about how you might want to use etags, and therefore have to know how etags work.
In Django, the default behavior is a sub-optimal solution which will break sometimes.
This is really a silly point to be debating when comparing frameworks, I just used it to show how Pylons gets out of my way when I want to go down into low level HTTP.
The real crux of the issue is SQLAlchemy. Pylons is the only major framework where its given first-class support. Event the SA support in TG is rather patchy.
>The real crux of the issue is SQLAlchemy. Pylons is the only major framework where its given first-class support. Event the SA support in TG is rather patchy.
Hmm, i think that with a couple of lines of code i could get same SQLAlchemy support in django.
My point is that I can change almost every aspect of django when I want it or when it doesn't suit my needs, but for most things you would like to do it gives you everything you need. I can start project and make new features very quick. I don't have to go very deep into http because this doesn't matter at this point. If your project fails because of slow startup phase (because you wanted to build top notch machine) it doesn't matter what kind of authentication or session framework you used, because you failed.
IMHO Django is GTD of python web frameworks.
I agree.
BTW: TurboGears 2.0 is just going to be a layer on top of Pylons that will make it easier to get going with a project that uses SA, Genshi, etc. IMHO, TG2.0 will be the best of both worlds.
Totally off topic - are you still happy anout your XPS M1330? did you get the cam working?
Martin
Yeah, still quite happy with the M1330.
I haven't had time to look into getting the cam working, but I do believe it is just a matter of time before Ubuntu gets a working driver.
Post a Comment