41–50 of 225 posts
If you're writing a REST api, invest the time to learn Django Rest Framework. It is well worth it.
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. :/
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.
Does go have a web framework that does as much for you as django?
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.
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.
Now that I really think about it, one annoyance I have with the django docs, is that they don't show you the import path for the modules used in examples. Though it's usually just 30 seconds of searching to find it.
> 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.
If you're writing a REST api, invest the time to learn Django Rest Framework. It is well worth it.
Isn't Flask simpler for REST stuff?
For a simple CRUD API, if you already have a cookie-cutter template of your REST API sketched out with Django Rest Framework, you can write your models and you're done.
Earlier quoted context omitted.
What are the bad bits? Why are they bad?
Too many issue to enumerate them here, but there are just a lot of things that are likely to lead to security vulnerabilities or hidden performance problems. I'm planning to write a blog post on this in the next few weeks.
If you're writing a REST api, invest the time to learn Django Rest Framework. It is well worth it.
Isn't Flask simpler for REST stuff?
Flask is indeed much simpler, and serves the needs of smaller apps very well. The reason I've stopped using it is because I'm now familiar enough with Django's substantial, problematic learning curve that building a Django project is now just as easy for me as spinning up a Flask app (django-cookie-cutter and wagtail's project init help with this, but they're no replacement for several years of smashing your head against bad Django code). While I love Django, and have derived much utility from the tools it gives me, it's not the solution to all problems, and there are times when Flask makes total sense.
But once Flask's simplicity advantage is removed by experience, I find that it's immensely useful to have (largely correct) opinions on ORMDB interactions, templating, settings/config management, form validation, and user authentication baked into the project. For my projects, having these has never cost me anything even if they go unused, and more than once I've gotten myself into the situation of "You either use Django or build Django"
All of the above applies even more so to the specific task of producing a rest API. DRF is, by a large margin, my favorite tool for producing robust, understandable APIs, and I've been lucky enough to never encounter the scaling issues that I've been told (and believe to) exist.
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…
It does do that
> Integer & NULLs
If you say `blank=True` you're telling the admin it isn't required
> Appending to a list in session doesn't work
99% of the time I never do anything with sessions and I can't think why you would without side effects in any case
> One-char names
That could be type-checked and type hints will probably be added at some point now Django 2.0 drops Python 2 support
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.
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.