Out of curiosity, why would I use Dataclass vs a Pydantic Basemodel. If we did not have a PyDantic dependency I could imagine wanting to use Dataclass. But if I have it, why not use everywhere?
One explicit difference is that dataclasses don't support validating nested objects.
I'd use it for passing flat structures as function args rather than a massive list of individual args.
I have a silly theory that I only half joke about that docker/containers wouldn't've ever taken off as fast as it did if it didn't solve the horrible python dependency hell so well. You know something is bad when fancy chrooting is the only ergonomic way of shipping something that works. My first taste of Python was as a sysadmin, back in 2012 or so, installing a service written in Python on a server. The dependency…
I won't touch Python either, but because I've been burned debugging large Python programs. Something that would have taken a minute in a statically typed language took hours of tracing data through the program to understand what was supposed to be in a dict. There are alternative languages that are pithy, statically typed, can write programs quickly, and can grow into large code bases that are maintainable; so there…
Most python written at a large scale uses types (TypedDict) and/or Pydantic for safety and never plain dict objects. That's a code smell in any language, we can stuff data into `map[string]interface{}` all day long and cause problems downstream.
The difference is it's default, it always works the same everywhere, it actually writes down the deps, and I don't have to manually switch between them (or set up fancy bashrc triggers) like venvs.
> it's default This point is true; the ecosystem simply can't change overnight. uv is getting there, I hope. > it always works the same everywhere `uv` works the same, everywhere? > it actually writes down the deps `uv add` does that, too. > I don't have to manually switch between them (or set up fancy bashrc triggers) like venvs. You don't have to do that with `uv`, either?
Hope they make uv default then. It's nice, but I have to separately create a project with it, and regular python commands don't work with it, both of which go back to it not being default. But even that won't fix all the old projects.
...by being as shockingly contrasting with their environment as possible. Maybe your aesthetics differ, but I find it quite ugly. If it wasn't, it wouldn't grab my attention so well. Wearing something shockingly ugly is a great way to not be mistaken for a deer. By contrast, I find a well camouflaged deer quite beautiful--once I notice it at all. The beauty comes from the way that it is so clearly a thing of its surr…
> Wearing something shockingly ugly is a great way to not be mistaken for a deer. Sure... yes the bright orange is ugly, but it's not the ugliness that prevents you from getting shot, it's the bright unnatural color. Other hunters aren't thinking "oh that's really ugly, it must not be something I can shoot" they're thinking "bright orange means person, I should not fire my rifle in that direction". > If it wasn't, it…
If I thought that bright orange was a part of a healthy forest ecosystem, I would likely see beauty in it. And if my intent was to shoot denizens of such an ecosystem, then yeah bright orange would make a poor indicator for "don't shoot here". You'd be better off with something ugly, something which clearly doesn't belong.
Millions of people put it into Docker, or they just deal with it and you see the results with tons of Stackoverflow questions
> Millions of people put it into Docker, or they just deal with it and you see the results with tons of Stackoverflow questions Arrogantly wrong. I've coded in Python for almost 20 years. Many of those years I've had it as my primary language at work. 2024 was the first year I actually needed a virtualenv. Before that, I'd happily use pip to install whatever I want, and never had a version conflict that caused proble…
I was talking about pip, not venv. I don't use venv either, not because I think it's a bad idea but because I can't be bothered. Stuff does end up conflicting unless I use Docker (lol) or uv.
>> I prefer to use a monorepo structure There is nothing more annoying than tons of little repos all of which containing tiny projects with a few hundred lines of code but (of course) you need most / all of them to do anything. Use a mono repo until there is some obvious reason to split it up imo.
I got the impression that TFA speaks of a monorepo in the sense of not splitting the backend and the frontend into two different repos. For personal projects, though, I get the value of an actual small projects monorepo.
I'm not talking about personal projects. If you have <100 people, mono repo imo.
> I would like to have a tool that generates the project structure for me, but I haven’t found one that fits me yet. I recommend cookiecutter for this. I have a few templates I've built with that which I use frequently: python-lib: https://github.com/simonw/python-lib click-app: https://github.com/simonw/click-app datasette-plugin: https://github.com/simonw/datasette-plugin llm-plugin: https://github.com/simonw/llm-p…
Hmm never heard of this. Thanks for the recommendation.