Not SICP as a teen, not the Haskell Book, not The Art of Unix Programming, not A Philosophy of Software Design. Those are all fantastic books, but they were the wrong things to read for someone whose definition of "Keep It Simple, Stupid" was "never build anything at all and stay unemployed". Django got me to shut up and build.
And build I did, and most of it did and does suck, and that's okay. And then I got a job, not doing Django, but using the things I learned from actually building with Django every day. I owe Django a great deal, and I still think of the DRF as my favorite approach to building a "well-tempered", maintainable API, on a deadline.
From those experiences you not only learn what to do, you get "what not to do" and "ah these parts are useful because of this" kind of information as well.
One edge of Python is its like the modern day Perl in terms of how many libraries you can use with it to get things done. It certainly feels that way anyway.
On the other hand .NET has cool things Python barely scratches the surface on like MAUI and Blazor. Not to mention both MAUI and Blazor are directly supported by a major tech giant.
A few years later I learned Elm and had a similar lightbulb moment, this time for front-end web development specifically.
Learning to build stuff and the excellent explanations he gave are still something I refer back to now as a senior JS dev
In PHP, you can just throw a php file on a webserver and it works. To update, you just update the file. You don't have to restart anything.
On the dev machine, you can just have Vim in one window and Firefox in the other, change code, hit F5, and you see what you did.
I don't like having to run a code watching process which then recompiles the whole codebase every time I save a file.
There is a very natural learning progression to: First build apps that run purely locally; then build a few static websites, maybe starting with hand-crafted HTML and eventually using something like Hugo; then build a small dynamic website with vanilla PHP; then finally build something with a more complex framework, like Laravel or Django. Going upwards in these iterations I think would help a lot ofd newer devs internalize where the tradeoffs of inital complexity vs. future ease of development lands for them.
Rest of the things you mentioned are pretty same for Python as well.
Yes, I could build everything from scratch myself in Python and have the same statelessnes as in PHP. But parsing headers, creating headers etc feels like it should be handled by a framework. In PHP, it is build right in.
And if I would build it, it would talk to the webserver via CGI. But I think CGI is slow. For PHP, you have mod-php which is super fast.
There are various implementations of this kind of autoreload system for Python but it always seems to come with compromises on semantics (different initialization order causes behaviour differences).
Python's import model is not without its flaws either, but at least you have a working application state, no need to fully initialize your app for every single request.
For simple apps that are contained within a few files, PHP is hard to beat for simplicity and speed.
I'm not sure if PHP stores any compiled binary or byte-code at all. Maybe it compiles it all on each request. It's super fast though, even with tons of imports.
My guess would be that it keeps compiled versions of each file in memory and on each request, it walks down the whole import path. And when it encounters a changed import, it compiles only that one.
Would be cool if someone with more knowledge could shed a light on what is actually happening.
PHP code is also typically far less complex than Python modules - modern PHP code consists of a single index.php with procedural code, and everything else is just class / function definitions, so there are no side effects.
(yes I think some js frameworks also allow this)
I don't like having a different webserver in development and production.
Here are some of my hilights from this relase:
* Default on model gets sent to API docs
* Orderedict replaced by plain dicts everywhere - plain dicts are ordered in python since 3.6 so this is a welcome simplification
* Automatic support for UniqueConstraints in ModelSerializers - this is one of the places where DRF were lagging behind. I found myself using the deprecated unique_together just to not bother with writing validators on all my serializers
* There is a new router supporting path converters instead of regexp - Looking forward to trying this out! Also long overdue IMO as this came to Django in 2017 :)
Also, https://www.cdrf.co/ helps with the class inheritance tree.
It really helped me find my way around the inheritance tree as well.
The fact that you can't even have multiple windows in vscode for say your task output is wild to me.
But Jetbrains refactoring tools is where it shines to me.
I don't mich like the strict and inflexible DRF approach.
But great that they keep continuing supporting the framework for the people that like and use it. Or just use it.
That's why I rarely use DRF and either use function based views directly or use another library.
To the devs : well done an Congrats on the release!
Don't get me wrong, I do think Django is one of those deep modules[1] where the interface makes it a pleasure to work with but the internals do need effort. Especially the ORM layer.
[1] https://duckduckgo.com/?q=deep+modules+John+Ousterhout&t=fpa...
I just wish I didn't have to do code contortionism any time I need to support async (or resort to a third party like adrf).
I looks like DRF will never support async.
def return_json(msg: dict) -> HttpResponse:
return HttpResponse(json.dumps(msg), content_type="application/json")
def load_body(request: HttpRequest) -> dict:
return json.loads(request.body.decode("utf-8"))
Edit: Did a drop-in replacement of JsonResponse; confirmed working.
I love DRF for CRUD apis. It just gets the job done and you can Focus on data modelling.
We built our data hub/data Integration solution on top of it. [1] It was a good choice.
By far the most extensible and overridable library I have worked with so far. Even when you need to ressort to hacks, they never seem to break when upgrading a Version.