
Django 1.5 released - Lightning
https://www.djangoproject.com/weblog/2013/feb/26/15/
======
bryanh
Wonderful! I just want to extend a heartfelt "thank you" to all the guys and
gals contributing to Django.

Django is still a cornerstone of our startup and we're way past the point
where folks have traditionally said "Django starts to constraint you". We've
found that to be untrue. We love the templating, the ORM and all the built-in
tools (not to mention 100s of libraries that get you an 80% finished feature
in 5% of the time).

I hope to meet a lot of you at Pycon, I'd be happy to buy you a beer. I'll be
wearing the bright orange Zapier shirt, you can't miss me. :-)

~~~
cookiecaper
I wonder if perhaps your people just don't have much exposure, because the
templating in Django is awful compared to Mako/Jinja2, the ORM in Django is
awful compared SQLAlchemy, and most of the useful features of Django are
easily available in Pyramid or Flask, yet these systems are unobtrusive and
simple. Django has a monstrous "middleware" piece and a bunch of other cruft
that is really just bothersome dead weight. It's not that there's no use for
it, it's just that similar things are accomplished in much more concise, fast
ways in other frameworks.

Not to hate on Django, jacobian, or the LJ-World, I appreciate the effort put
into the system. But I don't think it really has much to offer in present-day
for people developing new, serious platforms. I feel the same way about most
other "full-fledged" MVC frameworks, because they all seem to far exceed what
ought to be the logical bounds of their influence. In many cases you feel like
you're writing Django, Cake, or Rails and not writing the actual language
based on, because these frameworks mandate so much and require special
integration to do much of anything. In something like Pyramid, you write
Python, and Pyramid provides the pieces that make it easy to bundle together
and publish as a website.

I've had positive experiences with Sinatra, too. "Microframeworks" and close
cousins like Pyramid are really much more appropriate dev platforms, imo:
modular, unpretentious, exist simply to help you get your program onto the web
in a fast, concise, and simple way, without attempting to inject a rewrite of
the standard lib or force you to conform to their unique flavor of MVC, their
crappy ORM, etc.

~~~
bryanh
One might easily take offense at your comment:

> perhaps your people just don't have much exposure > new, serious platforms

Both could have been omitted and your points would still have been valid.

Anyways, I'm not advocating Django as "the one true way", just stating that is
hasn't hindered us in the least. :shrugs:

~~~
cookiecaper
I don't intend offense. I'm just suggesting an explanation for why you may
feel Django is not problematic. When all you have is a hammer, everything
looks like a nail. I've met many-a-programmer fairly early in their careers
who praise things like Cake, Rails, or Django, but in my experience at least,
as they mature, they prefer less invasive solutions.

~~~
mtrimpe
In a few years you'll probably get to the point where you don't prefer less
invasive solutions but will pick the right tool for the job.

If you know you'll be iterating rapidly but will stay within the confines of
'standard CRUDdy app' then e.g. Django, RoR, Spring Roo e.a. will be probably
be good to you. If you expect to go beyond those confines you'll be burnt.

In general it's about finding what I like to call the 'grain of the tool' and
pick the ones where you can go with the grain.

~~~
cookiecaper
I prefer less invasive solutions because they are generally the right tool for
the job for serious web platforms, which is the niche to which I limited my
comments. And for the record, I've been around for some years.

If I just want a basic CRUD app that will basically never exceed the
capabilities of Django's automatic admin interface, then sure, Django will be
fine for that because all I'll have to do is define models and I'll be done. I
can then query the SQL database directly if necessary, or write a separate
application that generates reports on the data.

Most "serious platforms", however, do much more than this. For platforms that
run companies, least-invasion is a good principle, because it allows you to
adapt quickly as changes are necessitated. Django, Rails, et al often world-
break if you try some "funny business". Next-gen frameworks like Flask and
Pyramid have almost no reasonable condition that qualifies as "funny business"
from the framework's perspective, so they're much easier to iterate upon or
pivot from.

~~~
mtrimpe
> serious web platforms, which is the niche to which I limited my comments

That is exactly the kind of grain I was talking about.

