hynek
Joined 17 years ago
Karma
819
Submissions
175
Member since
Mar 26
Recent submissions
Comment · 1 year ago
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.
Comment · 1 year ago
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.
Comment · 1 year ago
> 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.
Comment · 1 year ago
Pretty good, except it’s not Bismarck but Fontane. ;) Also, I’m comparing myself to CGP Grey, not whatever it’s transcribed. :D
Comment · 1 year ago
ha, I wish I saw that while working on that talk! adding it to the resources!
Comment · 1 year ago
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.
Comment · 1 year ago
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()
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
Comment · 2 years ago
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.
Comment · 2 years ago
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.
Comment · 2 years ago
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).
Comment · 2 years ago
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)
Comment · 3 years ago
I guess PEP 703 has to be auto-accepted now. I don't make the rules.
Comment · 3 years ago
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
Comment · 3 years ago
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 :|).
Comment · 3 years ago
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.
aspe:keyoxide.org:5KLULPTEPFVHZUBX2QRS4XM2M4