
Django 2.2 - ataylor32
https://www.djangoproject.com/weblog/2019/apr/01/django-22-released/
======
fredley
Django/Jupyter/pandas is an ecosystem that's hard to beat.

If you're not already using it, check out `django-extensions`. You can use
`./manage.py shell_plus --notebook` to launch a Django-friendly Jupyter
notebook.

From there you can prototype with extreme ease and confidence.

I have also built a trivial custom model Manager so I can do stuff like:

    
    
        User.objects.all().to_dataframe("first_name", "last_name", "email")
    

Honestly I can't see myself being even slightly tempted to move to something
else unless I can replicate this workflow.

~~~
vonseel
Not a data engineer / scientist here.

What am I missing with data-frames?

I've written products that utilized them before (years ago), but it's been
long enough that I don't know what I would even use them for in daily
programming.

~~~
shirakawasuna
They're for tables and doing table-ie things: an imperative programming method
for the same tasks people use Excel or SQL for.

This dovetails nicely with most data science-ie tasks, like statistical
analysis, engineering features, simple machine learning techniques (the tables
can be easily transformed into numpy arrays), and plotting results.

You can use them any time you feel the need to do table manipulations on non-
insanely-large data: aggregate, transform, combine, split, reshape, join...

~~~
vonseel
Got it, I was aware of this and many of the performance benefits another user
mentioned, but wasn't sure how it could be useful in daily operation or quick
Django shell_plus style scripting (one-off commands) when inspecting something
like a User's table, as the original comment above indicated.

------
orf
This release includes the Watchman based reloader I worked on for about a
year. It turns out auto reloading in Python is not an easy task, and I’m
really nervous about edge cases I haven’t considered!

I’ve actually had a nightmare where everyone’s auto reloader was broken. While
it never runs in production (right?!) it’s actually a pretty critical bit of
Django that had not been touched in about 10 years!

~~~
jacobian
Thank you! The new auto reloader is better by quite a bit. Many people have
talked about doing this over the years, but nobody's been willing to do the
grunt work and figure out all the corner cases, until you. Nice job!

------
mkolodny
I love Django. I've used it for the last 8 years. I'm happy to see the project
is still thriving.

At this point, for me Django is pretty much synonymous with Django REST
framework ([https://www.django-rest-framework.org/](https://www.django-rest-
framework.org/)). I can't imagine a better API than Django w/ REST framework.

For static sites I use Django's templates. Otherwise, I just use Django w/
REST framework for my API, and to serve up index.html. My index.html will
include a link to my JS bundle(s) - I use a separate build system
(Webpack/Babel/etc) to handle JS.

~~~
ibejoeb
DRF is awesome. If you're considering moving to or implementing GraphQL,
though, Django + Graphile is amazingly productive and performant. No
affiliation, just good experiences.

