111–120 of 143 posts
Hmm let's see we're going to - Reimplement SQLAlchemy models (we'll call it a "repository") - Reimplement SQLAlchemy sessions ("unit of work") - Add a "service layer" that doesn't even use the models -- we unroll all the model attributes into separate function parameters because that's less coupled somehow - Scatter everything across a message bus to remove any hope of debugging it - AND THIS IS JUST FOR WRITES! - Fo…
Wow this book is a goldmine for architecture patterns. I love how easy it is to get into a topic and quickly grasp it. Having said that, from a practical and experience standpoint, using some of these patterns can really spiral out into an increased complexity and performance issues in Python, specially when you use already opinionated frameworks like Django which already uses the ActiveRecord pattern. I’ve been in c…
> Turns out all the big ones with strict architectural (n=3) pattern usage, although “clean”, the code is waaaay to complex and unnecessarily slow in tasks that at first glance should had been simple. My last job had a Python codebase just like this. Lots of patterns, implemented by people who wanted to do things "right," and it was a big slow mess. You can't get away with nearly as much in Python (pre-JIT, anyway) a…
The trouble is if you strictly wait until it's time then basically everything requires some level of refactoring before you can implement it.
The dream is that new features is just new code, rather than refactoring and modifying existing code. Many people are already used to this idea. If you add a new "view" in a web app, you don't have to touch any other view, nor do you have to touch the URL routing logic. I just think more people are comfortable depending on frameworks for this kind of stuff rather than implementing it themselves.
The trouble is a framework can't know about your business. If you need pluggable validation layers or something you might have to implement it yourself.
The downside, of course, is we're not always great at seeing ahead of time where the application will need to be flexible and grow. So you could build this into everything, leading to unnecessarily complicated code, or nothing, leading to constant refactors which will get worse and worse as the codebase grows.
Your approach can work if developers actually spot what's happening early and actually do what's necessary when it actually is. Unfortunately in my experience people follow by example and the frog can boil for a long time before people start to realise that their time is spent mostly doing large refactors because the code just doesn't support the kind of flexibility and extensibility they need.
I actually do. It’s slow, buggy and not type safe.
Everything good about Python is actually C, namely the good packages. They’re not written in Python, because Python is shit.
Earlier quoted context omitted.
my favourite model is to write as many pure functions as possible, and then as many functions of 1-4 parameters that interact with the outside world, and only then create domain objects to wrap those - it keeps the unrelated complexity out of the domain and then I can also reuse those functions without having to create the entire object that I don't always need.
I am not convinced that domain driven design works. Objects doesn't model the real world well. Why we should think DDD model the real world or a business well? And why do we even need to model something? Computers are different than humans. I think we should be pragmatic and come with the best solution in terms of money/time/complexity. Not trying to mimick human thought using computers. After all a truck isn't mimic…
It's possible that it works for some people, but I've seen the above scenario play out too many times to see DDD as anything but a red flag
Earlier quoted context omitted.
I am not convinced that domain driven design works. Objects doesn't model the real world well. Why we should think DDD model the real world or a business well? And why do we even need to model something? Computers are different than humans. I think we should be pragmatic and come with the best solution in terms of money/time/complexity. Not trying to mimick human thought using computers. After all a truck isn't mimic…
> I am not convinced that domain driven design works. Objects doesn't model the real world well. DDD does not necessitate OOP. You can do DDD in functional languages. I think there's a whole F# book about it. So I think you can conclude that OOP doesn't model the world well, which may or may not be true, but I think it's not valid to extend the conclusion to DDD. Is there a DDD-inherent reason why you think DDD does…
Earlier quoted context omitted.
Haven’t read the book, so I don’t know exactly what position they’re taking there, but type checking has done more to improve my Python than any amount of architectural advice. How hard it is to type hint your code is a very good gauge of how hard it will be to understand it later.
My experience is that once people have static typing to lean on they focus much less on the things that in my view are more crucial to building clean, readable code: good, consistent naming and small chunks. Just the visual clutter of adding type annotations can make the code flow less immediately clear and then due to broken windows syndrome people naturally care less and less about visual clarity.
Earlier quoted context omitted.
I am not convinced that domain driven design works. Objects doesn't model the real world well. Why we should think DDD model the real world or a business well? And why do we even need to model something? Computers are different than humans. I think we should be pragmatic and come with the best solution in terms of money/time/complexity. Not trying to mimick human thought using computers. After all a truck isn't mimic…
DDD isn't about objects. It's just about modelling the domain (real world) using the tools available to you. Some things are best modelled by objects, some are best modelled by functions or other constructs. The real point is establish a common language to talk about the domain. This is enormously powerful. Have you ever worked with people who don't speak your language? Everything takes 3x as long as ideas aren't com…
With DDD you just get a third model that is neither the domain, nor the software, and both the domain experts and the programmers will have to work extra to maintain and understand it.
Worse, people often try to build this model up front, which means it will be wrong, hard to implement and probably get thrown away if you actually want to ship anything
Earlier quoted context omitted.
>I'm concerned with what capabilities the input offers, not the name given to one particular implementation of that set of capabilities. If I have to think about it in any more detail than "`ducks` is an iterable of Ducklike" (n.b.: a code definition for an ABC need not actually exist; it would be dead code that just complicates method resolution) I'm trying to do too much in that function. If I have to care about wh…
I understand that. The point is that I gain no information from it, and would need more complex typing to gain information. I keep seeing people trying to wrap their heads around various tricky covariance-vs-contravariance things (I personally can never remember which is which), or trying to make the types check for things that just seem blatantly unreasonable to me. And it takes up a lot of discussion space in my ci…
No, you do gain information from it: that the function takes an Iterable[Ducklike].
Moreover, now you can tell this just from the signature, rather than needing to discover it yourself by reading the function body (and maybe the bodies of the functions it calls, and so on ...). Being able to reason about a function without reading its implementation is a straightforward win.
Earlier quoted context omitted.
Do you mean that you're allowed to only use types where you want to, which means maybe the type checker can't check in cases where you haven't hinted enough, or is there some problem with the type system itself?
The type system itself is unsound. For example, this code passes `mypy --strict`, but prints ` ` even though `bar` is annotated to return an `int`: i : int | list[int] = 0 def foo() -> None: global i i = [] def bar() -> int: if isinstance(i, int): foo() return i return 0 print(type(bar()))