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.
> 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.
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.
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.
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).
Conceptually, Cython is mainly for accelerating Python code, and can _also_ access C code. Meanwhile CFFI is specifically for calling C code and nothing else. I recommend the video for the differences.
One concrete thing that pops to my mind is that Cython doesn't support Py_LIMITED_API which means that you need to ship a lot more binary wheels. At least the issue is still open (https://github.com/cython/cython/issues/2542) and Cython projects IME need new wheels for each minor Python release. Compare that to cffi projects that (musl & pypy aside) only have to ship wheels for one Python version / architecture: https://pypi.org/project/argon2-cffi-bindings/#files
Right, but that would take some really deep patching of code I don't control, just so it works in development.
If this were a production issue, I would probably fork the driver and do what you're suggesting (it's not like it's actively maintained or something :|).
You mean at the Python driver level? Unfortunately, that doesn't work with ctypes.
I've tried it by adding the DYLD_LIBRARY_PATH to os.environ before calling ctypes.LibraryLoader.LoadLibrary (https://docs.python.org/3/library/ctypes.html#ctypes.Library...) and it didn't work. I suspect ctypes gets somehow initialized much sooner and adding environment variables in your apps doesn't help.
TBH I didn't research it further, since the problems of the post are more general and it can happen that you trip into them regardless of runtime.
That doesn't help you if there's a surprise call to /bin/sh or /bin/bash somewhere in the call stack. Keep reading, I know it's long but I tried to make it comprehensive. :)
They did (it's me :)) and unfortunately in this case rpath can't be used, because that particular Python driver uses ctypes (https://docs.python.org/3/library/ctypes.html) to open the binary drivers which oversimplified means that there is no binary top modify.
I hope I make it in the preamble clear that this is bad and one should not have to deal with this – but it happens in practice and I hope such a summary is useful.
For posterity: if you want to wrap / use a C library in Python, you should go for CFFI (Cython works too and is overall faster, but has other downsides). This PyCon US video is a great up-to-date summary: https://www.youtube.com/watch?v=gROGDQakzas
I’m aware of all the problems that e2e tests have, and yet I find it more useful to have 1 test that adds something to a basket and 1 test that removes it than 100 unit tests without contract tests (which I never got the hang of TBH).
(To be fair, my projects are low on JavaScript which somewhat changes the trade-off calculations, but I haven’t seen any assertions about project types above.)
No, it doesn’t pass over that. It specifically points out that it’s a simplistic example for illustration that probably wouldn’t be worth it. And yet the effects are visible and so are the problems/solutions.
I mean what do you want here? 1,000 LoC in a blog post so it feels worth it?