If you were running a startup that's focusing on finding product-market-fit
and quickly iterating on the UX to get conversions up and attrition down
Django (or RoR) might be a better fit.

When you start outgrowing Django you can just start splitting off components
and rebuild them in a more 'serious' way.

~~~
cookiecaper
I disagree, because you can iterate just as quickly with Pyramid/Flask,
generally speaking.

------
jimray
Hot dog.

I've been working on a small side project the past week or so using the 1.5 RC
and following along the best practices recommended by 2 Scoops of Django --
<https://django.2scoops.org>

If you haven't already, I highly, highly recommend picking up the 2 Scoops
book. It's got some great, proscriptive advice and is an easy-to-follow
roadmap that helps answer a lot of "what is the right way to do this?" kinds
of questions. Setting up your settings files for multiple environments, using
CBV's, understanding the new User Model features, writing tests, recommended
3rd party tools, securing your setup -- these things are all a lot more clear
to me.

And it's actually really well written, not just a bunch of recipes. Their
explanation of mixins, for instance, is one of the clearest, most concise I've
ever come across. Well worth $12 and a few hours of time to read through it.

~~~
joshschreuder
Thanks for posting about this book, I've been meaning to get into Django for a
while, but I didn't find the official tutorial to be terribly enlightening
beyond the basics. Plus there's a whole heap of non-code related environment
stuff which I want to have best practice for too.

If anyone knows of any other good first-up books / websites (are there any
interactive tutorials Treehouse / Codecademy style?), please let me know.

~~~
jimray
Fair warning: 2 Scoops definitely assumes some familiarity with how Django
works, specifically models, views, templates, and forms. It won't introduce
these concepts to you but will help you use them better.

The official Django Tutorial is still a great starting place for getting your
head wrapped around that stuff --
<https://docs.djangoproject.com/en/dev/intro/tutorial01/>

~~~
joshschreuder
Thanks, I worked through the tutorial, so I know the basics I suppose. But I
got to the end and wanted it to keep going, so I guess this book will come in
handing for learning beyond the official tutorial.

I'm also going to check out <http://gettingstartedwithdjango.com>

~~~
simeonf
If you're interested: I wrote an extended follow-up to the 1.4 tutorial that
is a bit more real-world: using South for migrations, bootstrap templates,
learning to use the forms library, adding popular apps like debug-toolbar and
so on, writing annotation and aggregation queries, etc. See the "courseware"
link at <http://simeonfranklin.com/pro-django-class/>

~~~
joshschreuder
I'll check it out, thanks!

------
awolf
_> Django 1.5 is the first Django release with support for Python 3
(specifically, Python 3.2 and newer)._

That sentence is of course followed by caveats about Python 3 support being
experimental at this stage, but all-in-all I think this is a sign that we are
finally at the tipping point for Python 3 to start gaining mainstream usage.

Thank you Django community for moving the ball forward for everyone.

~~~
jacobian
FYI, the "experimental" thing is a community thing, not really a technical
judgement. Since this is our first Python 3 release, we want to have some
space to make changes between 1.5 and 1.6 that we otherwise would avoid
because of our strong backwards compatibility promise. The "experimental"
label is about giving ourselves that room and not surprising users if there do
have to be changes in the way Py3 support works between 1.5 and 1.6.

Technically, however, it's pretty rock-solid. I'll be launching a site built
on Py3/1.5 is about two weeks, and aside from constantly forgetting to
`print(...)` instead of `print ...` it's been surprisingly smooth sailing.

~~~
SoftwareMaven
Have you found any of the third-party Django extensions to be catching up? I'm
starting a new project and would _love_ to just start with Python3, but there
are a few packages I depend on: South, lxml, pytz, simplejson, requests,
django-compressor, gunicorn, jinja2, twisted, txAMQP, and django-rest-
framework (amongst some other utilities actually used for development).

It would sure be great to have a list of django sub-projects and their Python3
status.

Regardless, even if we start with Python2.7 and bump up to 3.3 in a few
months, this is a _great_ step!

~~~
jacobian
Of your list:

