This approach makes template rendering much more flexible!
For example, it would be easy to swap out a template for a mobile one ... or to A/B test a template. Or choose the content type of the output (HTML, JSON etc.)
Wordpress initially gave their latest release the code name Django (they always use jazz musicians as a theme), but quickly changed it to Reinhardt after a few polite complaints.
I agree. Switch immediately if you're just learning or playing around with Django. Most likely, the biggest change in casual development will be the class-based generic views, which I think are an improvement over the previous function-based generic views.
If there's no conflicting code changes compared to what you've already written, upgrade away!
If there are changes needed to support the new version you'll have to weigh the time needed to implement the changes to the new features/improvements in the new version; is it worth it? Only you can make that decision.
You may want to take a look at Pinax to get a HUGE head start on a django-based web app. (http://pinaxproject.com )
And since installing Pinax auto-installs django 1.2 (currently), you may want to stick with that.
But if you aren't using Pinax, move forward to 1.3 if you are new.
I'm using Pinax, and I'll use the version that they auto-install with their product (which was 1.2 when I installed on a new machine yesterday). I can't wait until Pinax ships 1.3! looks cool!
I was using Pinax, but I just moved my apps over to a vanilla 1.3 install.
Pinax has some cool stuff, but I gotta be honest, I found it a little tough on a newbie. Maybe I just choose poorly on my starter project, but it took me a while to understand how Pinax uses templates and how the media handling works. And it turns out that I'm actually rather particular about my templates and how I want my tagging to work. It also wasn't always clear how Pinax deviates from a regular install, so it made just that much harder to ask for help or reference other tutorials.
When Pinax comes out for 1.3 I'll definitely take another look. I certainly don't intend to build my own account creation & verification & user profile app, when it's got what looks like a very nice one.
That was the case until 1.0, but I don't think that's really the case since the 1.0 release, let alone later ones. That may have taken off again due to the 1.3 delays, but that's not a trend.
Point releases are supported, with clear changelogs and migration paths and available from pypi. They're really much easier to work with than trunk.
No, switch now. If only for the new 'render()' shortcut.
For what it's worth, I've upgraded a couple of 1.2 projects to 1.3 and it hasn't caused any problems. That's anecdotal, and I don't know what, if anything, is supposed to break, but if it's a baby project, better to switch before it gets too big.
I can't believe it... not one comment telling the django guys to quit celebrating and get back to work on a version that supports Python 3? :-)
Seriously, Adrian, Jacob, and the django team, I love your product. I actually just bought a SECOND copy of your book (available free on the web). What's wrong with this picture?
"Because of that we strongly recommend against using Python 3 for web development of any kind and wait until the WSGI situation is resolved. You will find a couple of frameworks and web libraries on PyPI that claim Python 3 support, but this support is based on the broken WSGI implementation provided by Python 3.0 and 3.1 which will most likely change in the near future.
Werkzeug and Flask will be ported to Python 3 as soon as a solution for WSGI is found, and we will provide helpful tips how to upgrade existing applications to Python 3. Until then, we strongly recommend using Python 2.6 and 2.7 with activated Python 3 warnings during development, as well as the Unicode literals __future__ feature."
I agree (except for the part where you wanted to down-vote me). I wasn't trying to say it was their fault. It was more a comment about other comments, not about the django guys.
I love django. But I also I can't wait for the day when we can quit talking about Python 2, and that Python 3 will be the obvious choice for ALL environments.
Considering Python 3K discussions go back to 2006 (PEP 3000) or earlier, and Python 3 was released in 2008, and we're still probably years away from closing the book on Python 2, it's just amazing how long it takes to "turn a battleship". This transition to Python 3 might be a decade or more, from start to finish! amazing!
Congrats to the Django team! I know you guys have worked very hard to put this together. I've been waiting for this final release for quite some time, having tried the beta release since launched.
Some of the new stuff is really cool, and means I won't have to rely on external libraries anymore (like passing context variables in template includes).
Also, the new logging functionality is really great!
Class-based generic view is a nice addition. I remember when I was learning Django and going through the official tutorial, that was one part that took me a while to understand. Kudos guys!
No, you can make your own class based views with the 1.3 codebase. The docs describe them as replacing Generic Views, but nothing stops you from creating your own class hierarchy that inherits from the base TemplateView (http://docs.djangoproject.com/en/1.3/ref/class-based-views/#...)
They backported the Python 2.7 unittest module to Python 2.4 and included it in Django? It is getting enterprisey. Maybe with Django 2.0 they will ship their own Python version?
Mostly when we do this, it's because there's a really useful/helpful stdlib module that wasn't standard for one of the older Python versions we support. We check first to see if you have the stdlib version (or in some cases a third-party distribution of it), then fall back to our bundled copy.
In many cases we've had direct help from the maintainers of the stdlib modules in doing this, so saying that "we" backported it isn't particularly accurate.
(the big exception to all this was PyDispatcher, which we originally included verbatim, then essentially ended up forking to suit our needs, to the point where I don't think it's really the same library anymore)
We also do some similar but smaller-scale things to smooth issues in older Pythons or to enhance standard language features (for example, we monkeypatch Python 2.4's copy module, and ship our own implementation of parts of os.path to handle Unicode properly). Poke around in django/utils for the sordid history of all the stuff we've worked around in this manner.
A good thing, short of depending on unittest2 itself (I don't believe Django "accepts" to depend on third-party projects as it's supposed to be self-contained).
unittest2 is a really big improvement over the old unittest, there are new (and better) assertions, improved comparisons (which diff containers on mismatches for instance, and the equality assertions are pluggable), improved fixtures (class and module-level setup and teardown), improved cleanups (separate from teardowns), autodiscovery has finally been included and is pluggable (you can override it for your modules), etc...
Because Django 1.2 has its own layer on top of unittest (to do basic setup and fixtures loading for the developer and integrate with management commands for instance), using unittest2 with it is a pain.
I, for one, am very happy with this development.
> It is getting enterprisey.
Because they bundle a preexisting library instead of developing yet-another-unit-testing-library?
Though I agree it's quite unpythonic, there's precedent for this practice in the history of Django. Simplejson has been bundled with Django for a long time (at least as far back as 1.0).
Just like with unittest2, it would check for Python 2.6+, and use its json library if available, then check if simplejson is already available on the pythonpath, and if that failed, only then use the bundled version.
The justification for this is that Django has a policy of not requiring external libraries, and that the new conveniences offered by unittest2 are too awesome to ignore.
I particularly like the idea of TemplateResponse - the earliest implementation I saw was in simonw's:
https://github.com/simonw/django-openid/blob/master/django_o...
This approach makes template rendering much more flexible!
For example, it would be easy to swap out a template for a mobile one ... or to A/B test a template. Or choose the content type of the output (HTML, JSON etc.)