Episode description

• content-types package for better MIME types/Content-Type
• Wagtail 6.4
• Build It Yourself
• Build backend popularity over time
• Extras
• Joke

About the show

Sponsored by us! Support our work through:

• Our courses at Talk Python Training
• The Complete pytest Course
• Patreon Supporters

Connect with the hosts

• Michael: @mkennedy@fosstodon.org / @mkennedy.codes (bsky)
• Brian: @brianokken@fosstodon.org / @brianokken.bsky.social
• Show: @pythonbytes@fosstodon.org / @pythonbytes.fm (bsky)

Join us on YouTube at pythonbytes.fm/live to be part of the audience. Usually Monday at 10am PT. Older video versions available there too.

Finally, if you want an artisanal, hand-crafted digest of every week of the show notes in email form? Add your name and email to our friends of the show list, we'll never share it.

Michael #1: content-types package for better MIME types/Content-Type

• It started with this comment from Raf.
• mimetypes — Map filenames to MIME types
• It is oddly missing very common types and varies by platform, OS install and other factors (see this function).
• Search around and found python-magic. Seems great but
  • ImportError: failed to find libmagic. Check your installation → brew install libmagic
  • magic.from_file("testdata/test.pdf") → FileNotFoundError: [Errno 2] No such file or directory: 'testdata/test.pdf'
  • hmm
• So I had to create my own. Introducing content-types
  • A Python library to map file extensions to MIME types.
  • Unlike other libraries, this one does not try to access the file or parse the bytes of the file or stream. It just looks at the extension.
  • Better support than mimetypes builtin.

Brian #2: Wagtail 6.4

• Release notes
• Lots of great updates, but I want to zoom in on background tasks.
• 6.4 includes django-tasks
  • which is an available implementation of DEP 0014: Background workers
  • This proposal is accepted and this thread includes a great talk from DjangoCon Europe 2024
• Why is this cool?
  • Even though django-tasks says it’s “under active development”, as long as you pin the version and test your behavior depending on this, it must be ready to use if wagtail is going for it. Don't you think?

Michael #3: Build It Yourself

• from Armin Ronacher, sent in by Rafael Weingartner
• An excellent article pushing back on too many dependencies
• Maybe the advice of always prefer code reuse isn’t that great after all?
• It’s much much easier to solve small little problems these days due to AI.

• Take Postmark as an example.

• “It's time to have a new perspective: we should give kudos to engineers who write a small function themselves instead of hooking in a transitive web of crates. We should be suspicious of big crate graphs. Celebrated are the minimal dependencies, the humble function that just quietly does the job, the code that doesn't need to be touched for years because it was done right once.” - Armin

Brian #4: Build backend popularity over time

• Bastian Venthur
• This is just for projects using pyproject.toml
• Apparently he did this last year as well, so we can see some trends.
• Results
  • setuptools: ~50% (last year ~50%)
  • poetry: ~30% (last year ~33%)
  • hatchling: (percent not listed, but looks like 12-15%), (last year 10%)
  • flit: ~5% (last year ~10%)
  • other: (above flit now)
• Analysis:
  • setuptools continues to grow in absolute numbers and maintain it’s percentage.
  • poetry declining
  • hatchling growing
  • flit declining
• Brian commentary
  • This is not surprising to me. I generally use hatchling for more control, and setuptools for simple projects. I think we might end up with mostly setuptools and hatchling in a couple years.

Extras

Brian:

• Test & Code Archive is now all episodes on one page
  • Old method was 30 episodes per page
• For something completely different
  • NameGrapher - popularity of US names
  • No wonder I don’t meet a lot of kids named Brian
  • Michael is #16 (#1 in 1950s - 1990s)
  • Brian is #317 (#8 in 1970s)

Joke: The long path to rejection.