3 ms·

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 ow

by beza1e1 16y ago

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?

masklinn 16y ago
> 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 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?
Aramgutang 16y ago
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.
ubernostrum 16y ago
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.

by beza1e1 16y ago

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?

masklinn 16y ago

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

Aramgutang 16y ago

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.

ubernostrum 16y ago

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.