* South doesn't have Py3 support in core, but there's a fork that does and seems to work perfectly: <https://bitbucket.org/aaugustin/south-python3>

* lxml as of v3 seems to have py3 support (I haven't tried it, but looks like it does).

* simplejson is now in the standard library as "json", so yes there.

* requests works, since v0.10 (about a year ago).

* django-compressor is not ported; however, django-pipeline does run on Python 3 and is basically -compressor's successor. It works great.

* gunicorn works on py3 (as does uwsgi and mod_wsgi, btw.)

* jinja2 hasn't been ported yet.

* twisted is actively being ported right now, and has gotten to the point of "kinda working". You can follow along at <http://twistedmatrix.com/trac/milestone/Python-3.x> and <http://twistedmatrix.com/trac/wiki/Plan/Python3>.

* txAMQP probably can't get ported until twisted does.

* django-rest-framework has Python 3 support, I think it's fairly recent, but it works well.

This list is about typical of what I've found doing Django/Py3 work: many
things are ported, a bunch more have good alternatives, and a few things are
still missing.

------
danso
> _Django 1.5 introduces support for a configurable User model. The basic
> Django User model is still around, of course, but now there's first-class
> support for specifying your own model and having Django's auth system make
> use of it._

I guess having it be a special User model is just part of the deal with
Django's good out-of-the-box admin. I don't even remember how the various
Rails plugins (ActiveAdmin, for example) generates the scaffolding needed for
an authenticated user.

~~~
endtime
Not just contrib.admin, but also contrib.auth.

It's very easy to extend the existing user model rather than creating one from
scratch. I had to do some unconventional auth stuff recently and I only
extended auth.User slightly (and also wrote a slightly modified authentication
backend).

~~~
obviouslygreen
This feature was something we'd hoped would be awesome; it's not. Going over
the documentation shows there's some jaw-dropping nastiness you have to go
through to make it work.

It's good that they're providing it, but I think the complexity is going to
turn people off (I know I won't be using it unless it's simplified at some
point in the future). User profiles have always been used for adding data to
User models indirectly, and I think this is probably going to remain the best
way to handle it for most uses.

~~~
jonknee
Can you expand on the "jaw-dropping nastiness you have to go through to make
it work"? Seems pretty straightforward, though I have not tried to actually
use it yet.

[https://docs.djangoproject.com/en/1.5/topics/auth/customizin...](https://docs.djangoproject.com/en/1.5/topics/auth/customizing/#auth-
custom-user)

It appears the database migration is the biggest hurdle, but I don't think
there's a way around that. User profiles require a join and that can be
suboptimal, which is why this is a useful addition. If you weren't running
into problems before it's probably better to not change (though that's usually
the case for working code).

~~~
Jasber
I can't speak for obviouslygreen, but I recently implemented the new User
model and was a bit surprised by all the stuff I had to do myself.

I just wanted to add one field to the user model, but to do that I had to add
100+ lines of code.

I am very happy custom User models are possible now––but for most stuff I'll
probably keep using a UserProfile.

~~~
jarcoal
What field were you adding? Are you aware of
django.contrib.auth.models.AbstractUser?

------
Spiritus
There's a lot of hype around the new configurable User module. But personally
the new verbatim template tag is golden:

[https://docs.djangoproject.com/en/dev/ref/templates/builtins...](https://docs.djangoproject.com/en/dev/ref/templates/builtins/#std:templatetag-
verbatim)

~~~
jonknee
It is, but was an easy addition before. If you needed a configurable user
module before you were up the creek.

------
naiquevin
It's great to see the Django tutorial extended to cover testing[1] and writing
reusable apps[2]. These days there are quite a few Django tutorials out there
covering best practices etc. (which are very good) but I would still recommend
the official Poll app tutorial to any beginner because of it's simplicity.

[1]: <https://docs.djangoproject.com/en/1.5/intro/tutorial05/>

[2]: <https://docs.djangoproject.com/en/1.5/intro/reusable-apps/>

~~~
mkhattab
Unit testing Django applications has been a source of pain for me. Writing
functional or acceptances is ok using Django test client, although many
recommend using WebTest, which is nice but slow if you're going to write
hundreds of them.