[https://www.graphile.org/postgraphile/](https://www.graphile.org/postgraphile/)

~~~
RussianCow
If you're using Postgraphile for the API layer and a frontend framework for
the view layer, what do you need Django for? Just migrations?

~~~
nouveaux
Postgraphile solves the problem of boilerplate CRUD very well but it does not
handle custom and complex logic well. For instance, interacting with other
APIs like payment.

~~~
BenjieGillam
I’m sorry you feel that way; I use PostGraphile with external APIs frequently,
using makeExtendSchemaPlugin to easily add more types and resolvers to my
GraphQL schema. Maybe you could go into more detail on the issues you’ve faced
here so I can improve the project?

------
bluedino
The projects/app relationship never 'clicked' with me. I also have a dislike
for the awkward 'polls' example in the django tutorial.

That said, I like Django. Of course, I liked Rails better, but maybe that's
because it was my 'first' and I never used any of the big php frameworks for a
long period of time.

I quit wasting my time with Flask for projects a while ago. It's a really
great project and suited for smaller things, but you just end up re-implenting
django. I'd rather someone made those decision for me.

~~~
digitaltrees
I feel the same way. Does any one have a good overview on how the community
actually separates functionality into “apps”?

I have been looking at a rails like framework in python called Masonite. Does
anyone in the python/Django community think this will gain traction?

~~~
Alex3917
> Does any one have a good overview on how the community actually separates
> functionality into “apps”?

For the most part there isn't any need to, with the exception of things
explicitly meant to be shared. So if you are a large company and want a bunch
of custom auth logic or something to be shared among many different teams
running their own Django service, then you might want to build that as an app.
Or else if you were building something as an open source project you might
want to do the same.

In terms of separating apps by functionality, I think the main reason many
people do it is because they are under the mistaken impression that putting
things into different apps will make them magically re-usable. That's not to
say you shouldn't do it, only that I think most people do it for the wrong
reasons.

In general I would say don't bother splitting up your project into different
apps by functionality until you have too many models to comfortably fit into
one file. That might not be until 20KLOC. For apps that are less than 10KLOC,
I think in most cases the overhead probably outweighs the benefits.

There isn't really any hard rule one how to do this, but you might do
something like:

\- Account management app for creating and deleting users, getting user
profiles, password resets, etc.

\- Apps for integrations with third-party APIs, e.g. Duns or Mailgun.

\- Apps for different front doors, e.g. if you make a Facebook chat bot that's
powered by the same tech that powers your normal website.

And then after that you can possibly split up your business logic of your core
website into different logical components, but I would do that last. By the
time you get there you should start to have a feel for how to do this.

The one place I use it for our own startup is that we recently built a couple
different front doors for our site, and each one accepts data in a slightly
different format and has different authentication requirements. I put each of
these in their own apps, but everything else is just in one main app.

~~~
digitaltrees
Thanks for the thoughtful response. Do you find yourself repeating code, or
struggling to decide where code should live and where it should be imported?

~~~
Alex3917
I had this problem for the first couple years, but not anymore. What I did:

\- I split the core app up into different views and services based on the
functionality. For FWD:Everyone this is basically: account_management,
admin_apis, content_discovery, organizations, upload_thread, read_thread,
comments, and user.

I have a folder for all my views and a folder for all my services, and for
each view there is one (or occasionally two) service files.

So e.g. in the views folder there is a file called account_management_views,
and then in the services folder there is a file called
account_management_service.

For utilities that get re-used across the entire app I have two additional
things in the services folder, one is called util.py and the other is
io_util.py.

Util is for things like sanitizing XSS that don't require any database access,
and io_util is for things like get_user_from_username,
get_user_from_email_address, etc.

Then you can import any models into io_util.py, but never into util.py. And
you can import anything from util.py into io_util.py, but never the other way
around. Then you can import anything from either util or io_util into any
service method and shouldn't have any issues. (Although I always just import
util or io_util, and then call the methods like util.sanitize_xss.)

Once I structured the services and utilities that way I never had issues again
with circular imports or figuring out where to put stuff. Importing with
Python is kind of difficult and janky in general, but so far this pattern
seems to be working pretty well for both our startup and also for the
consulting projects I've done.

Basically for logic that's mostly specific to a single view, put it in the
services file for that view. Public functions in that folder can still be re-
used in other services, but if they're fairly generic and they're re-used in
more than one or two places then consider moving them into util or io_util so
as to avoid circular import issues.

------
scardine
What I find most curious about Django/Python is that about 30% of the new
installs are for legacy Python/Django (2.7/1.11):

    
    
      $ pypinfo --start-date 2019-01-01 --end-date 2019-03-31 -- 
      percent --markdown django pyversion
      Served from cache: False
      Data processed: 160.22 GiB
      Data billed: 160.22 GiB
      Estimated cost: $0.79
    
      | python_version | percent | download_count |
      | -------------- | ------: | -------------: |
      | 3.6            |  39.61% |      3,277,927 |
      | 2.7            |  29.59% |      2,448,652 |
      | 3.7            |  17.53% |      1,450,949 |
      | 3.5            |  10.37% |        858,325 |
      | 3.4            |   2.76% |        228,150 |
      | 3.8            |   0.07% |          5,428 |
      | 2.6            |   0.04% |          3,686 |
      | 3.3            |   0.03% |          2,103 |
      | 3.2            |   0.00% |            220 |
      | None           |   0.00% |             56 |
      | Total          |         |      8,275,496 |
    

I would expect everybody moving over 3.x by now - we are so close to 2.7 EoL
in December...

~~~
jordigh
Trying to move, but it's tough. Old codebase, lots of deps, and no real
benefit to upgrading to 3.6, nothing our end users will care about or notice
(or pay for).

Upgrading to Python 3 is a chore. We have to do it, but it's not fun and it's
barely useful.

~~~
PunchTornado
don't your users in 2020 care you are using an unsupported language? security
wise

~~~
user5994461
Of course not. That's the point.

~~~
PunchTornado
the users care that your site is secure, especially if you're using their
confidential info.

