6 ms·

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

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.

kennydude 8y ago
> They could have provided a fallback of __class__.__name__. 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
paulhallett 8y ago
Up until 90 minutes ago the previous change to this was 8 months ago. Before that it was 4 years ago. I think you might be complaining about out of date documentation :) Given django's docs are impressive, I doubt this is used actively by people.
- mrguyorama 8y ago
  I use django at my day job, every day for the past two years. I didn't know this page existed, and better yet, I've never run into these problems
falsedan 8y ago
> 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. I sometimes feel that, similar to how perl's motto is "There's more than one way to do it", some python developers have converged on an unofficial mottot of "You're doing it wrong".
- Daishiman 8y ago
  Because... they are? I mean look, for the most part developers have optimized a happy path that is by far, one of the most productive ways to get anything done in the web dev world. If you're purposely going to go against that path for whatever reason, you're going to have to do the heavy lifting that the framework is doing for you. In the 9 years I've been using Django, I've rarely if ever come to a situation where there was any benefit to working against the framework's idioms. And the more I've grown to using the framework, the more you realize that people would rather create their own thing from scratch rather than learn existing methodologies.
  - falsedan 8y ago
    > Because... they are? The lack of self-instropection & hubris in some framework's devotees is astonishing. If someone is attempting to solve a problem, and their approach is not well-suited to the framework, perhaps it is the framework's fault? Perhaps suggest an alternative tool rather than telling the person they haven't come up with the 'best' approach (which is the version that the framework is well-suited to solve)? I feel that a lot of the time this defensive "you don't understand the problem" conversations are from devs who have invested a lot of time in the framework & have internalised their expertise into their sense of self-worth, such that 1.) they don't have much experience with other frameworks/approaches which may be better suited to the questioner's problem; 2.) admitting to a failure or gap in the framework becomes equivalent to admitting to a personal failure. I wish we had less ego in programming, and more decisive, clear declarations of intent and limitations in frameworks.
    - 8y ago
alasdairnicol 8y ago
> The middlewares shouldn't be redirecting POSTs then! They could have returned a client error instead. This has been fixed since Django 1.0, released in 2008. The page links to the commit that fixed the issue.
purrpit 8y ago
>> POST to views loses POST data >The middlewares shouldn't be redirecting POSTs then! They could have returned a client error instead. It does raise RuntimeError during development >> 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. Maintaining integrity is databases' job primarily, also I could have triggers and functions inside my database to fallback to some default value when there isn't one incoming. This isn't an uncommon setup. >> 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. Where did ORM come from? Session backends are not exclusively written to be stored in databases. >> 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. This way they'd have to type check at thousands of other places where types are assumed. If one isn't comfortable with python's syntactical sugar coatings - inevitably leading to some syntax gotchas, then they should move to more statically typed language.
ibejoeb 8y ago
> > 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. There's a lot going on here. In this case, you're telling the admin interface that nothing is required of the user. There could be a default value, for example. On the more technical side, blank and null are different concepts that are codified differently in different database systems. Here, in most systems, a integer attribute is nullable. If it were a string attribute, however, there are cases (Oracle) where null and the empty string are not distinguished, which is rather sensible for text. This separation supports all of these modes. I'll give you that `blank=True` lives in the wrong place in today's Django, but it was an early design and it stuck.
pure_ambition 8y ago
> 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 8y ago
  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.
ubernostrum 8y ago
Someone apparently decided to link a 13-year-old unmaintained community wiki page on HN. I've added a big note at the top of the page explaining that, and providing a link to the actual Django documentation.
c0un7d0wn 8y ago
Definitely agreed regarding django orm. And moment you decide not to use it or cannot use it because of legacy issues you're in a world of pain. We've developed https://github.com/shosca/django-rest-witchcraft https://github.com/shosca/django-rest-witchcraft and https://github.com/shosca/django-sorcery https://github.com/shosca/django-sorcery as the project was already using django+sqlalchemy and doing everything manually and also had to touch legacy db's (think composite pk's and all kinds of db quirks..)

