Django 1.5 release candidate available
djangoproject.com
djangoproject.com
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.
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.
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.
https://docs.djangoproject.com/en/dev/ref/templates/builtins...
https://www.djangoproject.com/weblog/2012/aug/19/experimenta...
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.
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"
http://www.tornadoweb.org/documentation/releases/v2.0.0.html
>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.
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 :)
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.
But that's probably a good thing. Python needs to keep improving, and Python 3 is just flat out a better language.
... 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.
But, it'll be worth it.
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.)
https://bitbucket.org/ubernostrum/django-registration/src/27...
Looks like that's the only place that enforces duplicate usernames.
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.
8) Done.
{% verbatim %} template tag