Live data from Hacker News

Django 1.3 released

djangoproject.com

1–10 of 42 posts

Re: Django 1.3 released

#2
It's been fun watching these features play out in libraries over the last year.

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.)

Re: Django 1.3 released

#3
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?

Re: Django 1.3 released

#4
post #3

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?

> They backported the Python 2.7 unittest module to Python 2.4

No, unittest2 is a project by unittest's own maintainer (Michael Foord): http://www.voidspace.org.uk/python/articles/unittest2.shtml

> and included it in Django?

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?

Re: Django 1.3 released

#5
post #3

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?

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.

Re: Django 1.3 released

#6
post #2

It's been fun watching these features play out in libraries over the last year. 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…

Yeah, I was really pleased to see that they've taken that concept and turned it in to a real, tested, documented feature.

Re: Django 1.3 released

#7
post #3

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.

Post reply on HN