erikvdven

Did I mention anything about performance? If so, my apologies, I'll need to revise the article, because this really has very little to do with performance.

In fact, a reader who emailed me ran into a challenge where, if you have an aggregate with just one entity, for example, Bookcase -> list[Book] , and that list grows significantly, it can lead to performance issues. In such cases, you might even need to consider a solution to improve upon that. But that's a separate topic.

What I was trying to highlight earlier were the whys behind the approach. And based on the feedback over here, it might be a good idea to update the post. I really appreciate all your input.

As for the whys: The less your domain knows about the outside world, the less often you need to change it when the outside world changes. And the easier it becomes for new team members to understand the logic. It also separates your database models from your domain models, which is great IMHO. It makes it easier to change them independent from each other. You could have both, separated domain models and database models or API models and use Pydantic for all these layers, but why would you do that? If you need to make the translation anyways, why not to pure dataclasses?: no extra mental models, no hidden framework magic, just business concepts in plain Python. This does depend on your specific situation however, there are enough reasons to not do this. But if your application grows in size and is not so much a simple CRUD application anymore, I wonder if there are enough reasons to NOT keep Pydantic in the outside layers. So yes, for small simple applications it might be overcomplicated to introduce the overhead when your data stay relatively consistent across layers.

Exactly. I love the comments by the way! I never expected this would take off like this. The fact that this isn’t clear in the article is excellent feedback, and I'll take it into account when revising it. After a few hours of writing, it's easy to forget to convey the real message clearly.

But you are absolutely right. To add a little: In practice, if a third-party library hardly ever changes and makes life dramatically easier, you can consciously decide to accept the coupling in your domain, but that should be the exception, not the rule.

Pydantic is great at turning large, nested dictionaries into validated objects, yet none of that power solves a domain problem. Inside the domain you only need plain data and behaviour: pure dataclasses already give you that without extra baggage. And that's the main reason to leave it out.

The less your domain knows about the outside world, the less often you have to touch it when the outside world moves. And the easier it becomes for any new team member to adopt that logic: no extra mental model, no hidden framework magic, just the business concepts in plain Python. And exactly what you mentioned: if you ever want to drop Pydantic, you don't need to touch the domain. The less you have to touch, the easier it's to replace.

So the guideline is simple: dependencies point inward. Keep the domain free of third-party imports, and let Pydantic stay where it belongs, in the outside layers.

So I'm not able to delete this message so it seems, but guess I already found a solution to this problem: the observer method, which ironically seems to be also implemented by Redux itself.

Oeh Delphi! That brings back some memories. But I hear what you're saying. I must say front-end has become more mature, but still, it can be quite frustrating so now and then.

More moving part is the right way to say it I guess. And perhaps: you have a user which interacts with it, so there is a lot to keep in mind regarding that as well: show loaders, what happens with y if they hit x and z, etc.

Well, I've seen a lot of discussions which try to prove otherwise. But perhaps it also depends a bit on the level in Software Engineering? If you are new, it might be that back-end feels more complex.

But yeah, front-end even feels harder to debug at some points like the one I mentioned in the OP, at least for me. Not to mention the facts you keep overthinking what might be a good solution in terms of UX (in case that too many DOM elements is the issue of slow performance).

That is definitely a neat one! If you are ok with it, I might add that one. I just updated the article already with some of the great comments and tips I recieved over here.

Perhaps for another article? :) But thanks, definitely a nice list! My purpose for now was to keep the article 'digestible' as well.

I agree. Someone else here also mentioned that they prefer code that is easy to read over code that uses a lot of "unfamiliar functionality," let's call it that. And I do agree; Kyle mentions the same thing if I remember correctly when it comes down to JavaScript. It is better not to expect your colleagues or other developers to know the ins and outs of the language as well. If one way is 10x easier to understand, just stick with that.

But as you said: if you know it, it's probably awesome. In my opinion, it never gets boring to discover new things in Python, and it does make you a better Python developer. Knowing what and when to apply certain knowledge is where your experience comes in.

Too many I bet. There is always stuff to learn I guess, but reading Fluent Python gets you pretty far. @qsort also mentioned some nice extras.

Thank you so much! And discussions about these articles over here are even more valuable :)

I fully agree on this! Like the Zen of Python says: explicit is better than implicit. You should not expect your teammates know all "special" behavior of the language and if you can write it more straightforward, you should in that case. Guess Kyle mentiones the same about JavaScript in his books. You are right about that. Perhaps that should be a nice addition to the post. I do believe though, it is good to be familiar with this behavior in case you ever come accross such situation.

You are right about that, perhaps it is good to mention it as "gotcha". Or I could have used a better title. I do think though, it is good practice to know this stuff. About the cache decorator: I did link to another article where I discuss lru_cache and cache :)

Sharp! Updated that line. And thank you for the compliment :)

Thanks a lot! Really appreciate it. Love the example! Haven't used the dunder __call__ yet (like many magic methods I guess), but that's a nice one!

I didn't have to use Metaclasses, either, though I have read about them, especially in Fluent Python. But I guess I belong to the 99% who haven't had to worry about them, yet :P

Thanks for the tip! :)

You are very much right a lot of it is pretty basic knowledge. From my experience though, a lot of python developers don't take the python docs or tutorial as first resource, and quite some developers I met did lack quite some knowledge I mentioned in the article.

You are right about the fibonacci operator, I thought I did refer to another article where I mention the lru_cache as well :) But I'll double check.

Good one about the parenthesis! I'll post an update soon

Thanks! I tried to add mostly the stuff I don't encounter that often in blogs/tutorials etc. But guess you are right. Generators, or at least the 'yield' keyword, is often misunderstood, and we can't emphasize them enough

Well, the purpose of the code is to use it in mail clients. And because mail clients don't allow you to use javaScript and such, using an image is the most obvious alternative.

Now you can do it yourself haha ;) I still have to cleanup the code a bit. Thinking of creating a class which allows you to create such image by just writing a multidimensional array, so less code to write. But I couldn't wait to share this already so... But updates are coming soon.

Yes, the idea is brilliant! But the purpose of my source code is to use "real-time" gif images in mail clients. Unfortunately, videlalvaro's solution is only possible for mail clients which support loading images from its original source. Google loads the images from their proxy, which downloads the images first. It DOES re-download each image at the moment you re-open the e-mail message, but it won't make it possible to manipulate the images real-time. I've tested it. It does work in clients like outlook, cause outlook shows the images from its original source, but gmail doesn't. So sending a gif image with a certain amount of frames is better, in my opinion.

I have tested an image generated with this script in both Gmail and outlook clients and it works just fine. Else I wouldn't post it over here of course :)