

Django 1.6 released - philippbosch
https://www.djangoproject.com/download/

======
jroseattle
Django is one of my favorite open-source projects. I owe the project a lot.

Years ago, when I was a Microsoft-only shill (yeah, I'll say it), I knew how
to build almost anything as long as something from Microsoft was under the
covers. I was proud of my abilities, and in spite of the anti-MS crowd, I
stood up for my platform and was a good developer.

In 2006, I had a short two-week break from my startup job, and my wife & kids
were traveling to their grandparents' house at the same time. I had 336
consecutive hours to spend as I wanted, something I hadn't been able to do in
many years. I decided I wanted to work on a little side project, something I
could complete within those two weeks.

I made a decision to break out of my comfort zone. I knew a little about
Linux, nothing about Apache, zero about Python, and had never worked with
Mysql. I came up with an idea for a simple little CRUD application, just a
utility site. It was something I knew I could build in maybe two or three days
using Microsoft tools.

So, I searched around and found Django. I downloaded v0.9x (it was sometime in
the summer, can't recall what it was specifically. I know it was pre-v1.)

And I started from the beginning, purely a newb. It was a position I wasn't
accustomed to, so I immediately felt a lack of boundaries and sense of
control. But the Django documentation was really good, and I soon gained an
understanding of everything I needed to learn -- Python, running Apache,
configuring Django, wiring up Mysql. I stayed focused and in one week, I had
written my ridiculously simple CRUD app.

But the value I got out of it was how well the project pulled me in to
becoming productive on a platform that I'd never used. Not only that, there
was the help in the discussion groups from the community. It was a lot of fun,
and I could recognize myself becoming a better developer.

The biggest realization came when I compared my Django project to an
equivalent built on Microsoft tools. It wasn't a comparison of one-week vs.
two-days, but rather one-week _coming from square 1_. All this led me to
rethink my thoughts around my Microsoft background. I didn't become a convert
per se, but it made me realize there are so many other ways of solving
problems and other systems on which to build applications. And, after feeling
productive, it made it easier for me to explore other (non-Microsoft)
technologies. The feeling of being productive in multiple environments was so
empowering.

I'm not sentimental about software, but the Django project is kind of that kid
who can do no wrong in my eyes, due to my formative experience with it.

~~~
EnderMB
I'm quite interested in your experiences with Django, as I'm somewhat in the
same boat. I'm a .NET developer, and while I love C#, am a fan of strongly-
typed languages, and am quite fond of the .NET framework I have a soft spot
for Python and especially Django.

Similarly, I had a few days and decided to go out of my comfort zone. A few
days later I had written a blog script and had modified it to work with Google
App Engine.

Do you use Python/Django in a professional setting now? If so, how did you
find the full-time conversion?

~~~
jroseattle
You're in the _exact_ same spot I was. C# developer, completely enthralled
with strongly-typed languages and OO development.

I definitely use Python professionally (and some Django, but that's not the
critical stuff.) It's not the only thing I do, but it's another arrow in my
quiver. It's really useful for generating applications that need to do a lot
of stuff, but benefit from brevity in code. Django is actually more
responsible for me learning Python and how to use it responsibly in a
production environment. I knew how to write services in C# and Java that
wouldn't be an administrative nightmare or cause pagers to go off at odd
hours, so I needed to learn that with Python (turns out, it's not hard.)

As always, your mileage may vary. Nonetheless, lean toward finding a use for
it in your operation, if only for experience. It's super practical, and to
minimize transitional familiarity, go with IronPython. Works with all the VS
IDEs.

~~~
EnderMB
One of my big reasons for wanting to pick up Python was to get me out of
developing on Windows. As much as people love to tout Mono, it's simply not
desirable for any .NET shop.

My biggest worry was if I was offered a job at a great company, how I would be
able to adapt not to the language, but going from an entirely different
platform, one that I hadn't used in anger since uni. Learning a language
shouldn't be a problem, but as I've found out, most of my issues aren't in
using the language itself, but adjusting to the Unix workflow.

Also, my big worry is being the "Windows guy" at an office. I doubt I'm the
first C# developer to be laughed at because I develop on Windows, even if it's
by (in my opinion) fairly crappy developers. Deep down, I reckon a lot of devs
look down on people that have the audacity to call themselves developers when
they don't build on Linux.

So, I guess my next two questions are:

1\. Did you notice a decrease in "professional level" when you moved from C#
to Python. I'm a mid-weight developer, probably not too far off from being a
senior developer. With very limited Python experience I doubt I'd be able to
just jump over to being a mid-level developer, and to be honest I wouldn't
want to drop in salary by too much just so I can use a different language.

2\. How easy was it to land a job writing Python if you've not come with
"previous professional experience"? I've written a bit of Python, simply to
script some things on a Windows server. I've got my own scripts, but nothing
in an actual job. I reckon I could pick it up (Python/Django), along with a
good dev workflow in Linux, within a few months, but I can see employers being
skeptical to hire a C# dev if another Python dev wants the job.

~~~
jroseattle
Actually, I find a lot of developers who don't care for Windows who very much
like C#.

To your questions:

1) Professional level decrease? Not hardly. If anything, I found strong
professionalism in Python. "Pythonistas" are huge in principles such as DRY,
which isn't about something terribly complex but rather keeping things simple
and clean. It's about being organizationally effective and not coding one's
self into a corner. The fact that the language seems so easy to work with
shouldn't give the impression of it being simplistic.

2) I didn't land a job writing Python, it's just a tool to get things done.
From a career standpoint, I don't want to be known as a
{language/platform/thing} guy, I simply want to be known as an engineer.
Tools, languages, platforms, services, etc. will come and go. As long as I
recognize how to use those in combination to get things done efficiently, I'm
doing my job.

------
ubernostrum
Looks like somebody jumped the gun when they saw the commits and uploads
happening; the official release announcement went up only a few minutes ago,
and is here:

[https://www.djangoproject.com/weblog/2013/nov/06/django-16-r...](https://www.djangoproject.com/weblog/2013/nov/06/django-16-released/)

The release notes are here:

[https://docs.djangoproject.com/en/1.6/releases/1.6/](https://docs.djangoproject.com/en/1.6/releases/1.6/)

Also: if you downloaded the package in the period between the parent link
going up, and now, you might want to grab it again. The first roll of the 1.6
package (which wasn't announced, so we could do final checks first) failed to
update our trove classifier, so the package was regenerated, which changed its
signature and checksums.

~~~
illumen
Seems like a new release should be done? Isn't that what RC and pre releases
are for?

Was the release uploaded to pypi or a download page? If so, that's released
IMHO. eg, debian, various news outlets, and others auto scan download pages
for new releases.

~~~
ubernostrum
Well, what we do is generate everything, then share it privately and quickly
amongst the core team for final review before flipping switches and making
things public. One actually important part of this is verifying things like
"the package I download from what will become the public release URL has
checksums that match what's in the checksum file", so it does have to actually
go up on our server for that.

And if we catch a minor packaging error at this point, it's easy enough to fix
on the spot without having to do an entire new release.

Except in this case somebody got really eager, saw the release process
starting, and posted a link to our downloads page (and I'm not entirely
certain if it would have been possible to get the incorrect package from it),
rather than waiting for and linking to the release announcement once we'd
vetted and made everything public.

~~~
philippbosch
That "somebody" would be me then. Sorry for any inconvenience this may have
caused. I saw "Latest Release: 1.6" on the djangoproject.com home page,
checked if it was on PyPI already (it was), did a "pip install Django" and got
1.6. These together to me seemed to be a pretty good sign that 1.6 was
released.

Will wait for the official release announcement next time. Sorry again.

~~~
ubernostrum
Next time around we'll probably do more to hide things up until the
announcement (though of course we can't hide the commits on github, and the
download URLs are predictable, so someone who sees the commits will be able to
figure out where the release is going to live).

------
EliAndrewC
The release notes can be found at
[https://docs.djangoproject.com/en/1.6/releases/1.6/](https://docs.djangoproject.com/en/1.6/releases/1.6/)

Personally, I'm happy that Python 3 is now officially supported, though in
practice I haven't had an issues with using Django 1.5 with Python 3.

~~~
speg
How is library support? I didn't have any issues with django 1.5 itself, but
many of my favorite libraries weren't ready yet.

~~~
pydanny
Django Packages lists 160 apps that work with Python 3. See
[https://www.djangopackages.com/python3/](https://www.djangopackages.com/python3/)

From personal experience, most of the critical ones are compatible.

~~~
kot-behemoth
Well, apart from Fabric.

~~~
jacobian
You may want to check out Invoke
([https://github.com/pyinvoke/invoke);](https://github.com/pyinvoke/invoke\);)
it's the successor to Fabric, and it's Python 3 compatible.

~~~
twsted
For what I can see, Invoke is just a revamped version of Fabric’s task running
components. Fabric 2.0 will "leverage Invoke for task running, leaving Fabric
itself much more library oriented".

------
fletchowns
The dedication to Malcolm Tredinnick was a very nice thing for the Django team
to do. I didn't know of Malcolm or his passing before reading the release
notes, but he seemed like a wonderful person who will be missed by many. Very
sad that somebody like that is no longer with us. Reading his tweets I get the
sense he was a really cool guy.

Really nice piece about Malcolm from his former boss:
[https://plus.google.com/+errazudinishak/posts/6j6iAMhNfnb](https://plus.google.com/+errazudinishak/posts/6j6iAMhNfnb)

Congrats to the Django team on releasing 1.6, I'm looking forward to upgrading
soon!

------
jtchang
One of the reasons I like Django so much is because of the community. This
might seem rather meta but the comments in this thread are generally positive.
Most Django users I know are well aware of its limitations and don't try to
sugarcoat it if Django is not the right tool for the job. But overall I've
found the community (and that of Python) pretty receptive.

~~~
lowkeykiwi
What jobs is Django the right tool for?

------
craigkerstiens
The persistent connections that now exist within Django should give a quite
but great performance boost for the vast majority of Django applications,
which are not already running a connection pooler
([http://www.craigkerstiens.com/2013/03/07/Fixing-django-db-
co...](http://www.craigkerstiens.com/2013/03/07/Fixing-django-db-
connections/)). This alone can be reason enough to upgrade in addition to all
the other improvements.

------
d0m
For those who works with designers or html people who don't use the command
line, how do you collaborate with them with Django?

For me it's a perpetual issue to get them up and running, commit/push with
git, etc etc. Is there an easier solution? Basically, I'd like them to get
started and be able to tweak the templates and css as effortless as possible.

It's kind of very hard to have people working directly in templates/css and
others updating html/css and them diff the changes, integrate them, etc..

~~~
phpnode
I don't use django, but one of the easiest ways to get designers and non
technical folks working directly on projects is to run virtual machines with
vagrant[0] and automate everything as much as possible.

[0] [http://vagrantup.com/](http://vagrantup.com/)

~~~
kkwok
As someone with no experience with this, any resources you'd recommend on how
to set this up?

~~~
FilterJoe
[http://gettingstartedwithdjango.com/](http://gettingstartedwithdjango.com/)

Doing the first 2 lessons will not only get your a vagrant powered VM up and
running, it will also give you a good feel for normal use. And you'll also be
learning Django.

------
euroclydon
If you were starting a new project today, would you use development version
1.7 in order to get Django Migrations instead of using South?

~~~
wiremine
I would recommend using 1.6 and South for now. 1.7 is at least nine months
away, and who knows where the API will go in that time. You're probably better
off developing a stable version of your project using 1.6/South, and then
refactoring when 1.7 lands.

------
andybak
Yay. Major usability wart fixed: "ModelAdmin now preserves filters on the list
view after creating, editing or deleting an object."

~~~
paganel
I was always opening an object link in a new tab and then going back and
hitting refresh in the main tab with the admin listing. Guess I won't have to
do that anymore.

------
magnusgraviti
1.7 release will be very interesting. Instead of South there will be
migrations support. At DjangoCon EU Andrew Godwin told about his vision of it.
i.e. if you have 200 migrations you'll be able to merge them into 1.

Form fields will get extended support like input[type="email"]

Django comments are now deprecated.

Congratulations to everyone using Django!

------
lunchbox
Dumb question: What does it mean that autocommit is now turned on? I no longer
have to call mymodel.save()?

[https://docs.djangoproject.com/en/dev/releases/1.6/#improved...](https://docs.djangoproject.com/en/dev/releases/1.6/#improved-
transaction-management)

------
daGrevis
It's a small change yet I'm really happy with it.

> BooleanField no longer defaults to False

It caused quite a few headaches. Boolean can't have default.

~~~
mhurron
> Boolean can't have default.

I don't see the problem.

~~~
codygman
__Warning: default was False previously so this example is backwards __

Think about this code:

    
    
        class Missile(models.Model):
            # we can only attack short countries
            target = models.CharField(max_length=7)
            should_launch = models.BooleanField()
            
            def launch(self):
                """
                pass launches the missile
                """
                pass
    

You recently added a new missile: # add new missile in case we have to attack
Merica # it won't be launched until we set should_launch to True
Missile.objects.create(target="Merica")

Then you have a view:

    
    
        /missile/launch_missiles
    

with the code:

    
    
        for missile in Missile.objects.filter(should_launch=True):
            missile.launch()
    
    

You'll have the unexpected behavior of launching that missile you just added.
With the new behavior your missile wouldn't be launched until you told it to.
Basically this update has everything to do with the missile above failing this
conditional:

    
    
        missile.should_launch is True
    

Since 'None is not True and None is not False', it is a sensible default for
Booleans.

~~~
mhurron
Two problems here:

One not only is the example backwards, but given the previous behavior, the
correct thing would have occurred. This is a complete nitpick but whatever.

More importantly, this shows a lack of understanding about the framework being
used, not an issue with the framework. The example has a programmer basically
assuming the default is False when it was True, or more correctly that the
default was not True. That is an issue with the programmer (and testing) not
with the framework, unless it was undocumented. Django is documented quite
well. The programmer here assumed something worked one way that was clearly
documented to work the other.

Booleans defaulting to False is not unusual, but not universal either. Django
has chosen to go the path of explicitness, which is a fine choice to make, as
opposed to defaulting to False which is often considered to be a safe choice.
I don't see a problem with not assigning a default, but I also don't see a
problem with the default being False.

Defaulting to NULL could cause other problems, at least for the programmer
above who didn't read documentation and worked on assumption.

~~~
daGrevis
Things should make sense without reading documentation (I'm not saying that
you don't need to read it) and boolean having a default doesn't make any
sense. Argument about it having a default value in other frameworks isn't a
real argument either.

------
andybak
django-vanilla-views in core for 1.7 please. ;-)

~~~
snoonan
Thirded! This is a better implementation for a framework. CBGV as-is would be
better as an add-on app.

This is a great example why framework projects could benefit from being a bit
more democratic. Most people seem to be pulling their hair out, telling you
something is too complicated to effectively use. The response: It's worth it
once you learn. The complexity cost is worth it. Trust us. Read the docs (of
course), use this 3rd party site (ok...), read the code. (so I can write a
non-trivial view!?). If you are still giving that answer years later, you have
to be open to the fact that that your users might be on to something.

Often when you hear someone say they're using CBGV on a large project, you can
almost sense the pause for applause.

~~~
ubernostrum
I use the class-based generic views in a couple of projects. My personal
opinion is that the official documentation still needs work, because people
end up in the API reference tree looking for the examples and explanations.

And that is not a happy place to end up when you're just starting out with
them, since in there you're seeing the whole inheritance/mixin layout
structure, which is what leads to the belief that it's too complicated to use.

Which... no, class-based generics are pretty darned easy. Here are the views
for my blog app, for example:

[https://github.com/ubernostrum/blog/blob/master/blog/views.p...](https://github.com/ubernostrum/blog/blob/master/blog/views.py)

It'd be nice to cut down the use of super(), but that's about the only issue I
have with it. All of the simpler-CBV implementations I've seen make a few too
many assumptions for my personal taste, or otherwise cut down on flexibility
in favor of simplifying the inheritance diagram, which I don't agree with as a
goal in itself.

~~~
tomchristie
Worth noting that it's an explicit aim of vanilla views to _exactly_ replicate
the functionality of Django's GCBVs.

For the docs: "If you believe you've found some behaviour in Django's generic
class-based views that can't also be trivially achieved in django-vanilla-
views, then please open a ticket, and we'll treat it as a bug."

You shouldn't be losing any flexibility by using it instead of using Django's
existing GCBV implementation.

------
anderspetersson
Thanks for another great release! Also big thumbs up for a shorter release
cycle than usual.

------
eliben
Is it only me or it's not easy to discover what's new / changed / release
notes from this page? Is there a secret link I'm missing?

~~~
ubernostrum
The person who posted this apparently saw the version-bump commits and jumped
the gun, posting a link to just our download page before we even had the
release announcement out.

The announcement and release notes both have the information you want:

[https://www.djangoproject.com/weblog/2013/nov/06/django-16-r...](https://www.djangoproject.com/weblog/2013/nov/06/django-16-released/)

[https://docs.djangoproject.com/en/1.6/releases/1.6/](https://docs.djangoproject.com/en/1.6/releases/1.6/)

------
anan0s
are there any particular performance improvements over the previous versions ?

I was thinking basically of transaction management, especially the autocommit
behavior.

I browsed through the docs and saw that the default python database API
requires autocommit to be turned off... but then again django overrides this
behavior.

any comments on this ? (or am I completely lost ?)...

~~~
masklinn
> Improved transaction management¶

> Django’s transaction management was overhauled. Database-level autocommit is
> now turned on by default. This makes transaction handling more explicit and
> should improve performance. The existing APIs were deprecated, and new APIs
> were introduced, as described in the transaction management docs.

> Please review carefully the list of known backwards-incompatibilities to
> determine if you need to make changes in your code.

> Persistent database connections¶

> Django now supports reusing the same database connection for several
> requests. This avoids the overhead of re-establishing a connection at the
> beginning of each request. For backwards compatibility, this feature is
> disabled by default. See Persistent connections for details.

~~~
mbell
It's hard to imagine using an ORM for anything high volume that just got
around to adding (still very limited) connection pooling. I'd tend to think
anyone overly concerned with performance would use SQLAlchemy, if they use any
ORM at all.

~~~
mhurron
> I'd tend to think anyone overly concerned with performance would use
> SQLAlchemy, if they use any ORM at all.

Or they did connection pooling outside the development framework.

~~~
collyw
right tool for the job. Djangoś ORM is great for simple stuff. And it works
with the admin interface (which is worth a lot). If You need something complex
enough, use raw SQL.

The admin was too much to give up to swap the ORM to SQLAlchemy for me.

------
smaili
It's amazing to see how far along Django has come. Anyone remember when Django
first came out? Good times :)

~~~
paganel
Yeap, it was early 2006 for me, in the pre- 0.96 days. I came to Django from
Zope, that seems so long ago.

------
Walkman
A lot of small but very nice improvements, yay!
[https://docs.djangoproject.com/en/1.6/releases/1.6/#minor-
fe...](https://docs.djangoproject.com/en/1.6/releases/1.6/#minor-features)

------
adamlj
I really need this update! Other than the good stuff already mentioned, The
DecimalField finally supports a comma as the separator.

------
Siecje
[https://dashboard.djangoproject.com/](https://dashboard.djangoproject.com/)

------
mukgupta
No database migrations in 1.6 .Disappointed

