
Django Newbie Mistakes - tosh
https://code.djangoproject.com/wiki/NewbieMistakes
======
jtchang
One of the things that makes me sad is there is no project even remotely close
comparable to Django for say Golang or Scala.

I love the fact that you get an admin interface out of the box. And tons of
documentation. The views/template stuff is a bit dated since everyone started
moving to frontend/backend services and SPAs but we still have DRF which is
incredible in the amount you get for "free".

I've had the "pleasure" of working with other large projects built on flask
and ever time it gets to a certain size I wonder why we didn't just use
Django. There is stuff you don't realize you need until some enterprise
customer requires it for your product to even be considered. Auditing, session
retries/timeouts, etc. With flask you can just add another library but it
isn't as connected as Django is. And that matters a lot when you get bigger
because it affects discussions about what the right way to do things is. You
generally have discussions about what is the right Django way vs what is the
right way in general.

~~~
jnbiche
> I've had the "pleasure" of working with other large projects built on flask
> and ever time it gets to a certain size I wonder why we didn't just use
> Django.

Actually, I've had the exact opposite experience. I like using Django for
small and mid-sized projects, because with Flask I have to spend time adding
all these extra libraries for universally required functionality on a quick
app whereas, with Django it's plug and go.

However, the larger the project gets, the more I like Flask since I have near
total control and understanding of the app. There's no digging into Django
internals to make some obscure customization.

Then again, it's been several years since I last used Django, so it may have
changed for the better here.

~~~
danpalmer
For what it’s worth, on a Django codebase of 180k lines, 100k lines of
templates, 1000 URLs, 380 “apps”, 350 models, we have a nice coherent
structure across the whole codebase that makes us really productive.

I haven’t seen a Flask code bass do this anywhere near as well. They all seem
to end up becoming very different and tricky to onboard new devs onto because
they are so custom.

Django hides some complexity, but we haven’t found many pets we can’t
effectively customise, and the architecture at scale is great, something I
haven’t seen in many other places.

~~~
ernesto7
Do you mind explaining what that structure is? I always find the standard
Django structure of everything is an "app" difficult to navigate once the
codebase gets larger.

~~~
danpalmer
As much as I'd rather not plug my own talk, it's probably going to give you
more information than I could ever get in a reply here.

[https://thread.engineering/scaling-django-codebases-pycon-
uk...](https://thread.engineering/scaling-django-codebases-pycon-
uk-2017-91c166fcb926)

------
ryanisnan
I've worked with django for a considerable amount of time now (~9 years), and
I have found the documentation a joy to work with. The documentation generally
covers each piece of functionality, and the source code is rich with
documentation.

When it comes to django itself, there are nuances, and yep, some of them
probably can be smoothed over for developer experience, but developers must
have knowledge over their tools.

If you feel like django is getting in your way, take a step back. Maybe you
can remove some of the abstractions it provides and do it yourself? Maybe look
at the source code? If the magic is no longer working, it's time to realize
that it isn't magic to begin with, but possibly a lack of understanding.

~~~
Daishiman
Usually when people complain about the magic in Django it means that they're
trying to work with things that are complete antipatterns. Django usually has
one, really good, solid way to do each task and going against the grain is
always going to hurt.

~~~
ryanisnan
To add to this, when you want to go against the grain, you can quite easily,
at the core, it's mapping HTTP requests to python functions. Outside of
middleware, it's trivial to strip all unnecessary additions.

------
tosh
Django’s documentation is still the best I have worked with so far of any
software project I came across to date. It not only explains, it educates.

~~~
davzie
I find it some of the hardest documentation (close to AWS) to understand the
best way to do something. I think it's great if you know what you're doing or
you have a rough idea of what to do but need more information, but for someone
new to the framework it makes me want to paper cut the webs of my fingers and
bath my hands in vinegar because it would be less painful.

~~~
paulie_a
I agree. The tutorial is incredibly simplistic with a "go play" ending. Then
the actual documentation assumes you have a pretty good knowledge of how
everything works. There is no middle step without utilizing 3rd party docs.

~~~
mixmastamyk
There are also lengthy guides on each part ORM, Templates, etc.

~~~
paulie_a
The problem is they quite frankly suck.

The official ones are incredibly dry and not approachable by someone wanting
to get started and do anything meaningful. I've helped people learn Django and
the official docs/guides are the last on the list of recommendations. there
are so many better resources to look at first. I've told people to skip the
polls app and go through Django girls tutorial. The polls app is a waste of
time.

