
Django 3 - cstuder
https://docs.djangoproject.com/en/3.0/releases/3.0/
======
tabbott
Zulip has been powered by Django since the very early days of its development
with Django 1.4, back in 2012. As a reasonably mature web application with
significant scale, we're at the stage in many companies' development where one
starts to rip out more and more of the web framework to optimize things or
just make them work the way we want. (E.g. while I was at Dropbox in early
2016, we discovered we only had about 600 lines of code left from the original
Pylons framework that actually ran).

One of the things that has been really fantastic about Django is that we're
still happily using it for the vast majority of code in the project, and every
time Django comes out with a new release, I read the changelog and get excited
about several improvements that actually make my life better.

Overall I think we've gotten a ton of value out of Python and Django and would
recommend it to anyone starting a new full-featured web application project
today.

My only frustration with this release announcement is dropping Python 3.5
support now. Because Python 3.5 is not EOL and used in LTS OS releases that
have vendor support through 2021, this forces us to choose between our policy
of supporting vendor OS releases until they reach EOL, not upgrading to Django
3 for the next year or more, or shipping our own Python on Ubuntu Xenial.

~~~
dylan-m
One of my favourite things with Django has been their mature approach to
changes. Want to be guaranteed a stable upgrade? Step 1: Fix deprecation
notices. Step 2: Upgrade. (If you're upgrading over a few releases, return to
step 1). Coming from other frameworks it's a delight :) At least that's been
my experience with smaller projects. I'm curious, does that line up with your
experience with Zulip, too?

~~~
tabbott
Yeah, that matches my experience; their documentation on upgrades is
excellent, and there's generally only issues not covered by their deprecation
notices in places where you were doing something not supported by the
documented API (E.g. monkey-patching, subclassing to override something,
etc.), and even then, they often comment if it's a common type of
modification.

