
Django 2.0 released - webiad
https://docs.djangoproject.com/en/2.0/releases/2.0/
======
jsmeaton
A good time to remind that Django has met all milestone, bug fix, and security
fix release targets since the introduction of the Django Fellow which can only
be funded with donations.

[https://www.djangoproject.com/fundraising/](https://www.djangoproject.com/fundraising/)

I’d like to encourage everyone that uses Django in a commercial setting to
speak to their company about donating to the DSF to continue getting timely
bug, security, and feature releases.

~~~
bluewalt
Thanks for the reminder. Django made me like web development and find a job
that I really love today. $25 given, it's nothing for this.

------
sirodoht
Respect to the Django team that even after 12 years they have only one major
version shift (which seems to only because of dropping support for Python 2)
and the backwards incompatible changes are minimal.

~~~
bebop
There have been lots of breaking changes along the way. Django is pretty good
at giving developers a heads up of what is deprecated and slated for removal,
but there have been lots of growing pains in the 1.x release cycles.

~~~
jordigh
I really dread upgrading Django. We have a codebase that has been with us
since the 1.3 days and each time there's an upgrade, someone on the team sets
about one month aside to deal with all of the breakage. You could say that
this is our fault for "doing it wrong" but we just wanna get stuff done.
Sometimes the only way to do it that we could figure out was by doing
something that Django later decided we shouldn't have done.

Going to Python 3 is going to be the biggest annoyance yet.

~~~
thecardcheat
That's surprising to me as I have updated a large production Django code-base
on my own for every version from 1.5 to 2.0 and it has never taken me more
than a day, with an equal or lesser (typically lesser) amount of time
dedicated to deprecations when I updated to the previous version. Any blockers
past that point have always been due to slow-to-update third-party libraries.

The Python 3 update took longer and had a longer legacy of surprise breakages,
but I don't ding Django for following the intended life cycle of Python.

~~~
jordigh
> That's surprising to me

I'm surprised you're surprised. Have you seen the size of the breaking changes
documented with each release notes? We typically hit about 10 of these changes
per release, sprinkled all over our code.

[https://docs.djangoproject.com/en/2.0/releases/1.10/#backwar...](https://docs.djangoproject.com/en/2.0/releases/1.10/#backwards-
incompatible-changes-in-1-10)

[https://docs.djangoproject.com/en/2.0/releases/1.9/#backward...](https://docs.djangoproject.com/en/2.0/releases/1.9/#backwards-
incompatible-changes-in-1-9)

[https://docs.djangoproject.com/en/2.0/releases/1.8/#backward...](https://docs.djangoproject.com/en/2.0/releases/1.8/#backwards-
incompatible-changes-in-1-8)

And those are just the intentional breaks. We find a lot of unintentional
breakage too, and sometimes we accidentally use undocumented stuff which of
course also isn't documented when it breaks. Each Django release has added an
average of 32 commits per release for the past four releases just to deal with
the version upgrade.

~~~
collinmanderson
Some things to do that could help everyone (this is what I do):

If documented stuff changes, Please report it (though that likely means
testing against the alpha / beta versions (or just master). Keep Django
honest.

If you find yourself using undocumented features, consider documenting them;
that way they’re held to backward compatibility.

Also, follow the development of Django and comment on the intentional breaks
if you think they’re not worth changing.

Disclaimer: Core dev now, though I had this attitude before that too.

~~~
jordigh
> Also, follow the development of Django and comment on the intentional breaks
> if you think they’re not worth changing.

I really don't want to be sucked into Django's drama:

[https://us.pycon.org/2015/schedule/presentation/381/](https://us.pycon.org/2015/schedule/presentation/381/)

I've encountered very little sympathy from Django developers. Everyone seems
to have just accepted that it breaks often and it's totally my fault for not
keeping up with the breaking changes. Everyone seems to think that Django
breaking compatibility all over the place is good, proper, acceptable, and
inevitable. Nothing is sacred, anything can break, and make sure you go
through that list each release to see what you have to change in your code.

This makes me sad and frustrated.

[http://stevelosh.com/blog/2012/04/volatile-
software/](http://stevelosh.com/blog/2012/04/volatile-software/)

~~~
collinmanderson
I hear you, and I've heard others say the same.

I think it would help if you bring it up on the Django-developers mailing
list, if you haven't yet. I think that would help raise awareness about the
issue, and I hope it would lead to some policy changes.

------
sgt
This is probably your best bet if you're just going to build a nice CRUD
frontend for a business app, possibly with an API (via DRF). I am doing this
right now on a project as it's the shortest path to a win. The API however is
written in Java 8 / vertx.

~~~
whalesalad
I’d posit that a simple crud app would take an order of magnitude less time
with Rails. I’ve been a Django developer since 0.96 and have built dozens of
apps with it. After transitioning to Rails, it’s hard to justify the use
unless you’re in an evironment that absolutely must use Python.

~~~
_arvin
Python - Django

Ruby - Rails

PHP - Laravel

all nice choices

~~~
blunte
And if you don't mind the learning curve (which will make you a better
thinker!), I would add

Elixir - Phoenix

I wish there was a complete Clojure - ???

~~~
guftagu
I'd wait for the ecosystem to mature before building a business app with
Phoenix. You never know what taken for granted library is missing in Elixir,
and it's going to be damn hard to hire a developer experienced with Phoenix.
Everyone on your team will be slow and will be making a steady stream of
mistakes as they learn the framework

~~~
blunte
I think Phoenix (and Elixir) is mature enough already to use in production.
I've made pretty good, bordering on oracle-like :) predictions about
directions in technology over more years than I care to think about; so I'm
confident that Phoenix is only going to grow in use and positive attention.

It will be the logical successor to Rails. It already is.

That said, I use a good mix of Elixir+Phoenix and old-school cron launched
Python utility scripts, and that works nicely. Anything that's difficult
(probably because I am still a newb) in Elixir I can easily do out of band
with a Python script.

But your point about difficult to hire experienced people is the reason for my
reply. This is the mentality that is ruining IT and development. Yes, having
someone with hands on experience in all of your tools is nice - a rare luxury
in fact. But it's really not necessary. I would be quite happy to have someone
that has willingly built something in Rails, Django, and Nodejs with an "Oh I
can learn that" attitude. Especially if you come from a modern MVC framework,
Phoenix itself is easy. Elixir is the part that requires some real effort,
imo.

------
skshetry
As a beginner/intermediate level myself, I think new routing syntax, which is
similar to flask is itself a major feature of the django 2.0. This really
simplifies the url routing than the regex(which is lot powerful though). For
simple projects of mine, it may well cover 60-80% of my needs, maybe more.

~~~
omegote
Indeed. The somehow clunky syntax for named groups in python re was (in my
opinion) a big drawback with old style routing. I hope this new style gains
traction.

------
tschellenbach
Nice this release will be the final push that tips over the balance towards
Python 3. With Django taking the lead I think more projects will drop Python 2
support. Well it sure took a while, but glad the ecosystem is standardizing
around 1 language again.

~~~
jefurii
Time for Python 4!

~~~
y4mi
Guido was imo pretty clear that there won't be backward incompatible changes
for python 4, if at all

[https://twitter.com/gvanrossum/status/501172370690699265?lan...](https://twitter.com/gvanrossum/status/501172370690699265?lang=en)

------
lima
Notable feature: no Python 2 support!

~~~
PunchTornado
yes and it is indeed a feature. death to python2. I would pay money to that.

~~~
mcny
just yesterday someone at cuny sps told me a professor is teaching them flask
using python 2.6...

sigh

~~~
maxerickson
It'd likely be better to use Python 3, but the actual differences in syntax
are pretty small, it's big Python 2 code bases that present a problem, not the
switch over to using Python 3 syntax and names for new code.

~~~
rkuykendall-com
Yeah, for the types of programs intro students write, it's basically "Okay,
now add parens to your prints." And if they're running Python 2.7 they might
be doing that already.

------
bluewalt
No Python 2 support, good thing. I understood that the Django codebase is
lighter thanks to this, but I'm asking myself if it has any implication for
the developper? (I was already using Python 3.6)

My guess: \- The Django codesource is easier to read \- Maybe error messages
are cleaner? (just a supposition.. I don't know)

~~~
collinmanderson
The documentation is a little cleaner too, with fewer “except on Python 2,
it’s like this..”

Also, this will eventually allow type hinting in the future.

------
y04nn
Does anybody know if there is better support for WebSockets? If I remember
right, with Django(1) it is not easy to do it. And is it possible to use
GraphQL?

~~~
orf
With Django Channels there is great support, with some quite interesting
things you can do. GraphQL can be handled by a third party package, there are
a few out there at the moment.

~~~
trowawee
Seconding this. Channels was actually shockingly easy to implement, maintain,
and expand, even at a small startup with a fairly small and relatively
inexperienced team.

------
BuckRogers
Congrats to the team, this has been a long time coming. No Python2 support
which is unfortunate, my Python3 migration strategy was to move to C# for my
main language instead. No regrets, I like it a lot. I describe it as
industrial strength. Good IDE and granted me a larger job market with Xamarin
for iOS coverage.

For web stuff, I'll probably be using a C# framework, or Wordpress with one of
the JITs. Still, a lot of hard work has gone into Django 2.0 and I'll be
keeping tabs on it, rooting for the team. It's not likely but not barring the
idea of using Django again.

~~~
AzMoo_
Why would you not want to use Python 3?

~~~
jsmeaton
I think choosing to migrate to a completely different language rather than
rewriting in python 3 is a totally valid strategy.

Maybe they’ve switched to c# lately and are using lack of py2 as a trigger to
rewrite. Maybe going after the benefits of a compiled language. Maybe just
wanting to use c# because it’s one of the best languages out there.

There are some python apps out there I’ve contributed to that I’d rather
rewrite in a static type lang rather than migrate to py3. Others I’d move to
py3 no problem.

------
halayli
I really wish they merge Django and DRF.

~~~
gonational
The value of the ecosystem is that each component does its part and each other
component that has interaction with that component reaps the rewards. This
leads to a natural evolution of components in the ecosystem (for instance, DRF
evolved out of the need for better REST support, since projects like Tasty Pie
were lacking thing that the rest of the ecosystem desired).

The idea that anything of value has to be nationalized and assimilated by the
framework is a misguided effort to prevent chaos in the ecosystem, but the end
result of trying to maintain order in an emergent ecosystem is usually
disaster.

~~~
brad0
OT but gonational you asked a couple weeks back to tell my story. I finally
got around to doing it:
[https://news.ycombinator.com/item?id=15762821](https://news.ycombinator.com/item?id=15762821)

------
wilsonfiifi
The new URL routing syntax is one of the most welcome changes for me (i mostly
work with Flask). I just couldn't get myself to work with regex.

------
LeoJiWoo
Wow, I remember being curious about Django a year ago. Now it's at 2.0 ! It
already felt overwhelming then, but now even more so.

I can't wait to check it out more.

On a sidenote, I feel bad for the developers who have to migrate to Django
2.0. Hopefully it's not too much work, I know a codebase review and full
update can't be fun with the business managers and customers at your throat.

~~~
rtpg
The biggest challenge with upgrading Django is making sure all your Django-
related dependencies have fixed things up.

Django only has one paid full-time maintainer to my knowledge (Tim Graham). So
given the team's limited peoplepower Only the last two releases (+LTS
releases) get security updates. This means that Django 1.10 (released 18
months ago) won't get updates, so if you use any new features you're on the
upgrade treadmill.

Django itself is very good about offering clean upgrade paths. Very vocal
about breakage, usually will not introduce breakage unless there's some good
reasons to. Unfortunately third party libraries often take a while to update,
so you can quickly find yourself overwhelmed with figuring out which deps are
safe to upgrade and which aren't.

I try to be a good OSS citizen and send in compatibility fixes for libraries
that fall behind, but maintenance can be hard when you're only really using
about 25% of a library.

I wouldn't be comfortable with sticking to older Django LTS releases (there
was still a lot of obvious improving to be had in the ORM and migrations in
particular), but I think Django 2.0 is in an amazingly good place now.
Sticking to this for a couple years would be fine for a lot of people.

~~~
bluewalt
I can't agree more with you. That's the one and only reason I'll stick to the
1.11 version.

Garanty of compatibility between Django and ALL my external packages is a lot
more valuable that a responsive admin panel and a new syntax for urls.

I would love "important" (yeah it's opiniated) packages move to the official
Django repo (like Channels), to help reduce this risk when migrating. It's
actually surprising how often I can't find the compatibility information of a
Django package.

~~~
rtpg
I've had decent luck for the most part, but it only takes one package.

I would love to see someone start on a combination of `pyup` and some
"maintenance fee" for projects that are found in ones `requirements.txt`.

For a monthly fee you can make sure that at least someone is checking to see
that your Django dependencies are being kept up to date as time moves forward.
The pitch being "get an extra maintenance developer for a fraction of the
cost".

------
OOPMan
At this point in time for me, having worked with a couple of Python web
frameworks, I would recommend Django hands-down every time.

For me it comes down to one simple thing though: Migrations

Django has, far and away, the best migrations system I've used in a Python
framework (although I won't claim to have used them all).

Compared to Alembic it's vastly superior also beats most jerry-rigged
solutions.

------
aprdm
Really nice! Should force more people into python3 as a side effect which is
great since python2 is getting close to its EOL.

Claps for the changelog, it's always a joy to read, I haven't really used
Django in some years but could easily read and see the changes. The new URL
formatting is a very good add-on, was always the thing that annoyed me the
most.

------
goodoldboys
* updates requirements.txt from django==2.0a1 to 2.0 *

Great work! I love Django and look forward to seeing how it continues to
improve.

------
janvdberg
Nice! Coincidentally I had my very first Django experience two weeks ago (and
blogged about it [0]). It struck me as a very solid and clean and lean
framework. But I do think there is somewhat of an entry barrier: you need to
understand quite a few concepts, which if you do, would open up many more
options besides Django. So it's not unique in that regard. However, I had
trouble finding QUICK CRUD app solution i.e. here is my database, please make
some forms for me. And Django: with the builtin admin/user mgmt, did exactly
that.

[0] [https://j11g.com/index.php/2017/11/23/django-
in-10-minutes/](https://j11g.com/index.php/2017/11/23/django-in-10-minutes/)

------
ergo14
Excellent, Django team made a really great job.

------
urda
This is great news! The Django project is such a wonderful project, I've
enjoyed working with it over the years.

------
gojomo
I wish they'd skip-jumped their version to "Django 3.0". That would have
allowed a simpler message about the Python dependency: "Django 3.x requires
Python 3.x".

~~~
collinmanderson
Django 3.0 will be out soon enough (Dec 2019). There's going to be a major
version bump every two years.

~~~
gojomo
Alas, that doesn’t help for presenting a simple version story to low-attention
beginners:

“Django 3.x requires Python 3.x”

“Ah, OK, so to use Python 2.x I should go back to Django 2.x?”

“No, Django 2.x requires Python 3.x. If you want to use Python 2.7 you should
use Django 1.x.”

------
ianamartin
There's a huge amount of talk about Django vs. Other Frameworks here, which is
not surprising. Bottle and Flask come up. Sadly, Pyramid comes up. Rails comes
up.

I think the real crux of the discussion around which framework is best is
really about the relationship between the framework and the language it's
based on.

Let's separate this from the Python world for a second and talk about the
relationship between Objective-C and iOS. Knowing the former doesn't in any
way imply that you know the latter. There's an incredibly host of things you
have to know to write an iOS app in addition to knowing Obj-C. XCode, UIKit,
all the different xKits there are. Which are basically magic, and the APIs
you're referencing are not necessarily written in Obj-C.

It is even possible to be a competent iOS developer and not really know
anything _but_ the framework. No real understanding of Obj-C or Swift is
required, let alone any guiding principle of how programming languages work or
how computers work, or how computer science works.

That's not a dig against people who went to code camp or took an online course
or just read a book. I'm someone who learned about stuff mainly by reading
books. And that worked out fine for the first few years of my career. But
there's a legitimate problem that you run into (I know first hand) about what
you do when the framework breaks down or you encounter something unexpected.

Anyone can learn a framework relatively quickly. What do you do when the
framework fails for some reason?

As someone who learned SQL and Python from the ground up--language-first--I
love that Django exists. It's damn impressive, and only ever gets better. But
I like Flask + SQLAlchemy better, and I like Pyramid + Stored Procedures best.

I would probably have a different attitude if I started with Frameworks first.
And again, that's not a criticism. It's just a different approach. One way to
get things done is to learn the fastest way to get things done, and in many
cases that's quite possibly Django or Rails.

But both of those make me a little nuts when I dig into the internals. Magic
isn't bad by definition. Good magic is when you can invoke a class you don't
have to understand to use well. Bad magic is when you have to understand the
internals of a class to work around it when it fails to meet your needs.

But I think we need some context about this when we talk about which framework
reigns supreme. If you're taking a class and learning to write web apps for
the first time with no other experience at all, Django is the bomb. You can
spend an entire career as a Django developer and do well.

Just like you can spend an entire career as an iOS developer writing apps, do
well, and never actually learn anything about programming. I think this is a
wonderful development in our world of programming because it brings so much
economic opportunity to such a large group of people who wouldn't otherwise
have access to it.

I think it's safe to say that Django is creating jobs for people who wouldn't
otherwise have them, and that's a good thing. My 98-year-old father and WW2
vet is starting to help me with a Django app just as a thing we can do
together. And I don't have to teach him anything at all about anything except
that framework.

It's a brilliant and beautiful framework, and I love it. But to me, it's a
little bit more like iOS or RoR than it is a framework that's really ideal for
people who started with bottom-up rather than top-down development.

I know what I need in a new project, and it isn't going to be all of that. And
I know how to quickly integrate the boilerplate things I will need. That's
what repos and plugins are for.

The short version of my response to everyone talking about different
frameworks is this: we need them all. Bottle and Flask are great; Pyramid is
great; Django is great.

What you are using them for is an important consideration, as is who you plan
to have working on them.

------
myf01d
Serious question: is the famous bug of correctly annotating multiple counts
fixed now?

~~~
lamby
Huh, I'm a big Django user but not heard of this. Link? :)

~~~
brianwawok
Me either

I am guessing it is one of the points where the ORM breaks down.. which the
answer is "use rawSQL"

