Django 1.4 Beta 1 Release | Hacker News Reader

Django 1.4 Beta 1 Release

djangoproject.com

146 pointsgoogletron30 comments

Nice to see some added security features, including more secure password hashing.

Here is a direct link to the changes: https://docs.djangoproject.com/en/dev/releases/1.4-beta-1/#w...

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.

I'm hoping this will fix some of that: http://www.holovaty.com/writing/back-to-django/

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

Or you can use a virtualenv, like you already do for all your python projects.. right?

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.

Update: they are already there. Working now on the Amazon Machine Images

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

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/

Learn on python 2.x. You don't want to start with a version that has fewer compatible packages.

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 want to use Python 2.X for now. There has been a lot of concern about the backwards compatibility between old libraries and the new python.

Feel free to use 3.X, but don't expect a lot of the python libs that make it such a great language to hit the ground running in to work.

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

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.

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

> Why not simply switch to Ninja?

It's jinja2, not ninja. If you want, you can use Jinja2 in your projects, but the other plugins you use will most likely be using django templates.

If you want something faster, why not try Pyramid? It's a modular framework that lets you pick any component you want!

http://www.pylonsproject.org/

Mozilla does it with their Jinjo (template loader applying Django's layout conventions to Jinja templates): http://jingo.readthedocs.org/

Coffin ports some template tags as well: https://github.com/coffin/coffin/

That said, PyPy is 16× times faster rendering Django templates, which probably makes Jinja2's code-generation cleverness moot: http://speed.pypy.org/timeline/?exe=1&base=2%2B35&be...

Better yet, why not deliver first-class support for multiple templating engines, something like ruby's Tilt?

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

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?

the args/kwargs in templates is what I've been waiting for

https://docs.djangoproject.com/en/dev/releases/1.4-beta-1/#a...

If you can't wait till 1.4, you can do that right now with classy-tags[1].

[1] https://github.com/ojii/django-classy-tags

I hope bug #1744 is fixed... Not having a functional group by in the ORM is literally killing me.

I think you probably mean Ticket #17144.

#1744 was a bug in contrib.comments and was fixed 6 years ago.

And by "literally", you mean "hyperbolically".

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?

I'll give this a shot.

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.

Ran headfirst into this issue earlier this week. Unfortunately, the issue was not fixed in 1.4 as of Monday.

Judging by their published release timeline, 1.4 is set to be released the first week of March, I dont think a fix will make it in to 1.4. :[

Reply on news.ycombinator.com