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 ๐ค
@felixxm I still can't believe it, I'm in shock since this morning when you told me! You'll be greatly missed, your absence will be profound. I'm sure you'll excel at anything and everything you do next. ๐
Yesterday I read all the amazing applications from the twelve candidates, and I was thrilled with the diversity, ideas and energy that they could bring to the board.
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.
@carlton@sarahboyce@djangochat@wsvincent
What I like a lot about CalVer is that it clearly conveys the message that "this is an scheduled release", as opposed to "this is a release because <this super feature was completed>".
Ep149: Becoming a Django Fellow with Natalia Bidart is live!
@nessita is a developer from Argentina who is the newest Django Fellow. We discuss her background in computing, her career at Canonical, consulting, and getting up to speed on the Django Fellow role.
@shaib Thank you, I'm looking at the repo right now.
While this is helpful, is not quite solving my need: I seek a way to diff between two hashes (hash1 and hash2), where hash1 is an improved patch against main (which original patch is hash0), and hash2 is the result of the cherry-picking of hash0 into a stable branch.
Specifically, this is to "backport" review fixes or improvements from an existing patch (still in review) to other patches. A diff of diffs I guess ๐
@carlton@shaib I completely agree! Though this was my first security patches batch so did all of them from the beginning to get a sense of the complexity involved and plan around that.
I got asked about using .save over .create in #django and wanted to put my thoughts down in some longer form about my experience. Anyone else using .full_clean and .save instead of .create? Are you a .create fan? How do you choose?
@tykling@emattiza As a Django developer, the distinction is clear to me in that save means to store (in the database) and says nothing about validation. I consider it "lower level" tan create and quite handy when needing to store objects crafted manually.
The other important difference which signals a difference in semantics and behavior, is that save is an instance method, while create works "at the table level." I hope this makes sense! (I had to summarize due to char limits)
@tykling@emattiza@valberg Yes, I can. From the top of my head (and these are real cases I've dealt with in my professional career) : 1. Tests, when intentionally creating instances in borked/legacy state to build specific scenarios, 2. On management commands that may do different processing at different stages, 3. (less common) When needing to optimize a potentially expensive validation or check and you need full control, for example to do it in bulk, or with async/tasks, etc. Does this help?
Besides the tests argument, I provided two more, which to me are quite relevant.
Secondly, yes, I can honestly say that I do believe that skipping validation is a good default because of the decoupling in validation -> persisting of the data. Just like with forms, if form.is_valid(): form.save(): saving a ModelForm will not run the validations.
Lastly, IMHO, if there is a validation that you must enforce at all costs and no matter what, I'd rely on DB checks/constraints.