~~~
naiquevin
I agree about the slow running time of Django tests although I have found that
using sqlite database backend for tests reduces the time significantly.

------
Lightning
Release notes: <https://docs.djangoproject.com/en/1.5/releases/1.5/>

------
elicox
Sorry for the Off topic, but anybody have a good experience with
Appengine+Google Cloud SQL+Django?? I am thinking as alternative to AWS but I
dont know if it's going to give me so much problems with the integration. Also
a bit worry about the price in comparation with AWS. Anyone experience in both
world?

~~~
mbarlow
I have used both. I would strongly suggest going with AWS.

Reasons:

Local development with Appengine is pretty bad. Good luck debugging and
profiling production issues.

Appengine will make you jump through many hoops that undermine or completely
drop pieces of the Django framework.

Getting data out of Appengine is a huge nightmare and timesink.

If you ever decide to migrate off Appengine you will need to rewrite almost
everything.

~~~
rattray
Was your data in the Appengine Datastore? I believe elicox was asking about
using Google Cloud SQL, which I believe makes data export relatively easy
(Cloud SQL is basically managed MySQL). New Django + Cloud SQL also runs
basically "pure" Django, rather than the hacked-up djangoappengine of the
past, so next to zero code should have to be changed in a move off AppEngine.

I recently made the switch from Datastore/djangoappengine to Cloud SQL, and it
has been a far better experience.

~~~
elicox
Yeah I mean Cloud SQL, few years ago i was trying to replace the ORM of Django
with he own AppEngine Datastore and it's a nightmare.

------
lcc_tn
So, I'll ask the noob question that has previously been getting asked to death
but there's finally new reason to ask once more: someone who's had little to
no prior experience with Django, and still is very much a novice with Python
-- do you suggest they start using Django with Python 3 or 2?

~~~
raverbashing
Python 2

I really, really wanted to say to you Python 3, because:

\- It is better (it fixes some annoyances)

\- Django is working really great with it

But some things (that Django uses, but are not Django) are not working yet.
Things like MySQL adaptors, South, etc

Or maybe go with Python 3 and wait for the issues to be fixed, they probably
will, soon enough

~~~
billforsternz
The Python 2 v 3 conundrum seems to have been going on for an eternity. It
must be putting off new adopters in their droves. For a start, you have to
make an important decision about which flavor to install and how to get
started right at the beginning, with no canonical right answer to the dilemma.
Do the great and the good in the Python community realize how damaging this
is, and how such a thing should never ever be allowed to happen again ?

~~~
pekk
How do you propose this be implemented? By abandoning Python 3, or shooting
the dissenters who still insist on Python 2?

~~~
billforsternz
I have no idea what to do about 2 v 3 now. The grandparent is a genuine
question, and my perspective is as a casual sometime Python user rather than a
serious Python user. I am personally frustrated by the problem every time I'm
tempted to get serious about Python. I'd love to know whether the key Python
people acknowledge the problem in the way I've framed it and whether they have
resolved to avoid something similar happening again in the future once this
issue (finally) works itself out one way or another.

------
djangoguy
I'm super excited about this release but I really, really envy the Russian
Doll-caching through key-based expiration and the Turbolinks of the Rails 4
release. Man I really wish django would package all the JS magic Rails comes
with.

~~~
andybak
Are there any mature 3rd party apps that cover this ground?

~~~
djangoguy
Not that I have found so far.

------
tazzy531
Does anyone know what the status is on the non-rel branch? It's still on 1.3.

What framework do other people using NoSQL data stores use?

~~~
bryanh
It is highly unusual to use NoSQL as the main data store in Django (so much of
the built-in functionality requires relational databases, so you end up net-
negative). Most Django folks augment their relational database with some NoSQL
bits.

We've been big fans of storing core data in Django models, but using things
like key/value stores to store random extra bits that aren't exactly _core_ to
the model. Redis is great for this, or another model as triple store style
GenericRelation if you need to query on it.

I don't imagine the nonrel branch will move again, its such a departure from
core Django. Look into using Flask, as there aren't many "mature" frameworks
that do NoSQL core.