can you achieve security with a dead language? I don't think so.

~~~
jordigh
Users care very little about security, actually.

------
mattrp
I would just add that if you’re new to Django read
[https://simpleisbetterthancomplex.com](https://simpleisbetterthancomplex.com)
\- there are ton of detailed explanations that go deep in how Django can be
extended. It’s definitely not the run of the mill tutorial blog that is only
surface level.

~~~
aldoushuxley001
Yeah I can't recommend simpleisbetterthancomplex enough for anyone into
Django. Great tutorials and articles about many issues you typically run into
or just best practices for certain things. The guy who runs it even started a
nice community forum that's been very helpful too.

------
amerine
Nice. Anyone building fun stuff using Django these days?

~~~
Alex3917
Django is still by far the best web framework as far as I can tell. Every
couple years I check what's out there for GoLang, Rust, Nodejs, and Swift, and
it seems like it will be a decade or more before anything else comes even
close.

Even though a lot of people don't like Django's ORM, at least it does almost
everything you would want to do with Postgres. (And if you want more you can
always use SqlAlchemy.) Most of the other ecosystems don't even have anything
near the baseline functionality built into Django.

~~~
nicoburns
IMO PHP's Laravel is competitive with Django.

I think Django, Laravel, and Rails are really the only 3 frameworks with the
levels of ecosystem and built in functionality that these 3 have (unless
there's something in Java-land that I'm not aware of). ASP.NET Core is close,
but the ecosystem around it is weaker.

~~~
BuckRogers
I reviewed these sort of web frameworks some time ago and went with ASP.NET
Core because of the language attached being more to my liking and industrial-
strength than Python, PHP or Ruby. I go in assuming every project will be
500KLOC someday, because it can happen. I've seen codebases this large in
Python, and it was no bueno. Static typing, forward migration / backwards
compatibility take top priority for me.

Laravel was my 2nd choice, the recent adoption of a JIT into the core really
adds some desirability to the space. Not to mention HHVM and how much
Wordpress is out there.

~~~
somecallitblues
But then you’re in Microsoft echo system. No bueno.

~~~
mosen
Would you mind expanding on this?

~~~
BuckRogers
People with that mentality aren't rational. If MS offers the best product,
which they do for an awful lot of tech, especially once you start valuing
integration & support, you should use it. It's actually pretty tough to beat,
even if there's guys like that who don't believe in using "best of breed".
Using "what you know" is usually best from a developer standpoint, but
Microsoft has many best-of-breed products, much to his dismay.

------
techie128
Django is awesome. It is a model Open Source project that everyone should
emulate. I have used it in the past and it can make you hyper-productive
especially if you're prototyping stuff.

------
newaccoutnas
We're a Django shop and it's a pleasure to work with (most of the time). Happy
to see a 2.2 LTS release, that should light the fire under some teams to
upgrade

------
rattray
I've been away from Django for a few years, and hope to come back one day.

One thing I'm curious about, coming from well-typed JS codebases using Flow,
is the quality of typings in major projects like Django, Pandas, etc. Are
their APIs well-typed? Can I get quality types for my models?

~~~
akx
The PyCharm IDE has extra support for Django to enable some additional type
inference, and it works like an absolute (pun intended) charm.

Beyond that, the Django core isn't type-annotated yet likely because of Python
version support, but I'm sure you can get typeshed pyis or something.

~~~
yhoiseth
There's a discussion on the mailing list about this, last updated a few months
ago: [https://groups.google.com/forum/#!topic/django-
developers/tr...](https://groups.google.com/forum/#!topic/django-
developers/trTEbURFhEY/discussion)

------
namelosw
I really hope Django can provide some front-end integration like Rails
Webpacker or Phoenix does. Setting up a smooth SPA and proxy is such a grunt
work which always something holds me back when I trying to set up a small
project with Django.

------
neves
I'm a fan of Django, but I'm in doubt if I must still use it for my new
project. I'll develop now an hybrid app that will start life as an mobile web
site. I'll use one javascript framework and I'm really in doubt about using
Django.

If I use a javascript server framework, I believe that it will prevent me to
duplicate forms validation code (in server in frontend) and also easier for
SSR (Server Side Rendering). But Django is a robust framework, in my beloved
Python language, why should I still use it?

~~~
rochacon
IMHO, code sharing between the frontend and backend is very hard to do
properly and you have more changes of making stuff too generic and
unmaintanable faster. KISS

As any new project, go with you're most comfortable with, so you can prototype
and changes things faster. After you reach a good size and understanding of
the problem you may refactor stuff for a different language/framework with
better reasons for it.

That being said, if you want to use Python but not a "batteries included"
framework like Django, so you have better control of the stack, check out
Pyramid, it is really good and scales (I'm talking on code maintainability,
but also performance-wise) very well from pet-project phase to complex
applications.

------
andrewstuart
Django is a magnificent piece of software.

I'm an experienced ReactJS developer and I discovered Django after ReactJS and
I am finding myself developing new projects not with React but just with plain
Django/JavaScript/HTML. That's because of the nature of my projects of course
which are simple crud applications, but the point is that for simple
applications, Django makes things incredibly easy and fast and importantly,
easy to understand.

More sophisticated user interfaces I would definitely build in React of
course.

~~~
spapas82
That's the real power of Django for me: Good ol' HTML based apps (with a
little salt of jquery when needed) using the tools that Django (and friendly
projects) generously offer to create Angels in a fraction of the time you'd
need with anything else!

------
coderunner
I'm coming from a systems and desktop background and looking into a web side
project. My only experience with backend frameworks is a few months with
Django for a small project at work.

Is Django still a thriving development community? And is it able to handle a
large amount of concurrent users? Basically is it a good choice for a backend
for a new project? The web tech world moves really fast, and I like that
Django has been around for years but wondering if it's still a good option.

~~~
bshipp
I have an assortment of Django and flask-based websites and Django still works
fine for new projects from my perspective, with the normal caveat that it
really depends on what you want to do with it. If i had to redo some of my
projects I'd probably use the Django rest framework more heavily as I ended up
duplicating a lot of that functionality writing Ajax endpoints way back in the
day, but I've not encountered issues where Django is the bottleneck in the
system. Usually the bottleneck is a poorly optimised database index or
something, which Django handles fine to a point.

however, since I've ended up utilizing SQLalchemy and Pandas in a lot of my
projects I have since tended to use Flask+SQLalchemy a lot more so my old
fuzzy brain doesn't have to try and remember the variations between two
different ORM syntaxes.

~~~
coderunner
Thanks, I appreciate the info.

------
subhajeet2107
Awesome ! we at Careers360 (India top 100 Alexa) use Django for everything,
the best thing about an Opinionated stack like django is freshers are
production ready at day 1, learning time reduces and maintainability is solid
, although i prefer golang where frameworks are particularly not favored
,Django ORM surely lacks a lot of features but does a decent job, async story
sucks unless you are willing to give in to Channels i hope Django embraces
async officially in the core

~~~
purrpit
I believe I had interviewed once at careers360 a couple of years back, don't
think it was mentioned to me then that you guys work majorly on Django
otherwise I think I would have had a better chance at clearing it lol... But
yeah Django is awesome, It has paid my bills for years. Hopefully async will
come in relatively soon with Andrew Godwin's focus on it.

------
trpc
Why Django is not good, here are some of my reasons as far as I can remember:

1\. mediocre routing (no nesting, all routes have to be declared in one place)

2\. mediocre middleware (middleware is global)

3\. mediocre ORM (easy only for very easy stuff, more pain in the ass than
writing raw SQL itself when it comes to complex aggregations and joins) not to
mention some of the famous ORM bugs that have been open for like a decade

4\. custom user model? good luck fighting with Django errors to make that
happen

5\. custom authentication? external authentication? want a custom token
format? want your authentication token in a custom http header? good luck

6\. Django is built for 2000s websites not REST/gRPC era

7\. want to use graph databases? noSQL? good luck

8\. external migration for SQL? oh god, prepare yourself for the mental hell

9\. Django as far as I can tell still ONLY supports decoding "x-www-form-
urlencoded" bodies, yeah no JSON, it's that pathetic

~~~
rusbus
A lot of these are pretty inaccurate, at least for modern Django.

1\. I'm pretty sure that's not true if I'm correctly interpreting what you
mean...You can do things like `path('myapp/', include(myapp.urls))`

4\. Custom User models are now very straightforward (and recommended for non-
trivial projects since it's easier to start with a Custom model that defaults
to the default model for all options then modify it later)[1]

5\. All these things are fairly straightforward and libraries like Django-
Auth/Django-Rest-Auth cover a huge set of the normal use cases (OAuth, JWT,
tokens, etc.)

6\. Django Rest Framework is a best-in-class solution for Rest APIs

9\. See 6.

[1] [https://wsvincent.com/django-custom-user-model-
tutorial/](https://wsvincent.com/django-custom-user-model-tutorial/)

~~~
trpc
>A lot of these are pretty inaccurate, at least for modern Django.

I wish you state exactly which of them are inaccurate and why, I sincerely
want to know and understand

>1\. I'm pretty sure that's not true...You can do things like `path('myapp/',
include(myapp.urls))`

so you suggest I create an "app" for every sub-route? every major and non
major web framework except Django has a router where you can mount it to any
parent and mount any child to it

>4\. Custom User models are now very straightforward (and recommended for non-
trivial projects since it's easier to start with a Custom model that defaults
to the default model for all options then modify it later)[1]

maybe you're right IFF you start using a custom user model from the very
beginning, if you happen to forget that, Django will make your life like a
hell and will refuse to even pass startup checkups

>5\. All these things are fairly straightforward and libraries like Django-
Auth cover a huge set of the normal use cases.

I mean authentication tokens not Django's authentication (e.g. signin, signup)

>6\. Django Rest Framework is a best-in-class solution for Rest APIs

so you suggest people throw their codebase and start rewriting for DRF?

>9\. See 6.

so you suggest I rewrite my applications to DRF just to have JSON http request
decoding?

~~~
acdha
> maybe you're right IFF you start using a custom user model from the very
> beginning, if you happen to forget that, Django will make your life like a
> hell and will refuse to even pass startup checkups

The startup checks are protecting you from more subtle problems because if you
switch to a custom model, you need to do a migration for your stored data.
That's a one-time process which can be squashed as soon as you migrate the
last server running the old code.

> so you suggest I rewrite my applications to DRF just to have JSON http
> request decoding?

DRF is a helpful tool which solves a number of common cases but it's not doing
anything you can't do in standard Django: that could be as simple as
json.loads(request.body) in the appropriate view or, more commonly, a
decorator or class-based view which provides standardized error handling, etc.

The reason why the stock forms API doesn't do this by default is that it's
designed to support the <form> interface in the HTML standard, which defines a
simple key-value interface which is much simpler than what can be expressed in
JSON:

[https://html.spec.whatwg.org/multipage/form-control-
infrastr...](https://html.spec.whatwg.org/multipage/form-control-
infrastructure.html#attr-fs-enctype)

Once you're moving out of the realm of standard browser interfaces it's much
harder to write a generic validation interface suitable for having in a
standard library, especially since there are multiple competing ideas of what
this should look like and most of them are easily installable from PyPI
without the Django project having to support them.

------
trpc
Whenever I see people still praising Django in 2019, I immediately know that
their technical understanding of the current backend and ops technologies is
years behind. Django is still okay for small and amateur projects but nothing
more than that. It is a curse for a fast moving business.

EDIT: even though I stopped writing Django for 3 years now but here are some
of my reasons as far as I can remember:

1\. mediocre routing (no nesting, all routes have to be declared in one place)

2\. mediocre middleware (middleware is global)

3\. mediocre ORM (easy only for very easy stuff, more pain in the ass than
writing raw SQL itself when it comes to complex aggregations and joins) not to
mention some of the famous ORM bugs that have been open for like a decade

4\. custom user model? good luck fighting with Django errors to make that
happen

5\. custom authentication? external authentication? good luck

6\. Django is built for 2000s websites not REST/gRPC era

7\. want to use graph databases? noSQL? good luck

8\. external migration for SQL? oh god, prepare yourself for the mental hell

9\. Django as far as I can tell still ONLY supports decoding "x-www-form-
urlencoded" bodies, yeah no JSON, it's that pathetic

Django is very intrusive and is pain in the ass in a fast moving environment
where you want to use microservices, external authentication/authorization,
APIs, gRPC, etc... that's excluding all problems of Python itself. I totally
recommend Typescript/Express or Golang for doing any kind of non trivial
backend with fast moving environment/requirements currently

~~~
zimablue
This post is very antagonistic but I can say that point 3 rings very true,
even using advanced/data heavy SQL got very annoying for me relative to
SQLAlchemy and I don't think you really want to try and pull it out.

~~~
preommr
It's been a while since I've used SqlAlechmy, but I remember absolutely hating
it. Like you said, Django's ORM fails above very simple manipulation and even
though SqlAlchemy might be better, it was still awful. I found it better to
just write raw sql for my few use cases than to dive into page after page of
sqlalchemy documentation.

