Weeknotes 2020 WK 41

OMG Timezones

A while back, Python core contributor Paul Ganssle opened a proof-of-concept PR on Django to deprecate use of pytz and move to use of the new zoneinfo module, that was introduced in Python 3.9, with a backport available all the way to Python 3.6.

I got round to taking this on this week. We’re a way from the Django 3.2 feature freeze, but I’m old now, and I like a bit of hustle early in the cycle, rather than right to the wire.

The proposal is to move to using zoneinfo and introduce a shim that is more-or-less backwards compatible with pytz, but which raises a warning when pytz specific methods (localize() and normalize()) are used.

The issue is this would be a breaking change. Even with the shim there’s a semantic difference in how datetime arithmetic is handled over UTC offset changes. Some links:

The bottom-line is that if you're doing datetime arithmetic, and calling normalize() afterwards (which you should be, in case you crossed a DST-change boundary) then you’re going to need to review and update this code if we move to zoneinfo.

I advise you to have a read of the discussion on the django-developers list, and think about these issues. Presumably you’re using pytz. You’re going to need to move away over the next few years. (Paul’s article on the issues with pytz is worth reviewing here.) In your own code, you likely just want to sit down and update, but for a library, and library like Django in particular, where we do all we can to not break your code, the use of pytz-deprecation-shim seems a small cost to pay to help users upgrade.

The currently proposed timeline for all this is:

  • Django 3.2 (LTS): add the ability to use zoneinfo behind a feature flag, for those wishing to opt-in early.
  • Django 4.0: switch to zoneinfo via pytz-deprecation-shim, so that warnings will be raised for the old usage in user code. Doing this after the next LTS allows users to hold-back for a while if they need more time. It also allows folks to upgrade from Django 2.2 without having something else to worry about.
  • Django 5.0: remove pytz-deprecation-shim. Transition complete.

This isn’t seamless. There’s still the breaking change in the semantics, and users will be best served to deal with that early. I’m not sure I can see a better way, though:

  • A hard break would lead to people not updating. This is something we’ve avoided for a few years with Django now, and I don’t want to go back there. If you’re on a supported version now (and for a while) there’s no reason for you not to update every major version. We have to maintain that: people sometimes describe Django as boring — absolutely not — that you can be on the latest version, and have all the latest features, knowing your code is safe, is the very thing that makes it super exciting. These are good times for Django. The API Stability Policy is largely to thank for that.
  • Maybe we could use some other shim, that didn’t lead to a break… — well maybe. But I struggle to think we’re going to come up with a better solution. Many were considered for PEP 615. What’s more, it’s not just Django making the move. It’ll be the whole ecosystem. To the extent that we all do the same thing the transition as a whole will go smoother.

A (proposed) small tweak to DEP 10

I opened a PR on DEP 10 (Django’s governance) to add a Triage & Review Team role.

Theoretically there’s no need for this to be part of DEP 10, except that it covers when a Merger (and by this I really mean Mariusz) may merge their own minor changes.

Rightly, such things need approval, but I’d often arrive on a Tuesday morning to find Mariusz has made a small tweak, approved by multiple regular contributors, but not merged because it needed another Merger’s approval (mine or Claude’s).

What pushed me to action was the result of the recent Technical Board election, in which Simon Charette, who’s the main active contributor to the ORM (for a long-time), did not get re-elected. That’s fine: the new board are all great. But Simon and Mariusz often work closely on quite arcane issues, and Simon approving Mariusz’ changes is an important workflow. (TB members can already approve Merger PRs under DEP 10.)

The first of these cases is just a bit silly, the second, that Simon’s approval is not sufficient, is kind of ludicrous. Hence, the proposed change. It’s fine that DEP 10 needs adjustment as it’s implemented. That’s to be expected… (something about the best laid plans and meeting the enemy…)

Setting up Pi-hole

I set up Pi-hole on my home network this week. Oh my, it’s good!

I’ve long run ad-blockers on device. Don’t we all. But these don’t always work in-app. In particular, I use The Economist app, but they insert adverts into the articles. Often these are for related materials, but I finally lost the plot when they started showing smartphone adverts. (The Economist is subscription-based, and whilst I think it’s good value, it’s not cheap.)

Pi-hole’s tag-line:

Network-wide Ad Blocking — A black hole for Internet advertisements

I had a Raspberry Pi sat there not doing anything. Connected by Ethernet to my router and installed Pi-hole. Whole thing took less than an hour, including a bit of head scratching working out to renew DHCP leases so devices would use the Pi-hole for DNS. (This last would happen eventually but…)

Tl;dr: I can’t recommend it enough.