![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
Django django django django django DJANGOOO
At work I'm learning Django to make a quick demo site, something I've been meaning to do for some time.
For context, I was brought up with Turbogears 1.0, and my native environment generally centres around CherryPy, Genshi, and running as far away from SQLAlchemy as possible (fortunately working with the company's own search engine negates the need to interact with SQL too much).
My first impression was how easy Django was to install. I opted for a virtualenv automatically, being used to TurboGears and Pylon's massive dependency list dragging in most thing under the sun. However, while a virtualenv is always a good thing while developing, I was delighted that Django is just a single package. Having spent an afternoon recently trying to track down moved, deprecated, and obsolete packages to try to get an old but maintained TurboGears 1.0 project installed on a new server, it's reassuring to know that in a few years time I'll only have to hunt down one package should the latest Django at that time be incompatible.
Django has an equivalent to TurboGears' tg-admin script in the form of django-admin.py, which does the job. I don't have a problem with not using Paste to start a project, although I prefer CherryPy's five-line write-it-yourself philosophy.
While their templating language is apparently swappable (thank goodness; their own one is massively inferior to genshi in my preference) it looks like they've gone for the Routes approach of regex-style dispatching rather than attribute-based lookup which makes CherryPy a joy to use. And unlike Pylons, they make you write actual regexes in Python's clunky syntax, which makes it even less fun.
The different terminology to everything else is a bit weird. They have a FAQ regarding their terminology, which I assume is cover for "we didn't know the terms when we started the project and we're damned if we're changing them now". With regards to adherence to the Python style guide, they're not bad, but HttpResponse really bugs me; "HTTP" is even a specific example in there!
Finally, I was rather annoyed to find that I was unable to pull up online help very easily to find out what SQL field types were available. I wasn't able to even import the module without using django-admin.py shell and then help(django.db.models) doesn't actually show any field types. They must be hidden elsewhere...
Anyway, overall I think we're going to get on just fine, but I think I'll continue to do with CherryPy and Genshi in the future for new projects. Ultimately, I suppose, it's a matter of what you're familiar with and used to.
For context, I was brought up with Turbogears 1.0, and my native environment generally centres around CherryPy, Genshi, and running as far away from SQLAlchemy as possible (fortunately working with the company's own search engine negates the need to interact with SQL too much).
My first impression was how easy Django was to install. I opted for a virtualenv automatically, being used to TurboGears and Pylon's massive dependency list dragging in most thing under the sun. However, while a virtualenv is always a good thing while developing, I was delighted that Django is just a single package. Having spent an afternoon recently trying to track down moved, deprecated, and obsolete packages to try to get an old but maintained TurboGears 1.0 project installed on a new server, it's reassuring to know that in a few years time I'll only have to hunt down one package should the latest Django at that time be incompatible.
Django has an equivalent to TurboGears' tg-admin script in the form of django-admin.py, which does the job. I don't have a problem with not using Paste to start a project, although I prefer CherryPy's five-line write-it-yourself philosophy.
While their templating language is apparently swappable (thank goodness; their own one is massively inferior to genshi in my preference) it looks like they've gone for the Routes approach of regex-style dispatching rather than attribute-based lookup which makes CherryPy a joy to use. And unlike Pylons, they make you write actual regexes in Python's clunky syntax, which makes it even less fun.
The different terminology to everything else is a bit weird. They have a FAQ regarding their terminology, which I assume is cover for "we didn't know the terms when we started the project and we're damned if we're changing them now". With regards to adherence to the Python style guide, they're not bad, but HttpResponse really bugs me; "HTTP" is even a specific example in there!
Finally, I was rather annoyed to find that I was unable to pull up online help very easily to find out what SQL field types were available. I wasn't able to even import the module without using django-admin.py shell and then help(django.db.models) doesn't actually show any field types. They must be hidden elsewhere...
Anyway, overall I think we're going to get on just fine, but I think I'll continue to do with CherryPy and Genshi in the future for new projects. Ultimately, I suppose, it's a matter of what you're familiar with and used to.