~~~
smnrchrds
What about hstore?

~~~
bryanh
I've _very_ limited knowledge about hstore, but have only heard great things!

------
message
Django 1.5 unchained

~~~
Ensorceled
I _hate_ that movie. I've never seen it but now it's the first page of search
about half the time when I'm googling development issues with the real Django
:-)

~~~
danso
Maybe it's Google Search biasing towards me (or at least my IP address), but
Django, the framework, should be proud that it's keeping the top rank for that
search term despite the buzz around Django, the movie (which, even though I
love QT, was a pretty sloppy movie, IMO).

The real loser is Django Reindhardt, who Adrian Holovaty named the framework
after, and is now bumped off the first page of Google results.

<http://en.wikipedia.org/wiki/Django_(web_framework)#History>

------
lifeisstillgood
Is it just me, or is it simpler to go back to wsgi middleware plain and
simple?

I am getting turned off left right and centre by frameworks - Django and even
Flask just make reasoning about the request/response more difficult.

Maybe I don't know how to use this but ... It would take me three months to
read the new Django docs.

I am not a hater here, just wanting the simple life

~~~
DeepDuh
I get this feeling about Django, but not about Flask. Its codebase is so lean
I can read all the relevant parts in an hour when I want to get back into it.
I don't even need docs for this thing.

However, I understand what you mean about request / response, I don't like how
this is handled in most python frameworks actually, it's usually too much
abstracted away.

The nicest (imperative) environment for asynchronous execution I've seen is
Objective C/Cocoa for some reason. It has a way of showing you all the handles
you might need, but it also makes it fairly obvious when and how these handles
are called. Together with lambda support ('blocks') it's simple but effective.

I think the main difference is enterprise + closed source + well documented
environments vs. opensource + not so well documented environments often
originating from someone's hobby. When it comes to big middleware frameworks I
prefer the first, but small lean stuff such as Flask is just fine to use IMO.

My advice is to not rely too much on the docs when you want to really know
something - take a look at the source, it's all there.

------
mariuz
The django-firebird (fdb driver) is now available for installing via pypi.
Just run: pip install django-firebird <https://pypi.python.org/pypi/django-
firebird> It's developed for django 1.5+

------
csense
What do Python frameworks like Django need to do to start taking market share
from Rails?

~~~
hekker
Increase the price of cpu's and memory.

------
niggler
Slightly OT: How does python2 and python3 usage numbers compare?

~~~
askedrelic
Anecdotal: I wrote a Google Reader API library in Python 2 that I'm working on
porting to Python 3 and it really hasn't been that bad. I had some HTTP
dependancies on urllib/urllib2 but requests (with a py3 compatibility class)
made it easy.

The port was requested by someone looking to build an RSS feed reader or
checker in Sublime Text 3, which using Python 3.3. Things are moving forward.

~~~
speg
Hey, that was me. Glad to hear it :)

~~~
askedrelic
Howdy! I have a branch with all the tests working, just haven't made an
official release yet. Hopefully very soon...

------
wowzer
On the Python 3 subject, I'd be highly interested in seeing if there any
performance wins by switching your Django deployment to Python 3 over
something like Python 2.7.

~~~
tshepang
If you go 3.3:

* If you use decimal module, you will benefit from the serious speed improvements (<http://docs.python.org/dev/whatsnew/3.3#decimal>).

* The memory usage of strings is slightly lower ([http://docs.python.org/3/whatsnew/3.3#performance-and-resour...](http://docs.python.org/3/whatsnew/3.3#performance-and-resource-usage)).

------
AUmrysh
I hope this isn't too difficult to upgrade to from 1.4 Also, I'd like to thank
all of the Django contributors for their excellent work and for making my job
easier!

~~~
kmfrk
Easy to upgrade: hardly. Easy to migrate. weeell ...

#django on FreeNode is pretty good, though.

------
jezi22
Im new in django and i fell in love with it. nice update. :D

------
kmfrk
Looking forward to see if there'll be any SQL query improvements after I play
around with the new User model and improved object fetching.

