class-based views (CBVs) or function-based views (FBVs)? 🤔
I started with function-based views, but after a few years of using Django I pretty much moved fully to class-based views. Both have pros & cons (and vocal advocates).
The Django docs introduce FBVs first and then discusses CBVs as well as Django's built-in "generic class-based views" (GCBVs).
Django-REST-Framework also makes heavy use of CBVs.
In the latest @djangochat, @nessita discussed how her non-Django friends were underwhelmed by the features in #Django5.0 — the major version is meant to mean some big breaking change.
@wsvincent has discussed numerous times how the X.0, X.1, X.2 LTS, Y.0, … cycle is confusing.
But how could we change it? The X.2 tells you WHICH ONE is the LTS.
The 24 month cycle means that if we went CalVer (say) the .4 would always be the LTS, so 23.4 (4.2) 25.4 (5.2) and so on.
If you call update_or_create where the instance already exists and the defaults passed in are already the values on the instance, do you ever want it to actually re-save the instance?
I'm running into the case where I'd prefer it to not update the instance if it doesn't need to. I'm guessing I'm overlooking some race condition problem though.
My #Django magic wand would disable checks running on all the things by default unless explicitly turned called or turned on.
Q: Why does it take so long to run manage.py for my project?
A: Django's manage.py runs checks which scan every Python file by default with apparently no cache and takes double-digit seconds to minutes for non-trivially sized projects with no easy way to disable. You can pass --skip-checks. https://indieweb.social/@adamghill/111714833371229206
A tool that allows you to rapidly test and compare various indexes against a queryset or known view.
It then would configure the db, and run the queryset, store results, run explain analyze, store that, move onto the next and do the same, then at the end present and annotate the results.
I've decided to retire from being a Django Fellow at the end of March 2024. It's a great honor to be a Django Fellow. I've spent the last 5 years in my dream job 💚 🦄 but it's time to move forward 🔭 I'm not abandoning Django completely, nothing like that 🤗. I will continue to be an active member of our amazing Community and do my best to help it grow 💓
I'm open to new positions from April, 1st, so contact me if you need someone with my expertise 🤝
I just wrote this proposal that #Django’s third-party package tutorial recommend using a django_ module prefix to prevent name collisions, such as the historical one between django-ratelimit and ratelimit.
✨ If you use #django and don't know about django-extensions' show_url management command, it's the cheatsheet you didn't know you needed... or you knew you needed but didn't know what/where to look for it at.
It saves me tons of time and frustration when figuring out what a view is named from a third party app.
My latest article shows how to smoothly propagate Database Changes in Blue-Green Deployments 💙 ➡️ 💚 using #Django migrations :django: Check and share! #article#deployment#Python
I've just written a #Django async view returning a StreamingHttpResponse which streams the results of PostgreSQL LISTEN/NOTIFY messages as Server Sent Events. The future is now, using old tech. All thanks to Django 4.2 and psycopg 3 🫶