Topics covered in this episode:

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

Watch on YouTube

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.

#419 Is your back end popular?

Python Bytes

#419 Is your back end popular?