Plurrrr

Hello! I’m excited to announce a project I’ve been working on for a long time: a free guide to implementing your own DNS resolver in a weekend.

The whole thing is about 200 lines of Python, including implementing all of the binary DNS parsing from scratch.

Whenever I give a talk about time zones, someone comes up to me afterwards and tells me that they have broken code currently in production, because they misunderstood how pytz works. This is because pytz uses its own non-standard interface for handling time zone information that is partially but not entirely compatible with the way Python's datetime library was intended to work, which leads to a lot of confusion from people naively using pytz as a time zone provider. This incompatibility is why, as of Python 3.6, the tzinfo documentation recommends dateutil.tz rather than pytz as an IANA time zone provider. ^[1]

In this post, I will cover both time zone models and if I cannot convince you to switch to dateutil.tz, at least provide some intuition about the differences between pytz and the standard time zone model.

Basically, you have two choices to parametrize tests in Rust:

• Code generation
• Custom test harness

They’re both not great.