Bumped Django-Filter to 2.4.0.
This was a security release. NumberFilter instances were subject to a potential DoS for numbers with very large exponents, if those were later convert to integers. We added a default MaxValueValidator with a limit of 1e50, which is plenty big enough for most use-cases. (Also hooks to customise that if you need to.)
Update recommended.
I like the way Django and DRF handle versioning. In X.Y.Z, Y is the major release, implying You may need to make some adjustments here.
For DRF X is saved for bigger changes, but it’s unlikely they’ll ever be a DRF v4 on this scheme. With Django time-based release schedule X just means it’s been 2 years since the last one.
However, because X.Y.Z looks like SemVer, every time we get folks outraged that we’ve broken BC on a point release. This should be a major version change, they shout.
For django-filter this get’s to the point of being nonsensical. The library is so small and stable that any change, even clear bug fixes prompt You broke it!. The only solution then is to bump X every time. No problem there: number are cheap. But the version then ceases to make any sense.
As such, the next version of django-filter will use CalVer, so it would have be 20.9.0 this time. We end up bumping X at least every year, but at least it still carries some information.
I would have done it this time but... grrr... grumble... GitHub.
GitHub has these Security Advisories. They’re a good idea I suppose, but they seem half-baked:
20.9 this time but I drafted the advisory on GitHub as 2.4 and couldn't then edit it so...I do kind of wish GitHub wouldn’t try to be everything. It doesn’t feel healthy. They’ll stumble, the commons will have been destroyed, and we’ll be in a strictly weaker position overall.
We had a good call with Micheal Kennedy of Talk Python for a Django Chat that’ll be with you soon.
He had this idea of Python as a “full-spectrum language” that I really liked — it’ll take you right from beginner to wherever you need to go.
Inevitably we got round to talking about async.
As much of an unneeded complication as it is for so many day-to-day use-cases, it’s important for Python because, if and when you do need the high throughput handling of these io-bound use-cases, you don’t want to have to switch language.
The same for Django: most of what you’re doing has no need of async but you don’t want to have to change web framework just because you need a sprinkling of non-blocking IO.
You might well choose a different language or framework if you’re doing lots of this stuff but Python’s not full-spectrum if it can’t accommodate you. Likewise Django’s not batteries included if we don’t have a story to tell there.
I liked this. It ties into the default principle that I’ll be writing about more. This is my default. I’ll use it until I need to change.