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!
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.
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
> 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.
>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.
I've added a big note at the top of the page explaining that, and providing a link to the actual Django documentation.
This has been fixed since Django 1.0, released in 2008. The page links to the commit that fixed the issue.
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.
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".
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.
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.
Synchronous web development in dynamic programming languages is, for all intents and purposes, a solved problem. The conceptual differences between Django, Rails, Laravel and so on are minuscule; there's a bounded number of ways to get a web request and spit out HTML.
It is an extremely well understood problem domain where escape hatches to go against idiomatic framework conventions have been built at all levels and are actually used judiciously by people who have an understanding of the tool's shortcomings.
And in the same spirit, I can say quite confidently that people that are trying to reinvent the wheel here have a non-zero, but minimal, chance of actually hitting a significant roadblock.
> 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.