Nice to see Django moving forward! I've been developing with Django since 2006 and have been frustrated at seeing the steam and community seem to stagnate in comparison to the Rails community. Granted, I've heard the opinions that the Django community is less vocal because they're busy actually building things--which I could agree--but as a fresh developer I could see how the Rails community would seem more inviting. I've played around with a couple good ideas in my head for promoting the Django userbase but haven't gotten around to it.
Me too! Adrian and Jacob have both spread their wings beyond Django and now that EveryBlock is doing well it's nice that Adrian can turn some of his attention back to the community. Some clear official direction can go a long way.
For those of you wanting to quickly check it out without interfering with your existing setup, we are working on an installer and VM image for Django 1.4 and will post it shortly on http://bitnami.org/stack/djangostack
These are self-contained packages, include their own pre-configured copies of Apache, MySQL, etc. As far as I understand virtualenv only applies to Python + related packages, not other dependencies. But I agree that for many setups, virtualenv would work fine as well.
Why no python3 version?
Django depending on other components which have not been ported to python3 yet and python3 being backward incompatible it takes time to port them all of course.
But as python beginner, I want to start by learning python3 which was released on December 3rd, 2008
It's available; see https://bitbucket.org/vinay.sajip/django/. This is in "ready to merge" status, i.e. it's technically ready to the point we want to merge it into Django proper. I hope to do so soon, possibly as soon as next month at the PyCon sprints.
However we decided not to merge this in for 1.4 for a couple of reasons:
1. As you might imagine, it's a big patch, and potentially destabilizing. Although it's in a good state now, it go there fairly late in the 1.4 cycle. If we'd merged it there wouldn't have been enough time to be sure we didn't break anything for 2.X users. So we held off the merge to make sure that 1.4 was as stable as possible.
2. The approach Vinay took (and the one we're sticking with) is a single-source approach. That is, a single source tree to support both Py2 and Py3, no 2to3 translation needed. The difficulty of this approach is directly proportional to how far back in the 2.X line you want to go. We promised that Django 1.4 would support Python 2.5, but single-source including 2.5 is a lot harder (and makes MUCH uglier code) than single-source for 2.6+. So we made the call to make the Py3 support depend on dropping support for 2.5, which we'll do for Django 1.5.
So, all in all, time timing wasn't right for Py3 support in 1.4, but it is right for Django 1.5. Which is why I expect to see this branch merged shortly after the final 1.4 release.
An experimental port of Django to Python 3 that passes all regression tests on Python 2.5 to 2.7 as well as Python 3.2 is available here: https://bitbucket.org/vinay.sajip/django/
I mostly concur with this sentiment. I jumped straight into Python 3, and the amount of incompatibility was almost frustrating enough to make me drop the language entirely.
However, if you're stubborn enough to power through (and not afraid to roll up your sleeves and manually correct any errors you encounter (which is actually quite a good way to learn the nuances of a new language)) your reward is a language that is more forward-thinking and consistent. Sometimes it's worth the frustration (but only sometimes :) ).
You are right. It isn't your job to learn on old versions of Python just so that Django does not have to release a port yet. Many projects have been waiting on other projects to port, thankfully the progress in library porting has picked up speed and the available library for Python 3 is very usable.
And Python 3 actually is a reasonable decision for a beginner. It is more consistent and does a better job of exposing the 'right' way to do many things.
Python 2 is reaching the end of its life and has little purpose except to support legacy libraries and apps and ease the transition.
It is not the users of Python 3, but people insisting on using Python 2 to the EXCLUSION of Python 3, who are fragmenting Python
> Armin has repeatedly talked about how much slower Django's template rendering is than Jinja's, and I want to cut out our inefficiencies to bridge the gap.
Why not simply switch to N^HJinja2? (Okay, probably not that simple, but still.)
The specific reason not to switch to Jinja2 was that Django's templating language was originally intended not to be that powerful, so that you could feel reasonably safe handing it to non-technical "designers" or "writers" rather than fearing that they would generate a great variety of new tracebacks for you to look at.
If you have to ask why Django would not switch to (or even make any effort to allow the use of) any externally developed tool in place of its own, you might not have noticed that almost everything in Django is self-developed and that the officially given reason is that they are "perfectionists. with deadlines."
The reason why not is the Django project's philosophy
The specific reason not to switch to Jinja2 was that Django's templating language was originally intended not to be that powerful, so that you could feel reasonably safe handing it to non-technical "designers" or "writers"
Jinja2 follows this same philosophy of a sandboxed engine and the syntax matches django's almost exactly (it was actually based on django templates). The designer wouldn't even notice he is dealing with a different templating language.
So, it looks the same from a designer perspective, is at least an order of magnitude faster and is much simpler to extend. So, why not switch?
Anyone else's imaginations going wild thinking what bizarre combination of circumstances might lead to the lack of a "group by" in an ORM leading to a gradual death, during which one still has sufficient strength to post to HN?
No group by means that a Mr. Blair's project fails, and he gets fired, and loses his health insurance. Combined with his pre-existing medical conditions, he cannot get another job nor afford treatment, and dies a slow death of, say, bonitis.
Literally dead, for lack of a "group by" in an ORM.
Here is a direct link to the changes: https://docs.djangoproject.com/en/dev/releases/1.4-beta-1/#w...