kennydude 8y ago

> They could have provided a fallback of __class__.__name__. 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

paulhallett 8y ago

Up until 90 minutes ago the previous change to this was 8 months ago. Before that it was 4 years ago. I think you might be complaining about out of date documentation :) Given django's docs are impressive, I doubt this is used actively by people.

mrguyorama 8y ago
I use django at my day job, every day for the past two years. I didn't know this page existed, and better yet, I've never run into these problems

falsedan 8y ago

> 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. I sometimes feel that, similar to how perl's motto is "There's more than one way to do it", some python developers have converged on an unofficial mottot of "You're doing it wrong".

Daishiman 8y ago
Because... they are? I mean look, for the most part developers have optimized a happy path that is by far, one of the most productive ways to get anything done in the web dev world. If you're purposely going to go against that path for whatever reason, you're going to have to do the heavy lifting that the framework is doing for you. In the 9 years I've been using Django, I've rarely if ever come to a situation where there was any benefit to working against the framework's idioms. And the more I've grown to using the framework, the more you realize that people would rather create their own thing from scratch rather than learn existing methodologies.
- falsedan 8y ago
  > Because... they are? The lack of self-instropection & hubris in some framework's devotees is astonishing. If someone is attempting to solve a problem, and their approach is not well-suited to the framework, perhaps it is the framework's fault? Perhaps suggest an alternative tool rather than telling the person they haven't come up with the 'best' approach (which is the version that the framework is well-suited to solve)? I feel that a lot of the time this defensive "you don't understand the problem" conversations are from devs who have invested a lot of time in the framework & have internalised their expertise into their sense of self-worth, such that 1.) they don't have much experience with other frameworks/approaches which may be better suited to the questioner's problem; 2.) admitting to a failure or gap in the framework becomes equivalent to admitting to a personal failure. I wish we had less ego in programming, and more decisive, clear declarations of intent and limitations in frameworks.
  - 8y ago

alasdairnicol 8y ago

> The middlewares shouldn't be redirecting POSTs then! They could have returned a client error instead. This has been fixed since Django 1.0, released in 2008. The page links to the commit that fixed the issue.

purrpit 8y ago

>> POST to views loses POST data >The middlewares shouldn't be redirecting POSTs then! They could have returned a client error instead. It does raise RuntimeError during development >> 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. Maintaining integrity is databases' job primarily, also I could have triggers and functions inside my database to fallback to some default value when there isn't one incoming. This isn't an uncommon setup. >> 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. Where did ORM come from? Session backends are not exclusively written to be stored in databases. >> 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. This way they'd have to type check at thousands of other places where types are assumed. If one isn't comfortable with python's syntactical sugar coatings - inevitably leading to some syntax gotchas, then they should move to more statically typed language.

ibejoeb 8y ago

> > 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. There's a lot going on here. In this case, you're telling the admin interface that nothing is required of the user. There could be a default value, for example. On the more technical side, blank and null are different concepts that are codified differently in different database systems. Here, in most systems, a integer attribute is nullable. If it were a string attribute, however, there are cases (Oracle) where null and the empty string are not distinguished, which is rather sensible for text. This separation supports all of these modes. I'll give you that `blank=True` lives in the wrong place in today's Django, but it was an early design and it stuck.

pure_ambition 8y ago

> 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 8y ago
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.

ubernostrum 8y ago

Someone apparently decided to link a 13-year-old unmaintained community wiki page on HN. I've added a big note at the top of the page explaining that, and providing a link to the actual Django documentation.

c0un7d0wn 8y ago

Definitely agreed regarding django orm. And moment you decide not to use it or cannot use it because of legacy issues you're in a world of pain. We've developed https://github.com/shosca/django-rest-witchcraft https://github.com/shosca/django-rest-witchcraft and https://github.com/shosca/django-sorcery https://github.com/shosca/django-sorcery as the project was already using django+sqlalchemy and doing everything manually and also had to touch legacy db's (think composite pk's and all kinds of db quirks..)