The fancy word for that is Vertical Slice Architecture btw and it's the only way for complex apps that doesn't end in chaos.

Bogard's example for a poor fit for VSA, in the famous blogpost, was specifically controllers.

> Sometimes these are still required by our tools (like controllers or ORM units-of-work) but we keep our cross-slice logic sharing to a minimum.

That's exactly where you shouldn't be using it! Relying on it as dogma will result in chaos.

> I’m not sure this is good advice. I prefer to test as much of the stack as possible. The most common mistake I see these days is people testing too much in isolation, which leads to a false sense of safety.

You make it sounds as if the article would argue for test isolation which it emphatically doesn't. It in fact even links out to the Mock Hell talk.

Every mock makes the test suite less meaningful and the question the article is trying to answer is how to minimize the damage the mocks do to your software if you actually need them.

But ultimately it suggests this test; which only tests an empty loop?

  def test_empty_drc():
      drc = Mock(
          spec_set=DockerRegistryClient,
          get_repos=lambda: []
      )

      assert {} == get_repos_w_tags_drc(drc)

Maybe it's just a poor example to make the point. I personally think it's the wrong point to make. I would argue: don't mock anything _at all_ – unless you absolutely have to. And if you have to mock, by all means mock code you don't own, as far _down_ the stack as possible. And only mock your own code if it significantly reduces the amount of test code you have to write and maintain.

I would not write the test from the article in the way presented. I would capture the actual HTTP responses and replay those in my tests. It is a completely different approach.

Yes, because it's showing how the simplest-possible mock already gets ugly if you don't follow the advice. Making the example more complicated would dilute the point it's making.

The question of "when to mock" is very interesting and dear to my heart, but it's not the question this article is trying to answer.

Pretty good, except it’s not Bismarck but Fontane. ;) Also, I’m comparing myself to CGP Grey, not whatever it’s transcribed. :D

ha, I wish I saw that while working on that talk! adding it to the resources!

Shouldn't some AI be able to clean that up for you? This seems something LLMs should be well-suited for.

---

FWIW, I'm the speaker and let me be honest with you: I'm super unmotivated to write nowadays.

In the past, my usual MO was writing a bunch of blog posts and submit the ones that resonated to CfPs (e.g. <https://hynek.me/articles/python-subclassing-redux/> → <https://hynek.me/talks/subclassing/>).

However, nowadays thanks to the recent-ish changes in Twitter and Google, my only chance to have my stuff read by a nontrivial amount of people is hitting HN frontage which is a lottery. It's so bad I even got into YouTubing to get a roll at the algorithm wheel.

It takes (me) a lot of work to crystallize and compress my thoughts like this. Giving it as a talk at a big conference, at least opens the door to interesting IRL interactions which are important (to me), because I'm an introvert.

I can't stress enough how we're currently eating the seed corn by killing the public web.

that's a reference to my attrs library which is what data classes are based on. It originally used

    @attr.s
    class C:
        x = attr.ib()

as its main api (with `attr.attrs` and `attr.attrib` as serious business aliases so you didn't have to use it).

That API was always polarizing, some loved it, some hated it.

I will point out though, that it predates type hints and it was an effective way to declare classes with little "syntax noise" which made it easy to write but also easy to read, because you used the import name as part of the APIs.

Here is more context: https://www.attrs.org/en/stable/names.html

I REGRET NOTHING

For what it’s worth, I was in the “loved it” camp.

(I’m the author of dataclasses, and I owe an immeasurable debt to Hynek).

Thank you for creating dataclasses!

if it's good enough for glyph, it's good enough for me

That is inaccurate. Both Rye and uv have the same goals and support virtualenvs.

uv is meant to supplant Rye eventually (it mostly already has: see also this post by the creator of Rye: <https://lucumr.pocoo.org/2024/8/21/harvest-season/>). But you can’t put a virtualenv into a Kubernetes, so Docker containers are still interesting if that’s something you want to do.

It’s much, much faster both in creating virtualenvs and installing the dependencies. And if you use lock/sync, you get a cross-platform lockfile that you only got with PDM and Poetry before – no more requirements.txt (but it supports it too).

Why was UV created when we already have PDM and Poetry?

Genuine question, we are drowning in options here!

Both PDM and Poetry are a) 90% solutions that only cover what their respective authors need (and this is indeed what Python is drowning in) and b) written in Python which makes them slow and somewhat janky since Python installations and virtualenvs tend to break (lol Homebrew).

I personally love PDM, and PDM is in the process of adopting uv’s lower-leveln functionality to install/resolve packages, but I can see how having a single binary for bootstrapping a whole dev environment is really nice.

In the end, uv’s biggest upside is that it has several people work 8h / day on it and one would be surprised how much can be achieved in such amount of time.

The burpee exercise is named after the US physiologist Royal Huddleston Burpee Sr.

I know y’all want to fact-check this – I sure did when I heard it the first time: https://en.wikipedia.org/wiki/Burpee_(exercise)

I guess PEP 703 has to be auto-accepted now. I don't make the rules.