The feature I like the most from this release is by far the swappable User model. Needing an extra table and performing JOINs between the User and my profile table have really been a pain.
I also like that some effort has been made to update the tutorial, when I started back in 1.2 I recall the tutorial to be quite confusing and didn't know where to go after I finished it.
That was what attracted me, too, as I was starting a new project yesterday, but it turned out that the User model stuff is not as straightforward as I expected. In particular, a number of external applications/libraries have hard-coded references to auth.User, so those need to be patched.
So I'm using Django 1.5, but I'm using the old User->Profile setup, but I'm storing relatively little on the Profile.
EDIT: I've not found User->Profile to be much of an issue. I only store extra data in the Profile and don't have ForeignKeys against it, so I don't actually use the Profile that often.
I imagine there'll be somewhat of a database migration hurdle going from the profile configuration to auth.User, though. That seems like an incentive to use the format at one's earliest convenience.
>In particular, a number of external applications/libraries have hard-coded references to auth.User, so those need to be patched.
On that front, if I'm using a full blown framework (like Django or Rails) I try not to use any third party plugins for it. Third party libraries (ie. framework agnostic), yes, but not plugins.
I find that this is a sane middle ground between:
a) doing it yourself from scratch (maybe using a minimal base like Flask/Sinatra) and
b) adding the kitchen-sink of variable quality and volatile third party plugins, that are "here today, gone tomorrow".
This way you know you're building in a stable base that is gonna be there tomorrow (at least, most of it), that is, the framework, and you also get to build and know intimately the rest of the dependencies you might need.
Seems like you read my mind and wrote verbatim. When I started learning web app dev, I started looking at Django (1.2 at the time) and working with User and the user profile and connecting the dots b/w them was a major PITA. Even though I got a workable solution as a side project, that was my last Django project ever. <Now a happy Flask user just as peripheral info>
Django 1.5 has "full" Python 3 support, at least from a technical level. It's done, works, is well-tested. I'm planning on putting a Django 1.5 / Python 3.3 site into production later this year. So in that sense it's "done" now.
However, we sorta have to hedge our bets in terms of what we recommend others do.
We have a pretty serious backwards-compatibility promise, and we're not 100% certainly we've nailed down all the Python 3 APIs perfectly. There's a small (but non-zero) chance something might need to change between 1.5 and 1.6; we want the ability to make that change backwards-incompatible (for Python 3 users) if possible.
Similarly, there's a small (but again non-zero) chance that there's a serious bug or three in the Python 3 support. We don't want people getting bitten.
Finally, much of the "good stuff" in Django-land is actually in third-party apps, many of which don't yet support Python 3. This puts a pretty big obstacle in the way of a Django/Py3 site -- most real-world sites use a ton of third-party stuff. So to use Django on Py3 right now you'll need to make a bunch of "should I DIY this component or port it to py3 and submit a patch?" decisions.
In the case of the site I mentioned up top these are tradeoffs I'm willing to make. I know Django well enough to not be worried about potential bugs or backwards-incompatibilities, and I have the luxury on this project of getting to work on py3 patches as part of the deal.
Most people won't be so lucky, though, so we expect the majority of Django users to wait until 1.6 to start seriously using Py3.
We don't have a firm timeline yet. I'm guessing something like 6-9 months for 1.6, but that depends on a lot of different things. It could be longer, as much as a year, or possibly even as short as 3-4 months. We'll see :)
This is such a great answer. Definitely understand the reasoning here -- part of Django's strength is its ecosystem and its available third-party apps. Taking that away would certainly hinder adoption/productivity.
At the same time, it's important to realize that there will probably need to be some point in the future where Django has to take a stand and firmly put down a timeline on when apps need to be migrated to stay "relevant."
Maybe something like Python's Wall of Superpowers / Shame (http://python3wos.appspot.com/) though I know Jesse Noller has had some pushback on this website.
Is there a non-zero chance that all Python 2.* support will be removed in the future (2-3 years)? I'm with a company that's currently toying with the idea of using Django in our production environment. Py3 is a no-show in our plan or goals.
At some point, yes, we'll drop Python 2 support. When really depends on how rapidly we see adoption (from users and re-distributors of Django) and how heavy the dual-version support burden turns out to be. My guess is what we're looking at a longer support window than the 2-3 years you posit, but that's really just a half-assed guess. Anything between "next year" and "never" would be a reasonable guess too...
... and y'know, Python 3 should be on your radar, if not necessarily what you use right now. It's better than Python 2 in every way (except for adoption, and that's changing). 3.3 in particular has a ton of really great new stuff (futures! working namespace packages! yield from!) that you'll wonder how you lived without.
This! I'm so glad to hear this straight from one of the maintainers. Python 3.3 is the first version of Python 3 that has made me stop and say, "Wow, this really makes my life easier/better". The sooner we as an ecosystem get moving on, the better.
I'm glad to hear it. Just as additional feedback: Python 2 is a "no show" in our future plans. We got over the upgrade hurdle years ago and have no intention of walking back into it. Anything stuck in Python legacy-land may as well be COBOL as far as we're concerned. We prefer Python 3 when it's available, but we use languages other than Python when there is no Python 3 solution.
They've been gradually removing support for older Python 2.x with each release, so it's likely the same will happen with all of Python 2 in the coming years.
But that's probably a good thing. Python needs to keep improving, and Python 3 is just flat out a better language.
Isn't it still significantly slower? Even though it probably doesn't matter most of the time, it would helpful for all 3's items to be in the "better column."
The only significant slowness I've heard of was due to the I/O library, but it was only in 3.0, so has since been fixed. Or were you referring to something else?
As an author of many Django sites and third party components/libraries -- Django was one of our major blockers to even attempt Py3 ports. Now that it's under way, we'll get started, too. The fact that Django is using a single code base (with six) is a huge bonus, so we'll be trying to do that, too.
Considering minor releases happen every 8 months or so (i.e., Django 1.6 will be released latter half of this year), I'm thinking that'll be enough time to work out the kinks for running Django on Python 3.
I do want to point out that it was only last year people used to say that Django was _the_ thing holding everyone going from Python 2 -> Python 3. And now Django has made the move, -- others (Flask, etc.) have not.
Django 1.6 wouldn't be a minor release, 1.x are major versions.
You're more likely to see an alpha release of 1.6 in 8 months, the final released versions of Django have a roughly annual release schedule:
* Django 1.4 came out March 23, 2012
* Django 1.3 came out March 23, 2011
* Django 1.2 came out May 17, 2010
* Django 1.1 came out July 29, 2009
* Django 1.0 released September 3, 2008
Update: Didn't read the part of Jacob Kaplan-Moss' response above where he says 1.6 could be coming in "6-9 months" and as in as little as 3 months. To which I'd say "Wow"
As a Django user, I've always understood Django 1.x to follow the Apple convention with OS X numbering. To the credit of the core team, every minor release has felt like a major improvement to me.
Many projects roughly follow 'semantic versioning'. You change the first number for a release that breaks backwards compatibility, the second number for a feature release, and the third number for a bugfix release.
if by full you mean the whole codebase in python 3 without python 2.7 support, I guess no sooner than around 1.7 considering the deprecation scheme. currently all core code has to support both https://groups.google.com/forum/#!searchin/django-developers...
I would be very surprised if they deprecate python 2.7 in Django 1.7. More likely to happend when django hit 2.0. It's going to take a while until all the packages you might need for a project supports py3k.
yeah, maybe. 1.4 set minimum 2.5, 1.5 set 2.6, 1.6 will (probably) be 2.7 only. 1.7 could either stick with 2.7 and 2.0 be a py3 milestone, or it could drop 2.x and provide a py3-only codebase for developing 2.0. gotta check all the talks and announcements, I don't remember if it was decided yet.
>until all the packages you might need for a project supports py3k
I don't see it as a problem. most of them don't support py3 because django was py2.x. there is still at least a year or year and half to 1.7, it's a lot of time.
I think the point is they don't know yet. 1.5 is intended to get the early version in front of a wide audience, shake out the issues, and then they can make a call on timeframe.
I hope folks don't mind this rather off-topic question here. Is there a JavaScript-based equivalent to Django or Rails? My (limited) understanding is that node.js, Meteor et al are rather different beasts.
Looking at the wall of (f|s)ame, there's still some vital projects without py3 support: south, fabric, mysql-python. Don't see myself developing without those.
On the upside, MySQL seems to have restarted work on Connector/Python which both claims to be Python 3 compatible and is pure Python (i.e. doesn't simply wrap the binary MySQL client library).
I'm looking forward to the swappable User model feature. Has anyone seen or heard of a site that has looked at migrating from a profile approach to a full in swapped User model? What does that migration look like and how painful was it?
1) Create the new User model, and create a schema migration for it.
2) Create a data migration to copy every piece of data you have in your users and profiles over to the new User model.
3) Add ForeignKeys to all your models that reference either the old User model or the Profile.
4) Add a data migration to copy every reference to the old User/Profile from every other model to the new FKs, to point to the corresponding NewUser model.
5) Remove the old FKs with a schema migration.
6) Rename all the new FKs to the old names, create a schema migration, go into it and turn all the delete/creates into column updates.
7) Revert your code to your last commit because you noticed you screwed something up and you can't reverse it now.
God, I was so fed up with django.contrib.auth.models.User, not being able to ignore Username was probably the most insane part, I always felt email was a better choice than Username. I along with a bunch of people I know are looking forward to swappable User model, far saner than the round-about approaches I was using.
Very much agree with this. Websites rarely require users to choose a unique username nowadays (email is enough) and it's been a pain hacking Django to work like that, since many email addresses won't fit in the username field.
In fact I always hate it when application frameworks make arbitrary decisions at the schema level on how long usernames, real names, emails, street addresses, etc. can be. I always use varchar(254) myself. (Unless using a schemaless db like Mongo where this is not even an issue.)
It's not terribly straight forward to do this, depending on which apps you may use. E.g. django-registration or even django.contrib.admin. Username is hard coded in many places. It will get there, but apps have some work to do.
I've been using Django 1.5 for about a month for a couple side projects and it's been working great. A couple quirks with third-party modules (mostly related to the change in the default {% url %} template tag syntax). Anyway, awesome work by the Django team here!
Just tried out StreamingHttpResponse and it's looking great. The User model should work well w/ the MongoEngine project (for MongoDB and Django), I'll look at upgrading it to support that.
I also like that some effort has been made to update the tutorial, when I started back in 1.2 I recall the tutorial to be quite confusing and didn't know where to go after I finished it.
Thanks all involved.