James Bennett

Finished a long-overdue transition away from subscribing to the Planet Python RSS feed, which has become close to unusable, and now am subscribed individually to a bunch of interesting people.

Dependencies are not evil, and in some ways are unavoidable (operating system, language runtime/standard library, etc.). Having been in the business of maintaining a web framework, I think you probably don't want to get into that business *on top of* whatever your actual business is.

There are lots of acceptably-good programming languages out there. Choose any of them. Choose on factors like "what's the team most familiar with". Scaling to OMGHUGE is something *no* language does out of the box.

The "function color" problem is a tradeoff, and what you get in exchange is increased ability to reason about what might happen. I find this a strong enough benefit to outweigh the "color" issue.

Litestar is worth a look A few years ago at work, I had a project which offered an opportunity to look at the new generation …

New blog post: I've mentioned before that #litestar is by far my favorite of the new generation of #python web frameworks, and I've finally found time to write about why.

www.b-list.org/weblog/2025/...

Object-Oriented Programming is good, actually. Having a *thing* that carries both some data and the logic to work with it is a really useful idea and a lot of allegedly non-OOP languages adopted it anyway and pretended they didn't.

Test coverage is useful. Not as a target, but as a warning sign: if it suddenly *drops*, that's a reliable sign something has gone wrong.

Instead of doing "Agile", read Fred Brooks and implement his recommendations for how to build software and manage software projects.

His advice is concrete, actionable, and correct, and "Agile" misses on at least two of those adjectives.

The growing tide of worthless slop that shows up in search results for technical topics (which did not begin with LLMs but has been accelerated by them) has had the interesting side effect of getting me to buy books about programming again after many years of not doing so.

A lot of tech that comes from huge companies is like birds on remote islands: highly evolved for an ultra-specialized niche, and won’t do so well when transplanted somewhere else.

The primary utility of static typing is not in automated correctness checks, it's in forcing you to write *something* resembling documentation for how to use your code.

The pursuit of "testable" code has diminishing returns, especially as all the decomposition and extra layers of abstraction/indirection make the code harder to understand.

ORMs are fine, actually. Manually querying and transforming DB data to/from your application's data structures is tedious and error-prone and you can skip it.

Doing a twist on the meme that's going around:

One like on this post = one hot (or at least lukewarm) take on tech.

I wonder if there's any hyped-up "everyone has to use it or get left behind" thing going right now? People being swarmed with "you must have used it wrong"? I wonder what history tells us will likely happen in the end?

A similar process happened with other techniques/methodologies. Pair programming. "Extreme" programming. The Agile-Industrial Complex.

Thing comes along, fans claim it's a revolution and everyone must adopt or be left behind, eventually it settles down to a "some use it, some don't" equilibrium.

And so the industry has settled down to where people who like TDD do it, and people who don't like it don't do it, and neither side seems able to claim a measurable advantage.

But somehow, for some people, TDD is awesome and amazing and they can't understand why everybody doesn't do it. And for others, TDD is "meh" at best and they can't understand why it's so hyped.

There are plenty of other people who try TDD and find it doesn't deliver what its fans claim. And when they say this, the fans show up and pick that apart.

You weren't REALLY doing TDD. You couldn't have been doing it correctly. If you had you'd have seen the same results I got!

There are people who insist that Test-Driven Development (TDD) delivers massive gains to multiple aspects of software development, and so, they tell us, everyone should switch to TDD.

Happy 20th birthday Django! Posted by Thibaud Colas & Benjamin Balder Bach on July 13, 2025

Happy 20th birthday Django! 💝🎂🎉

www.djangoproject.com/weblog/2025/...

Our open source journey started 20 years ago today, on July 13th 2005. Come celebrate this big milestone at one of our many community events this year

#Python #Django #OpenSource #DjangoBirthday

Anyway, I was just doing a quick investigation for whether stuff at $WORK (which uses PDM as a friendly frontend, but currently exports to requirements files installed by pip in the actual containers) could switch to pylock.toml yet.

I'll check again in a few months!

Ironically one of the things confusing me was that "uv pip install -r" works with a pylock.toml and so I wasn't sure if that meant actual pip could do it too.

I have basically zero patience with people who respond to a question about whether something's supported with "volunteer project, do it yourself".

Screenshot of part of a Mastodon post, saying: `pip` tends to the lag the standards a little bit, especially if someone directly involved in the standards process is not already a champion of the stuff being added to `pip` To put it bluntly: maintaining `pip`'s existing features is already a lot, so some standards become "implementations welcome" until there are cycles available from the maintainers themselves. PEP 723 is another one that comes to mind

It was this guy, who was not only rude to word it that way but also factually wrong, and has now blocked me to save face.

Of course, being Mastodon, someone else felt the need to “bluntly” shame me for even asking whether it was supported yet because they needed to stand up on behalf of the maintainers.

Installing from a pylock file appears to be coming in the future — someone in the Mastodon thread linked this useful description: ichard26.github.io/blog/2025/04...

#Python packaging question: I'm looking at pip's documentation and I see an explanation of how to generate a pylock.toml file, but nothing which indicates pip could then install from that file. Can it? If so, what's the right combination of arguments?

If everybody who benefits from Hynek's open source work paid in just one (1) unit of currency, this balance would be positive again by the end of the day.

Code: append_images = (Image.new("RGB", (1, 1), color) for color in colors) im_reloaded = roundtrip(im, save_all=True, append_images=append_images) for im_expected in append_images: im_reloaded.seek(im_reloaded.tell() + 1) assert_image_similar(im_reloaded, im_expected, 1) And then Codecov warns these last two lines weren't covered.

Days since running coverage on tests found a bug in the tests: 0

This time, a generator had already been exhausted, before we tried to iterate over it. The lack of coverage highlighted the problem.

hugovk.dev/blog/2025/ru...

#Python #tests #coverage