Shownotes Transcript
Topics covered in this episode:
- [**content-types package**](https://github.com/mikeckennedy/content-types?featured_on=pythonbytes)) **for better MIME types/Content-Type**
Extras
Joke
Watch on YouTube)
About the show
Sponsored by us! Support our work through:
Connect with the hosts
Michael: @[email protected]) / @mkennedy.codes) (bsky)
Brian: @[email protected]) / @brianokken.bsky.social)
Show: @[email protected]) / @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)
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).