~~~
kraptor
May be the django book might be the approach you are looking for...

[https://djangobook.com/the-django-book/](https://djangobook.com/the-django-
book/)

------
jonknee
Great post, though this bit stuck out for me:

    
    
       current_zip = meta.IntegerField(max_length=5, blank=True)
    

You should not store zip data as an integer as they can start with 0. Zip
codes use numbers, but aren't actually numbers themselves (leading zeros, no
arithmetic, etc). Plus, someday you'll want to ship something to Canada.

~~~
silvestrov
It's even worse: zip codes can contain letters and spaces in United Kingdom:
[https://en.wikipedia.org/wiki/Postcodes_in_the_United_Kingdo...](https://en.wikipedia.org/wiki/Postcodes_in_the_United_Kingdom#Validation)

~~~
ubernostrum
Falsehoods programmers believe about this HN thread: it links to Django's
documentation.

It linked to a 13-year-old unmaintained community wiki page, and people
apparently didn't look too closely at it. I stuck a big honkin' warning at the
top of the page to clarify that.

If you want to handle US zip codes, UK postcodes, or other country-specific
data types in Django, may I suggest this, which formerly was bundled with
Django and now is maintained as a separate add-on:

[https://django-localflavor.readthedocs.io/en/latest/](https://django-
localflavor.readthedocs.io/en/latest/)

It includes such things as a correct dedicated US zip code field, and a
correct dedicated UK postcode field.

------
tiglionabbit
A lot of these things are only common mistakes because of Django's unusual
behavior.

> POST to views loses POST data

The middlewares shouldn't be redirecting POSTs then! They could have returned
a client error instead.

> Blank object names

They could have provided a fallback of __class__.__name__.

> Integer & NULLS

If the admin interface knows the field is required, why does it even attempt
to insert a null value? It could return a validation error.

> Appending to a list in session doesn't work

Django's behavior with ORM relationships has always disappointed me. There's
no way to work with them in memory like in SQLAlchemy because they always
attempt to sync out changes to the database immediately. As a result you often
have to write some very strange code. They could change this.

> Errors about undefined attributes with one-char names

They could have done a type check to see if you passed a string instead of an
iterable of strings.

...etc.

To me, the Django project exudes the stubbornness of the developers who
maintain it because rather than fixing these problems they've decided to write
this page about how it's you, the user, who is wrong.

~~~
pure_ambition
> To me, the Django project exudes the stubbornness of the developers who
> maintain it because rather than fixing these problems they've decided to
> write this page about how it's you, the user, who is wrong.

Sounds like you're doing the same thing. You have a set of expectations about
how the world works that is not the exact same as Django's - which is true of
any other tool anyone uses.

Also I want to point out that software is not made by a monolithic entity;
it's made by people, and you suggest a few simple things like adding type
checks and validations, which would be a wonderful opportunity to contribute!
In fact, opinions such as yours are enormously helpful to the creators of
software frameworks. Software doesn't build itself; if you have ideas,
contribute!

~~~
tiglionabbit
Back when I was interested in Django I'd go to Python meetups and hear people
complain about how the Django project would not accept their patches. They
told me that third party changes never make it into Django. That "contrib" is
a lie, and that it's made almost entirely by core developers.

Ultimately I found Django to be more trouble than it's worth. I only use it if
my work forces me to. I find its design to be obtuse and unpleasant in many
places.

------
alasdairnicol
Django’s documentation is excellent, but parts of the wiki are out of date.

This page has barely been updated in the last four years. It mentions
MIDDLEWARE_CLASSES (deprecated in Django 1.10) and using strings in url()
(deprecated in Django 1.8). There may well be other bits which are out of
date.

The entries in the faq [1] are more likely to be kept up to date.

[1]:
[https://docs.djangoproject.com/en/2.0/faq/](https://docs.djangoproject.com/en/2.0/faq/)

~~~
cimmanom
The wiki (at code.djangoproject.com/wiki) is community-maintained, and not
part of the official documentation, and yes, very often out of date.

The official documentation (at docs.djangoproject.com) is scrupulously
maintained, and excellently written.

~~~
alasdairnicol
Thanks for the clarification. My point was that this wiki page is out of date
so probably not that useful. I could have been clearer that the wiki is not
part of the official documentation.

------
n0us
If you're writing a REST api, invest the time to learn Django Rest Framework.
It is well worth it.

~~~
akx
DRF is nice enough 90% of the way, but when you need to do something that its
authors haven't really thought of, you need to dig in very deep to fix things,
I've found. :/

~~~
douglaswlance
If that's the case, you should take a step back and think about it from
another angle to make absolutely sure that you're not attacking the problem
from the wrong vector.

~~~
dwaltrip
I have heard great things about DRF, and often it is good to resist coloring
outside the lines.

That being said, your comment assumes that DRF has indeed thought of
everything. All abstractions leak, some more than others. Clean escape hatches
are very valuable.

~~~
douglaswlance
I never said that you MUST be thinking about it wrong. I just said to make
sure you're not thinking about it wrong. No framework has thought of
everything.

~~~
dwaltrip
Ah, my bad, I should have noticed that.

------
adpirz
My favorite opinionated boilerplate for new Django projects:
[https://github.com/pydanny/cookiecutter-
django/](https://github.com/pydanny/cookiecutter-django/)

From the author of the great Two Scoops of Django series.
[https://www.twoscoopspress.com/products/two-scoops-of-
django...](https://www.twoscoopspress.com/products/two-scoops-of-django-1-11)

Two great ways to avoid some newbie mistakes. Although some could argue diving
into boilerplate without understanding it is in fact a newbie mistake itself.

~~~
btown
As a word of caution - the authentication framework used in this boilerplate,
Allauth, is opinionated and badly documented. Expect to do code dives if you
use this.

~~~
adpirz
That’s actually the one thing I throw out immediately when I use this for
precisely that reason.

------
purrpit
Maybe not just Newbies, but I often notice even seasoned Django developers
cribbing about Django's Class Based Views (CBV). I don't really understand why
to be honest. There are many blog posts that express regretting the time
invested in CBV by their respective authors by pointing out all sorts of
pitfalls they fell into during usage. My ex-boss hates it as well, he even
banned it from usage among developers. IMHO, it's was a great new introduction
in version 1.3.

I hear them discuss about the difficulties and time it takes to implement some
views which involves complex logic and more than one entity per view. How to
embed a Form inside a Paginated page for example: to use a FormView or to use
a ListView or both, followed by a long day of trying to exit a maze full of
dead-ends

My advice to Newbies and other people who are struggling with CBV is:

1: You are probably not struggling with the concept of class based views..
just with Django's generic views module

2: Stop stressing about not being able to understand what each Django generic
view class does, or it's Mixin classes. Instead refer to ccbv.co.uk and source
code extensively - not just the docs.

3: If you are not able to fit every logic you want to fit inside your view
using a generic Django view class.. Then just spin up your own class from
Mixins or django-braces like nice apps or from object.

4: Remember, one basic upgrade you get from using Classes vs Functions is the
ability to extend. If your views can not take advantage of this then you
probably don't need a class based view, function based is fine. I almost
always keep a base view class with me, often call it a ContextMixin(object)
and use it in every view so that i can have some common context variables
available in my every template.

~~~
ricw
Or just don’t use class based views. Simple function views do the job just as
well while not obscuring code “behind a magic wall”.

------
alexbecker
I don't remember running into any of these issues learning Django or
maintaining a Django codebase, but I've written the problems I ran into:
[https://alexcbecker.net/blog/django-is-
dangerous.html](https://alexcbecker.net/blog/django-is-dangerous.html)

In general, I think Django makes it way too easy to shoot yourself in the
foot.

~~~
acdha
“Validation defined on the model is only enforced on the form” hasn't been
true since 2010 when Django 1.2 was released. Most of the database-related
discussion shares that pattern of either being factually incorrect (“queries
can't use computed columns”), blaming Django for MySQL's many problems or
failing to fix problems caused by other code failing to do things like input
validation.

There's a real discussion about how to handle such issues on large, complex
codebase but hiding it behind a clickbait title is not a good way to have that
end up anywhere productive.

~~~
alexbecker
You must not have read the section "Validation defined on the model is only
enforced on the form". The validations I referenced, e.g. `choices`, are only
run in when
[`full_clean()`]([https://docs.djangoproject.com/en/dev/ref/models/instances/?...](https://docs.djangoproject.com/en/dev/ref/models/instances/?from=olddocs#django.db.models.Model.full_clean))
is called, and it's not called on `save()`--it is usually called through form
validation.

Regarding computed columns, it looks like the specific issue I ran into
repeatedly was [fixed in
1.8]([https://docs.djangoproject.com/en/2.0/releases/1.8/#query-
ex...](https://docs.djangoproject.com/en/2.0/releases/1.8/#query-expressions-
conditional-expressions-and-database-functions)). I should have been explicit
that I was referring to not being able to define such computed columns on the
model the way one would a normal column, not to being unable to use
`F`-expressions.

~~~
acdha
> You must not have read the section "Validation defined on the model is only
> enforced on the form". The validations I referenced, e.g. `choices`, are
> only run in when
> [`full_clean()`]([https://docs.djangoproject.com/en/dev/ref/models/instances/?...](https://docs.djangoproject.com/en/dev/ref/models/instances/?...))
> is called, and it's not called on `save()`--it is usually called through
> form validation.

In addition to being wrong about whether I read your post, this is a great
illustration of what I found tedious while reading it: since that feature was
released in Django 1.2, the documentation has been clear about the
relationship between save() and full_clean():

[https://docs.djangoproject.com/en/2.0/releases/1.2/#model-
va...](https://docs.djangoproject.com/en/2.0/releases/1.2/#model-validation)

[http://django.readthedocs.io/en/1.2.X/ref/models/instances.h...](http://django.readthedocs.io/en/1.2.X/ref/models/instances.html#validating-
objects)

The direct statement of fact you used as a heading simply hadn't been true for
years before you wrote your post and it's not helped by little mocking asides
such as “Because nobody ever modifies a model instance expect through its
form, right?” which are basically restating the reasons why that feature
exists in the first place.

> I should have been explicit that I was referring to not being able to define
> such computed columns on the model the way one would a normal column, not to
> being unable to use `F`-expressions.

Strong agreement here. Your post could have been so much more useful if each
of the mocking asides had instead been taken as a cue to ask whether it's more
likely that so many people have worked on Django for years without noticing
such a major flaw or that your understanding of how it was intended to be used
is incorrect.

Imagine if your post had been something like “Things I learned about Django
the hard way” and had covered things like picking safer defaults or updating
the docs to more explicitly suggest how validation is intended to work
(especially in this age where people use fewer forms and more APIs than a
decade ago), or that Django treats the database as the ultimate source of
truth so you should approach various things about validation and transactions
with that in mind (e.g. strengthening the the wording to make it clear that
e.g. get_or_create relies on database integrity checks so you should either
set those or religiously use some other strategy). That post could be a
DjangoCon talk and it'd get a lot more positive reaction than another angry
rant on an internet full of them, especially since people in the community
would be likely to share it rather than seeing a big claim which is not
correct and closing the tab.

~~~
alexbecker
Back when I was working on Django codebases, I saw almost no use of
`full_clean()`, largely because _some_ validation was performed on `save()`
(by virtue of being database constraints, e.g. non-nullability) while other
validation was not, and there was no indication in the APIs which was which.

In a world in which Django applications were always written by people who read
and understood the docs in full, I would totally agree with you about these
criticisms. But I've never had such an opportunity outside of my own projects.
I've only dealt with codebases that were written with falty assumptions,
_enabled by Django 's choice_ to hide some but not all tricky work from its
users. By then the database constraints would be incredibly painful to add
since there was lots of data already violating it, and switching global
defaults like ATOMIC_SAVE were nearly as bad since code had widely relied on
other behavior.

------
vivan
I absolutely love Django's documentation. As a desktop developer looking to
get more into web stuff, Django has been super attractive as a backend to get
my hands dirty with.

------
mixmastamyk
Django is great at being "batteries included," with tons of functionality for
free. One thing that bugs me about these frameworks however is that you have
to wire _everything_ together by hand, sometimes from both sides.

Would be great if there were a product built on top that let you drop a model
or a view file in a folder and everything would be wired automatically for the
default case, customizable later of course.

~~~
iliaznk
Django Rest Framework is getting close to that.

~~~
nnq
Huh?! Any moderately complex usage of DRF requires tons of boilerplate, or ton
of app-specific abstractions... Also, just having to _write_ a view, then a
_serializer_... to _actually write it!!_

Imho the ideal framework would work with a models definition, json or yaml,
not code, with extra anatotions for everything needed to have the logic of
stuff like serializers and views instantiated from them. And keep the "custom
behaviors" _code_ fully separate from this models config, preferably in some
modules with stateless and mostly pure function, sort of the serverless
mindset, and not too much oop bullshit on top.

Rails and all the frameworks that copied it (Django, Laravel etc.) set a
really _bad example_ imho...

~~~
iliaznk
Well, of course complex and specific stuff will require more boilerplate, but
if you just need a basic CRUD on a model – just define a view set and you're
done, URLs and methods will be created automatically.

------
WorkLifeBalance
I doubt it's still the case but for a long time the default "Authorization"
was effectively fail-open so a newbie mistake was to use that and then not
customize it leaving your API vulnerable to any logged in user reading
anything.

There was a bright red box effectively saying "Don't use this module without
customizing it" in the documentation but that didn't stop newbies going live
with it in place.

------
topstriker515
My standard tool for quickly spinning up a web app is Rails, but recently I've
been writing a lot of python for data projects and I'm thinking about spending
some time learning Django. Rails development seems to be going strong though
and has me a little worried. Can anyone speak to Django development and its
ecosystem in 2018?

~~~
paulhallett
Django in 2018 is still a very vibrant and active community. The project is
actively developed, there is a lot of sponsorship from big companies
(instagram etc) funding a dedicated fellow who's job is to work on Django
full-time.

The plugin ecosystem is very rich and active too - almost always a pre-made
package for some feature or implementation you want to add to Django.

------
rrauenza
Is _mylist = []; mylist == []_ really a thing for testing for an empty list?
Seems very unpythonic.

My newbieish mistake was assuming (forgetting!) that NULLs aren't
distinct/unique, so you can not enforce a nullable column unique and expect
only a single NULL value. There is a way around it with conditional
constraints ... but _unique=True_ or _unique_together_ is not it.

It's really an RDBMS thing, not a Django thing, but when Django abstracts away
the RDBMS, one forgets.

------
mgkimsal
> current_zip = meta.IntegerField(max_length=5, null=True, blank=True)

This is given as the 'correct' way?

Storing a ZIP code as an integer? What does an 'integer' length of 5 mean?
Integers have max values, not lengths.

"The django docs are so great! They educate you!"

I'm presuming most people aren't being sarcastic when they post that sort of
sentiment, but it's hard to take those endoresements seriously.

~~~
ubernostrum
Someone dug up a 13-year-old page from the community wiki and presented it as
"this is totally the official Django documentation".

I've added a gigantic warning at the top of it to address this. See also my
other comments in this HN thread, for the right way to do what that particular
example was trying to do.

~~~
mgkimsal
Thanks... ?

Having dates on the pages would probably help avoid some of this in the first
place.

People point to a lot of the PHP comments in their docs as "bad" (and many
are) but they're also dated, and you can use a comment date of 2009 when
trying to give weight to how relevant/useful something may be.

"blank=..." anything is, imo, more confusing than "required=", regardless of
what version/age of the docs though.

~~~
ubernostrum
The issue is: what would you list as the date?

Apparently some other people noticed this was on HN, too, so there are minor
edits from a few hours ago, but the bulk of the information is still a decade
old. Would you stick a date on every paragraph?

(personally I'd forgotten that this page even existed)

~~~
mgkimsal
"Created on" and "last modified".

I see last modified way at the bottom of a long page in light grey.

I did not even notice it was a wiki until others point it out.

Biggest text on the page says 'code'. I plead nav-blindness to not seeing
'wiki' in the floating navbar.

Perhaps a date on every block section?

Or... something that throws a big block at the top if the last edit was more
than 2 years ago?

~~~
ubernostrum
Honestly I'm not convinced it's worth the amount of work involved in doing all
this, and the number of places available for people to share tips/tricks/etc.
has drastically increased since 2005. So if it were up to me the wiki would
either go away, or become read-only with prominent "only for historical
purposes, don't use information here" warnings.

But I'll think it over.

~~~
mgkimsal
i was meaning probably more in a general sense, not so much for this
particular page. the notice at the top of that specific entry does the trick.
a notice at the top of all wikis which aren't intended as the 'official word'
indicating such would mitigate a bit of this sort of confusion.

------
koyote
This is very useful for beginners.

I hope more frameworks/languages have a page of common "gotcha's" in their
documentation in the future. Then again, it's sort of a right of passage to
spend a couple of hours debugging common mistakes when you're learning
something new: you'll definitely not repeat your mistake in the future that
way :)

------
megasquid
Shout out to the IRC #django freenode community. What a helpful group of
people if you get stuck, thanks FunkyBob wherever you are.

------
stesch
Please don't ever use integers for ZIP codes. In Germany there are ZIP codes
(Postleitzahlen) that start with a 0.

~~~
ubernostrum
Please don't use examples on a 13-year-old community wiki as recommendations,
period!

See the many other comments I've made in this thread for how to handle
elements of postal addresses in Django.

~~~
digianarchist
"Newbie Mistakes" \- this will be read by new people and taken as good
practice. They should change these examples.

------
maerF0x0
From my perspective there's little reason to be building html serving
webservers these days.

1) Frontend React+Redux paired with an API (eg golang http server serving
json)

2) Your boss is going to want "APIs!" soon anyways. le sigh.

3) IMO its as easy to do a JSON API HTTP server in golang as python, but you
get typesafety, compiled code and multicore ...

~~~
jnbiche
> React+Redux paired with an API

For building a REST API, there are no frameworks or languages I know of that
are easier, quicker, or more user-friendly than Django REST Framework. I say
this of someone who is not a big fan of Django in general (although it's not a
bad framework).

However, I wish that Django REST Framework were build on top of an async HTTP
server. Although it's never been an issue, I've occasionally in the past felt
uneasy building APIs on top of Django since I know beyond a certain point
scaling will be an issue. But either fortunately or unfortunately, I've never
had that problem.

~~~
swah
I'm trying DRF now (last project in Golang) and one point I have no idea which
way to go is how to deliver updates to the mobile client (avoiding polling
every N seconds).

I'm not sure I want to try Django channels, which comes with its own spec
(ASGI?) and possibly changes the entire way the Django application is run[1].

Should I go with Django channels or - my alternative idea - deploy a separate
Golang server only for "real time updates" ? Then I can send updates by simply
POSTing from Django to Golang, which forwards the update to the mobile client.

[1] For example:
[https://channels.readthedocs.io/en/latest/topics/databases.h...](https://channels.readthedocs.io/en/latest/topics/databases.html)

------
jonwinstanley
These are great tips, but maybe they should be on separate pages so Google has
a better chance of matching them up to search queries?

------
myf01d
Django is a hell for APIs and big projects. It's good for beginners and small
projects, but once you need the least amount of actual control, you will find
it's too late

~~~
BozeWolf
I read this a lot, but I do not agree. Worked on quite large (and busy)
websites, did not experienced problems with exactly that. And if the project
really is that large, perhaps it is time to split things up? (I intentionally
avoid the term microservices, because there are more ways to split things up.)

Actual control... where? And why is it too late? Too late for what?

You can get actual control everywhere if you want to. Doing raw sql queries is
perfectly possible. Rendering with jinja instead of django's template system
is possible. Speaking to redis directly: possible. Returning a string instead
of something rendered: possible.

Heck, even speaking to the django db from another project with sqlalchemy
worked out quite alright.

A big problem in large projects is too many queries per view, or unoptimized
queries. Django's orm often gets the blame. But I did see that happen with
ORMs in other frameworks as well (flask, bottle although an orm is optional).
Even raw sql. Another nice feature of django 2.1 will be the .explain() method
on querysets. Im using 2.1 to debug queries now and switch back to 2.0 when
things are speedy again.

Another problem is having way too many unused variables and unclear calls to
database from templates. But that is also a big problem in flask etc.

I think it is a myth Django is a hell for big projects, there are plenty big
companies and websites which prove im right. Of course there are struggles.
But those struggles are there with other python frameworks as well.

A lot of work happens quickly beyond the framework you use anyways. When a
website grows many background jobs have to run or many business rules have to
be programmed at some place. This does not have to do with the framework and
often times just happens to become messy. I think of the work i do in django
projects 30% is django related 70% is django unrelated.

You can consider to use another _static_ language and framework for speedups,
like play or something. But i think the parent poster meant Django is a hell
compared to other python frameworks.

I do wish django could do some async stuff, like the play framework does. It
would be just nice to fire off a few db queries and resize an image and just
wait for the result at the moment you build the response. But other than that
it is superb!

~~~
cimmanom
Async may be in the works: [https://groups.google.com/forum/#!topic/django-
developers/Kw...](https://groups.google.com/forum/#!topic/django-
developers/Kw7-xV6TrSM)

------
jaffee
I feel like I just got into a time machine - this is the top post on hacker
news? People are _learning_ Django in 2018?

I guess its fine if you have a small project and aren't going to see much
traffic, but Python is so slow and difficult to maintian compared to (e.g.)
Go. I say this as someone who worked in Python for a long time, and on several
large Django projects.

~~~
cosarara
Does go have a web framework that does as much for you as django?

~~~
djstein
I know this was rhetorical, but no, it doesn't