------
Ramiuz
I have been using FastAPI for the last two months (which also is an ASGI
server and makes full use of annotations and type hints with mypy) and the
experience has been incredible.
([https://fastapi.tiangolo.com/](https://fastapi.tiangolo.com/))

If Django can now also support annotations and async code I dream of an
scenario where apis can be built using this two elements.

Does anybody know a good resource to learn/catch up with this release?

~~~
andrewgodwin
It's worth pointing out that the ASGI support in this release is very low
level, and doesn't let you write async views or anything yet. We're still
working on that.

~~~
petters
Thanks for your work on this.

If I am willing to hack a bit, is it possible?

What is the main obstacle? Is it all middleware?

~~~
mattrp
If you’re in the hacking mode - what do you think of taking the Django orm and
grafting it onto fast api - sort of like a stand-alone sqlalchemy but with all
the ease and power or django’s querysets...

~~~
m_ke
Django ORM is not async so using it with FastAPI would block the event loop. I
guess you could wrap the calls in sync_to_async from asgiref but it wouldn't
be pretty.

Another option is using something like Tom Christie's orm project
([https://github.com/encode/orm](https://github.com/encode/orm)), which is a
wrapper on top of sqlachemy with a django like interface.

~~~
hultner
FastAPI runs blocking IO/sync functions in a separate thread pool to work
around this issue.

------
airstrike
The community built around Django, coupled with the sheer amount of
documentation and the stability of their APIs has done enough to forever ruin
my expectations for any other coding project out there. Ostensibly everything
else feels disorganized, poorly documented or rushly released.

But the most commendable value of the DSF – which I believe is a model to be
replicated – is how effectively it has managed to both attract new developers
and also mentor them so well that they have gone on to become core developers
who maintain the framework later on.

I'm still subscribed to the django-developers mailing list, even if I have had
no free time to contribute with more than a couple patches over many years,
simply because I enjoy watching how incredibly smart and efficient developers
collaborate.

Kudos to all of you guys, and congrats on achieving this big milestone!

~~~
madrox
I echo this sentiment exactly. I don't feel like OSS projects achieve this
kind of success by accident. I'd love to see some write-up of some kind on how
they do it. They're definitely the gold standard in my mind.

~~~
frankwiles
That’s a damn good idea!

------
gonational
If you can convince your company to keep Django up-to-date with every release,
I have found this to be easy and pain-free (Django has been pretty API stable
since ~1.8), compared with waiting for each LTS and then being forced to jump
ahead three versions each time.

You also gain access to new features as they come out, this way.

~~~
primozk
But you have to be careful that all dependencies are up-to-date as well.

~~~
vdfs
No to mention each new release have many incompatibility that you need to read
the release note to find out

~~~
BozeWolf
Django is very good at being backwards compatible. Deprecated functions emit
warnings for a few releases before being removed. They are also documented.

Do you have some examples? Are you sure you are not confused with
dependencies?

The release notes mention less than ten deprecations related to django. Other
stuff which is not supported anymore is mostly non supported database
versions.

[https://docs.djangoproject.com/en/3.0/releases/3.0/#backward...](https://docs.djangoproject.com/en/3.0/releases/3.0/#backwards-
incompatible-3-0)

------
wiremine
Just want to say thank you to the Django core team. I was privileged to use
Django full time for over 6 years. Both the project and the community are a
joy.

There's a few times I had to dive into Django's internals, and every time it
was logical and straight forward to understand and modify.

Thanks guys!

------
m_ke
Was really excited to upgrade but the async safety check makes the ORM
unusable in a Jupyter Notebook.

[https://stackoverflow.com/questions/59119396/how-to-use-
djan...](https://stackoverflow.com/questions/59119396/how-to-use-
django-3-0-orm-in-a-jupyter-notebook-without-triggering-the-async-con)

[https://forum.djangoproject.com/t/is-there-a-way-to-
disable-...](https://forum.djangoproject.com/t/is-there-a-way-to-disable-the-
synchronousonlyoperation-check-when-using-the-orm-in-a-jupyter-notebook/548)

~~~
singularity2001
please tell me that python did not adopt the javascript async hell. async
should be an optional keyword on the CALLER side, not an invisible trait of
the function. go figure()

~~~
m_ke
It didn't, async await is just syntactic sugar on top of coroutines/futures.
You can define an sync function and get a coroutine back if you call it
without await.

It's still kind of a mess though because you have two universes that are not
really compatible, forcing you to rewrite everything that touches IO. For
django that probably means a rewrite of the ORM, caching and middlewares.

~~~
hajile
JS async/await is also just syntactic sugar on top of Promises (which are
basically just futures with the ability to write as well).

------
reustle
I've been building some fun side projects with Django lately and it's really a
breath of fresh air. Normal, old, boring web applications with server side
rendered html and basic forms. Sure, I can't add some super fast interactivity
on my forms as easily without some json endpoints, but for most of my projects
it's totally fine.

------
pkuphy
[https://www.aeracode.org/2018/06/04/django-async-
roadmap/](https://www.aeracode.org/2018/06/04/django-async-roadmap/)

[https://github.com/django/deps/blob/master/accepted/0009-asy...](https://github.com/django/deps/blob/master/accepted/0009-async.rst)

------
IgorPartola
Groovy. I am excited to try out the new ASGI goodness. Last time I used Django
Channels it was a constant struggle to tune it, prevent it from becoming
deadlocked, etc. And the transition from Channels 1.x to 2.x was also not
pleasant. I hope that Django proper did things better/differently.

~~~
andrewgodwin
Well there's no actual async support for views in 3.0 - we missed the cutoff
due to performance concerns! Hopefully it'll be in 3.1.

~~~
naveen_
Thanks for the info & for your work!

------
Alir3z4
Django and Python have made me a much better developer.

Using it for more than 10 years professionally, full time with no stop.

It helped me to pay my bills, bring food to the table and build my ideas and
get one step closer to my dreams.

Thank you Django and everyone around or behind or even remotely related to it.

~~~
andy1729
Can you explain lil bit more like what exactly you do with django (freelancing
or job??) and your journey with django. I am sensing their is a great story
which can inspire newbies like me! Thank you very much sir!

~~~
Alir3z4
Prior to working with Django, I worked with ASP.NET/C# and later PHP with
various web framework CakePHP, Zend, Symfony) and then worked Ruby on Rails
for 2 years until I found Django (version 1.0.x I think) and from there in
less than week, without even having a knowledge in Python, just by following
tutorials and reading the source code I become productive and made production-
ready apps.

Almost all of my work with Django is through full time and once a while
contracting gig here and there (very short ones.)

Not just my day time job, I also implement all my side/personal/commercial
projects with Django (gonevis.com is my latest project).

Django never gave me a tough time to understand anything, for almost
everything there's a well-maintained library and properly tested with enough
community around it, it's ORM is crazy easy to work with, optimize, tweak and
change when needed.

Every new release is easy to upgrade, you may have some problem with third
party libraries to catch up if something is not compatible with them but in my
experience with medium-size code base (~300k LOC) the whole upgrade would take
2-3 hours and that was just changing code and running the tests, all in all,
in 2-3 week most of the other third parties would have upgraded as well.

It's mature framework, doesn't get crazy with new shiny things (NoSQL,
MongoDB, WebSocket, etc), it might be late to some technology but it's because
it stays in the corner until all these shiny things have worked out their
problem and issues, then those things will become part of the official code
base, otherwise if you're in hurry, there's always another third party that
bring those for you, either NoSQL, WebSocket, push notifications, OTP, etc.

For me, the most fascinating thing in Django is the ORM, Authentication,
Admin, Views and template engine and the crazy support of PostgreSQL (almost
the same applies to other database backends in Django), sessions, caching and
every other single thing in that carefully have been layered upon each other
and work in harmony. The database migration (formerly South migration then
part of official) is something you can't easily find in other frameworks
(Rails migration is great as well).

Now, DRF is something else, since starting to work with DRF, I've become an
API monster :D

The framework that lets you implement your idea without getting in your way
and allows you to bring ideas from zero to production very quickly, is the one
I look forward to using (I use Java Spring once a while as well).

For me, Django and it's surrounding makes sense, it's logical and it's not
magical, maybe it's just me and it may not be something tasteful for others,
if you find a framework you're comfortable with it, then use it, if you get
into Django, I hope you feel the same.

------
randshift
Congrats to Django's contributors and community! It's been a while since I've
actively worked in Django but I found the people in the Django ecosystem to be
generally very helpful.

------
fareesh
Interested in reading about agencies that used to (mostly) build web
applications in Rails but then switched to (mostly) Django.

I find the productivity somewhat higher from a business point of view, to turn
around projects for customers when using Rails instead - largely due to the
gem ecosystem and the way community libraries tend to play well with one
another.

~~~
m_ke
I think it really comes down to the type of project that you're working on.
For data science / machine learning projects python is a much better choice
and that spills over to django.

REST APIs are also incredibly easy to throw together using DRF.

~~~
fareesh
I feel like you could just unload the data science + ML stuff to a separate
process though.

------
Pandabob
This looks neat. Does anyone have experience with using type hints and mypy
with Django? Any gotchas?

~~~
emptysea
I gave ‘django-stubs’ a spin on a Django 2.2 project. The ORM typings and mypy
plug-in worked great. ‘.filter().first()’ and similar all returned the correct
types.

Ran into a couple issues with the typing of ‘client.force_login()’ where the
‘user’ parameter was typed as the ‘get_django_user()’ which wasn’t the same as
the custom user model I defined in the ‘models.py’. I also had issues with
‘from django.conf import settings’ not being the correct type so I’d suggest
changing that to ‘Any’.

You might be able to override the few types that don’t work for your given
setup or you can just fork the repo.

Overall, I think the pain is worth the benefits.

~~~
mkurnikov
Hi, I'm a primary maintainer of 'django-stubs'. We're going to release new
version with mypy==0.750 and Django 3.0 support soon. Could you create an
issue for your 'client.force_login' problem?

> I also had issues with ‘from django.conf import settings’ not being the
> correct type so I’d suggest changing that to ‘Any’.

This one also has plugin support, and should be working mostly correct. Fill
the issue if you can reproduce, I'd love to help with that.

What's your experience with that whole "plugin has to actually run
django.setup() before typecheck" thing?

------
luckycharms810
Having worked with Asynchronous python since the days of twisted, tornado - I
haven't really found any real reason to switch to asyncio. Generally speaking
the old forms of async syntax (@coroutine, @inline_callback) make it
incredibly clear that you are executing code well outside of a sequential
paradigm - they force you to think a little more about what is going on.

The idea of Django throwing errors when you try and run async unsafe code
within an event loop gives me cause for concern. I can just imagine folks who
don't understand adding 'yield', 'await', 'yield from' until the errors go
away - while being confused with the resulting execution. I think there is
always a place for synchronous code in Python - I think Django should lean in
to the simplicity afforded by it.

Last note - I also am very weary to mix asynchronous code with other
primitives like threading, multiprocessing. If I am going the route of async
programming - I usually just intend to optimize a single thread - and then I
leave it up to the OS to optimize across multiple processes.

~~~
fjp
I'm a really big fan of using aiohttp + aiopg + some light wrapping for CRUD
APIs

------
andrewstuart
I learned, in this order:

bottle

flask

falcon

django

Django is incredible. It was useful to start with the minimalist frameworks to
understand the true value of Django when I got there.

Django is amongst my software top 10. Maybe top 5.

~~~
oehtXRwMkIs
Curious as to what your top 10 is.

------
scarygliders
Right as I was just about to start a new Django project...

The thought going through my mind right now is "I wonder if there is some way
of creating a Django project and make it resilient to future Django updates
and releases with minimum fuss?"

I've had to deal with ongoing and inherited legacy projects which run on
Python 2.7, use the long-deprecated Pylons, for which there is no easy upgrade
path other than a total re-write in less deprecated technologies. No practical
way to convert that Pylons project to Pyramid, for example.

I guess the answer to my thought above is to "Not do/use anything /too
exciting/ when creating your Django project" \- i.e. only use the most basic
and generic Django features, but even then what's to say those won't get
deprecated in favour of some new exciting replacement?

I guess that's one of the dilemmas developers have day to day?

~~~
mamcx
I work as a contractor and have codebases in python, f#, delphi, swift, obj-c
and now rust.

> "I wonder if there is some way of creating a ???? project and make it
> resilient to future??? updates and releases with minimum fuss?"

\- Use control version (mercurial, git, ...) in everything, including utils
and side projects.

\- Record all dependencies somewhere in the project.

\- Automate the builds, so you also have how reconstruct the project

\- Use VM or containers or virtual envs or similar

\- Rely in a small "core" of solid dependencies (in my case: PostgreSQL,
sqlite3, nginx, ubuntu LTS) that could cross across projects and versions.

\- Reduce dependencies (but each day is HARDER and HARDER) or better, NOT USE
VERY FANCY STUFF (rely on PAAS or kool-aid kind of tech.) For example, If I
rely in a http client library it can be dead years after I need to upgrade.
That sucks, but, a "http client library" is so "normal" to have that I can
rely in found a alternative easily. However, if I base everything on top of
Firebase or other cloud stuff, if it die... good luck with that!

~~~
dkarras
>NOT USE VERY FANCY STUFF

They said "with minimum fuss". Write every non-trivial functionality yourself
from scratch is the opposite of minimum fuss.

When you use something fancy, and the devs stop supporting it, worst case is
you have to write it from scratch yourself at that point, or hope that an
alternative exists.

Your suggestion is acting like they don't exist in the first place and write
stuff yourself like fancy stuff disappeared - it is a huge hassle and
investment all the same.

~~~
mamcx
I mean VERY fancy stuff. Things nearly "experimental" or that rely in a huge
black box. Like "not chance in hell I could replicate it" instead of "very
hard, but doable".

I know everything have "but..." somewhere (for example: We rely in operating
system and the browser, 2 things too hard to recreate) but the idea is always
about minimization.

Sometimes you NEED to rely in VERY fancy stuff... but then you are walking on
luck...

------
cstuder
Release announcement:
[https://www.djangoproject.com/weblog/2019/dec/02/django-3-re...](https://www.djangoproject.com/weblog/2019/dec/02/django-3-released/)

(The release note erroneously still show the "Under Development" banner.)

------
aitchnyu
OT, but what do you use to validate JSON posts without DRF? We mangled django
form fields to validate a list of ids, but can I use forms to validate nested
JSON? I now use Marshmallow for that use case but would love to stick with
Django forms.

------
darkerside
For those on the 1.11 LTS release, and considering getting off the LTS train,
I wonder whether it's a feasible upgrade path to go straight to 3.0, or if it
would be smarter to go to 2.2 first.

~~~
jacobian
My experience has been that the easiest method is to to upgrade one minor
release at once (e.g. in your case I'd do 1.11 -> 2.0 -> 2.1 -> 2.2 -> 3.0).
This has almost always gone quite smoothly, but it is somewhat tedious.

That said, jumping a bunch of releases (e.g. 1.11 -> 3.0) actually often works
out just fine, especially if I've got good test coverage. It's just that when
it doesn't work, it can be tricky to find out what's going wrong. That's
because the release notes are typically written with just a single step in
mind, so with a bunch of releases I find myself scrambling to figure out which
set of notes I need to read.

~~~
samwillis
I recently went from 1.11 -> 2.0 -> 2.1 -> 2.2 over the course of about a
week, deploying to production each time we had all test passing to ensure
there wasn't anything amiss. There were actually relatively few changes to get
there, the upgrade to Python 3 was a bigger (albeit still manageable) change.
I'm expecting very few changes to get onto Django 3.0, will probably wait till
the first bug fix release though as it tends to catch a few things.

The best thing to go is run the dev server with `python -Wd` to get the
depreciation warnings, and fix them before each upgrade. Worked perfectly!

------
tracer4201
The last time I used django was for one piece of a capstone related project
back in college, and for what I was doing, it was dead simple (to get up and
running, that is).

I’ve seen python used extensively for data science work, but I’m not sure how
well dynamic typing works (in terms of support ability/maintenance) in a
larger code base, especially as some trivial knowledge gets lost and newer
folks are introduced to an older code base. Do you just set break points to
trace? I digress, but open to hearing folks thoughts.

------
goodoldneon
> Django is now aware of asynchronous event loops and will block you calling
> code marked as “async unsafe” - such as ORM operations - from an
> asynchronous context.

So DB calls aren't async?

~~~
gonational
Correct - the Django ORM is not (yet) async.

The asyncpg library[1][2] could be used for direct, asynchronous database
access, from within a Django 3.x app.

The asyncpg library is a low-level async Postgres adaptor, similar to
psycopg2, except that it provides much better abstractions and automatic
encoding / decoding (vs just piping bytes back and forth like psycopg2), not
to mention it is much faster than anything else out there. IOW, asyncpg would
serve as a much better foundation for a future ORM. My best guess is that, in
the future, Django's ORM will be refactored to optionally support async and
will supply an adaptor for asyncpg.

1\.
[https://github.com/MagicStack/asyncpg](https://github.com/MagicStack/asyncpg)

2\.
[https://magicstack.github.io/asyncpg/current/](https://magicstack.github.io/asyncpg/current/)

~~~
hultner
Asyncpg is amazing, I’m writing a thin dataclass-style semi-orm-layer ontop is
asyncpg. Still very early but I’m considering cleaning it up and extracting it
to a stand-alone library if I see any demand for it.

------
ak39
OT: Are there any backend JSON/REST open source applications* that allow
declarative configuration for your storage (eg. set SQL statements in config
files) instead of needing compilation?

------
rptr_87
I have been learning flask for development. Can someone describe advantages of
using Django over flask?

~~~
ablekh
Please check out the following posts: 1) [https://devel.tech/features/django-
vs-flask;](https://devel.tech/features/django-vs-flask;) 2)
[https://www.airpair.com/python/posts/django-flask-
pyramid](https://www.airpair.com/python/posts/django-flask-pyramid). Hope this
helps.

------
bobjordan
Is substituting the Django ORM for SQLAlchemy doable in V3?

------
deusofnull
i <3 django. thank you to all the people involved!

------
bicx
Does Python still have performance issues? That's always been my concern when
considering its adoption.

~~~
sojmq
Yes. If you can afford the CPU power, by all means go with Python. Otherwise
just don't.

Instagram can afford it so it works fine for them. Reddit can't, so their site
is always slow or down.

~~~
traverseda
I think reddits issues are more related to database IO than cpu time.

------
904baf11
> ASGI support

> Django 3.0 begins our journey to making Django fully async-capable by
> providing support for running as an ASGI application.

Bleh. ASGI is probably the worst implementation I can think of for a common
async interface. Stringly-typed callbacks? async generators exist for a good
reason. It's also very asyncio-centric, and asyncio is Not Good.

~~~
andrewgodwin
I'd love to hear your suggestions for changes we could make while keeping it
somewhat WSGI-compatible. It took a few years to refine it to where it is now,
so it's not like we just threw something at the wall.

~~~
904baf11
> while keeping it somewhat WSGI-compatible

There's the problem. WSGI is fundamentally flawed too - it could also be using
generators for a two-way communication channel instead of stringly typed
callbacks.

In a world where Python has optional static type hints, it would be nice to
have concrete objects passed too.

~~~
orf
Can you expand on the stringly typed callbacks? Where are they required? Are
you referring to string keys in a callback dictionary, in which case stringly-
typed seems a bit of an odd choice of words.

~~~
904baf11
Calling the receive async function gets you a dictionary with a string type
key, which defines the layout of the dictionary. It's not nice.

