Pybites Podcast

#171 - Hypermodern Python with Claudio Jolowicz

• Julian Sequeira & Bob Belderbos

Share episode

Welcome back everybody! This week we have another exciting podcast episode, this time with Claudio Jolowicz, well known for his "Hypermodern Python" article series which he recently turned into a book.

We dive into what Hypermodern Python means, uv's current quick rise, Nox, 80/20 tooling for (beginner) Python devs, Rust, mindset, and last but not least, some good book tips.

We hope you enjoy this interview with Claudio and make sure to check out his great materials.

Chapters:
00:00 Intro episode
01:42 Intro Claudio
02:44 Music background
04:21 Hypermodern Python
08:20 uv rapid develment
10:20 Making uv default tool
12:56 Nox for local CI
15:20 Hypermodern Python, the book
19:57 80/20 tooling for beginners
22:37 PDM ad segment
23:03 uv making it easier 
25:02 Cloudflare and Rust
27:33 Developer mindset and persistence
30:23 Book tips
32:25 Design patterns and TDD
33:40 Monkeypatching and dependency injection
37:12 Final CTA and wrap up

Links:
- Hypermodern Python article series
- Hypermodern Python book
- NOX vs TOX – WHAT are they for & HOW do you CHOOSE? 🐍
- Harry Percival's Stop using mocks video
- Book tip #1 - The Manager's Path by Camille Fournier
- Book tip #2 - Designing Data-Intensive Applications by Martin Kleppmann
- Book tip #3 - Architecture Patterns with Python by Harry Percival and Bob Gregory
- Claudio's GitHub and X

I think I would recommend people to use an integrated workflow tool, not use kind of the low level building blocks. And I think UV is a great candidate here. I'm the author of a project template, and I don't actually believe that people should just take the project template. And without understanding what's in it, I think it's much better to actually kind of gradually build out your tooling, ideally yourself. And once you understand how all these building blocks fit together, then maybe switch to a project template, because you're going to be doing the same thing over and over again for your projects. But, yeah, build it kind of a step, step by step. Hello, and welcome to the Pibytes podcast, where we talk about Python career and mindset. We're your hosts. I'm Julian Sequeira. And I am Bob Baldebos. If you're looking to improve your python, your career, and learn the mindset for success, this is the podcast for you. Let's get started. Welcome back, everybody, to the Pibytes podcast. This is Bob Eldebos, and I'm here with Claudio Jolovic. Claudio, welcome to the show. How are you doing? Hello. Very glad to be here. Thanks for having me. Yeah, thanks for hopping on. We're honored to have you. You do a lot of great work in the space, and you recently came out with a new book, which is based on an article series you did a while ago. Of course, going to talk all about that, but maybe we can start off for the people that don't know you, a little introduction and talk about how you got into python. So, do you want to give a quick introduction? Yes, absolutely. I have a kind of very funny story. I didn't go out studying computing science. I actually have a law degree. I got really interested in German. Legal theory is kind of this elaborate architecture that goes back to ancient Rome, and I thought, this must be something that you can put in a mathematical theory. And this is kind of how I got into logic and then computing science, and then I found I just really loved building things and ended up a software engineer instead. So that's kind of my story in a nutshell. And, yeah, I came across Python while, yeah, eventually I did study computing science and found a Unix book. They mentioned Python and just immediately loved its simplicity in the best sense of the word and intuitiveness. So I've been using it ever since. Awesome. And you also have a music background, right? It's true. Along the road, I've always played music, and I had been an engineer for maybe three, four years and been playing in various bands and I was thinking either to do some research on the side or try something new and play music. So I ended up actually spending about a decade as a touring musician and session musician. I play saxophone and flute. I don't do that so much anymore. I have small children now and I prefer to be at home rather than on the road. But yeah, yeah, yeah, life changes. By the way, I see a lot of musicians getting into programming. Do you see any, any link or has music had any influence on your software coding skills? I really, I really do see a link in kind of the mindset. It's the thinking about the music is also an architecture and formalism in a way that is like one thing that I find is a parallelism. But then there's also when you play improvised music, you really have to be in the flow and you have to be ready for mistakes to happen and so on. And it's kind of like the engineering process where you face obstacles and get compiler errors or runtime errors, and you just have to figure them out and take one step at a time. Yeah, awesome. Fascinating. So you're well known, at least I hope so. Also with our audience for the Hyper Modern Python article series, I think you started those in 2020, right before the pandemic. So for people that are less familiar with that, can you define the term hyper modern in the. Yeah. What it means and why is it hyper modern? What is it actually? And also, what inspired you to write that amazing series of articles? The term hyper modern really was tongue in cheek. So how this started off was I just started writing readmes for my teammates, for our projects, because I was trying to find a really good setup of tooling that kind of just worked, that gave you a single entry point for everything, all the developer tasks, but also really encourage best practices, reproducible checks, all of that. But kind of like trying to keep the cost as low as possible for running all of these checks, like type checking or linting code formatting, to always run your test suite across multiple python versions and ideally do all of that while having your dependencies locked so you don't get any surprises and gets the same experience for everybody, both locally and in CI. So that's kind of how hyper modern was born. I started to get into blogging. I thought this is a nice topic to write about. I made this journey, figured these things out and I really wanted to share them. And hyper modern as a term, I wanted to give people a really linear journey. So no options. I just say this has worked for me. This is like a golden path through the jungle of python packaging and tooling. And obviously, with the speed at which the python ecosystem evolves, it's bound to be out of date at some point. So I'm going to try to find really the best modern tools that I see right now. But if you look at it a year later, things will have changed a lot. And so I chose this kind of over the top name of hyper modern, which is also a reference to a chess theory book from, like, the 1920s, I think. And I have all these. This imagery on the blog of kind of the way that people in the 19th century imagined what the future would look like. So that's kind of the story of hyper modern. In the end, it's just kind of, I guess, things I value about how to set up a Python project, like best practices, reproducibility, dependencies, have always been kind of a big concern. Yeah, no, because it can be really challenging, right? Because there's so many tools, and especially for newer python developers, even developers that have been coding python for a while, it's just overwhelming how many tools there are and what's the best way of doing things. There should be, obviously one obvious way, but that has not been the case for packaging. That's interesting that you came up with. This is the way. But then it's also a challenge because the tools are evolving very fast. For example, now you have uva and 0.3 just came out last week, and now they're already on 0.4, and all of a sudden they added a couple of features, which basically was a whole poetry thing in there. So maybe on that note, do you think uv is taking over? Could it become a cargo like tool for Python? Is that even desirable? Is that realistic? What do you think of that? I'm a big fan of uv. So uv happened while I was writing the book and I started incorporating it. It was still the UV that was this blazingly fast drop in replacement for Pip and virtual eNV and pip tools. And I love that. And it was already clear that they were going for something bigger, that they really wanted to create the cargo for Python. And I think with 0.3, it's really like all the building blocks for that are there. I mean, more than the building blocks. You actually have an integrated workflow tool, and I think it is exactly what the Python ecosystem needs. I would very much recommend checking it out. It's very. If you've used poetry before, it's very similar workflow. And yeah, uv 0.4 has added also Python projects that are packaged as Python packages, which is going to be very convenient for people with say data science workflows. So yeah, I think I'm a big fan. I love the work that all the folks at Asheville have done and including the way they interact with the community. Yeah, it's really impressive because from 0.3 to 0.4, that was like a week and it implemented quite a big request of using the uv init with non packages or something like that. And that was quite a change and there was a lot of discussion on the issues. So like, wow, it seems like they're working day and night. Yeah. So is it your default tool now? Because I'm trying to force myself to now just use it for everything because I do see that it's going there, but it doesn't replace everything. Right. Because in the book you talk a lot about Knox. It's really nice recurring theme, I think you also, are you the creator of it or at least you're a contributor. Thea Flowers is the creator of Nox. I've been kind of like a fan who joined the band, his favorite band. So I'm a co maintainer of Knox. I help out sometimes I have more time, sometimes less, to do this, but yeah, it's true. So there are other things you want to be using, I think, or that may be helpful for you besides something like uv. And Knox is a good example, I think, for. So you asked, is it my default tool? I do try to use uv a lot right now. I'm converting projects to uv. I hope I will eventually find the time to give my hypermodern Python project template a remake and I could definitely see it using uv as well. So there are other things, there's pytest that you would want to use for your test suites, there's Nox that's really helpful if you want to not just run tests on different python versions, but just generally automate the checks that you have. And I see that still being very valuable. Knox has added support for uv internally, so that was a great speed up as well. So you can just set an environment variable and Knox will, if you have uv installed, we'll just default to it. Yeah. So yeah, UV I think for me will become the central, kind of the central tool and I will have other tools like Knox to supplement it. Yeah, and I forgot to introduce it to actually because some people might not know, but I think most people do know talks and I associate that mostly with running your tests and linters against different versions of Python. So maybe it's useful to know for people what has Knox on top of talks. Right? So actually Heneg Schlaback has made an excellent video post about comparing Knox and Tox, which I recommend. LinkedIn. Yeah, yeah. So they're both great tools and tox is kind of the spiritual ancestor of Knox. Tox uses any configuration file. Knox just uses Python. So you write a Knox file py I find personally, obviously I'm partial here. I love Knox because it's very simple for me to understand because it's just Python. I don't have to learn another language and it's very flexible for the same reason Knox just doesn't get in your way, because you just write Python functions, decorate them with the Knox session decorator, and you can specify the Python versions that the function should run across. And then Knox will create virtual environments for you with those Python versions and run whatever you want to run. So this could be tests or could be other things like linters, or building a package, doing releases, updating your readme, you name it. Excellent. I really see Knox as kind of like your local CI. So I try to have a CI that is super simple and basically just calls Knox. And this way I can easily run all the checks locally and don't get any surprises when I push my code. Yeah, because one of the takeaways from the book is the sooner you catch something, the better. Right. So you can of course run your CI CD on mid GitHub actions, but why not pull that in locally and make it uniform across the team? It will just save a lot of time and you catch your bucks and issues earlier. Congrats on the book. So the hyper modern tooling articles made it into a book, finished it last week. There's a lot in there apart from the tooling and giving you clarity, as you said, with the hyper modern theme, there's so much out there, but I can give you some clarity what to use. It also talks a lot about software best practices testing. You compare unit tests with Pytest at some point and there was some really good insights there. The skepticism around monkey patching. And I think your example shows more like how you more can inject the dependencies. Super interesting. So yeah, really insightful book. Highly recommended. Maybe talk a bit about the process, how actually turned into an O'Reilly book from your article series. How did that, did that happen? Right. It was a long journey. I think it took me two years to write this book and I rewrote some parts, some of the early parts. It was also a process of myself growing as a writer, one thing that I realized was that I didn't want to just replicate the blog. I said earlier, the blog doesn't give you any choices. It just kind of gives you one golden path to the python packaging ecosystem. In the book, I really wanted to go deeper and give you describe the problem space. What are these tools actually trying to solve? What kind of packaging standards do we have? Because these tools, it's not like every tool reinvents the wheel. There's this common frame of reference. And by doing that, I think even though uv 0.3 isn't in the book, people will understand what problems it solves and why certain things are a good idea, or what the trade offs are of certain approaches that uv has great support for. So this actually turned out to be much harder to do than just to write a block where you tutorial that goes step by step and at the end you have your finished project, because you really have to give people a mental model of what is a python environment. Have you ever tried to explain what a Python environment really is? I mean, not a virtual environment, but the runtime environment that Python code runs in. There are so many different ways that you can run Python code in that it seems simple, but it actually isn't. So a lot of the book, the early chapters, is really giving people a mental model of this problem space. And what actually happens when I import a package and where does it come from? Where does all the packaging metadata come from, and so on. That's a major accomplishment because, yeah, it's often confusing for people. It's not only the amount of tools, but how are the inner mechanics working? So, yeah, 400 pages, again, people should read it. It's not only introducing it to the tools, but I can definitely attest that gives you the real understanding of these tools, and that's really good. Yeah. Anything else you want to share around the book? So it's for all levels, right? It can be for beginners or trans people? Yeah, I think it's definitely, you know, the advice I would always give to beginners is to start simple. And I think you will benefit from the book if you have, like, a good mastery of the Python language and you're kind of starting to think about how can I make it easier for myself to build a package and what's the right way to test my code and what other tools might be there that help me kind of maintain this code over time. That's kind of the point in time in your evolution as an engineer or programmer where this book will be useful. So I think it's kind of a wide range of people. But if you're just really starting out, really learning Python, then maybe I would read another book first, just about Python itself. Yeah, that's a good point, because one other question I had was the 80 20 tooling advice. Right, like you're completely new to Python. Yeah, I think you can distinguish what you can do right away and maybe what you defer, for example, type hinting. Of course I'm a big proponent of it, but maybe you can not burden the beginner too much with that. But a virtual environment, you need to have from the get go. So is there kind of a distinction, especially for beginners, you can make? Yeah, I really agree that it's one of the great things about Python that you can start very simple and all the additional tools or features that language has, like type hinting, you can add them on. They don't get in your way right from the start, as with some other languages. So I agree. I think type handing is something that's hugely valuable, and you should always type check your code, I think. But you don't need to learn type checking right away. I would recommend people to use uv now that it really gives you a very quick start. You get a virtual environment by default, as you say, you should always use a virtual environment. That's one thing you don't want to skip as a beginner. You don't want to install packages into the global python environment. You can definitely write scripts without dependencies as a beginner, and then you kind of don't have that problem. But once you take on dependencies for your code, use a virtual environment that uv is a great candidate. I would, yeah, I think I would recommend people to use an integrated workflow tool, not use kind of the low level building blocks. And I think uv is a great candidate here. I'm the author of a project Template and I don't actually believe that people should just take the project template and I, without understanding what's in it, I think it's much better to actually kind of gradually build out your tooling, ideally yourself. And once you understand how these building blocks fit together, then maybe switch to a project template because you're going to be doing the same thing over and over again for your projects. But yeah, build it kind of a step, step by step. In just twelve weeks, pyrites elevates you from python coder to confident developer. Build real world applications, enhance your portfolio, earn a professional certification showcasing tangible skills, and unlock career opportunities. You might not even imagine right now. Apply now at Pibit DS PDM. Yeah, that's a good point. That happened to me with cookie cutter for Django all of a sudden made so many decisions and then also obfuscated a lot of things. So there's something to say to kind of figure out your own tool set. It's also kind of personal, right. How you want to set it up. What I really like about, well, many things of uv, but one thing I noticed, like the whole virtual environment is it's kind of hidden. Like normally you would just mainly make a virtual environment and activate it, and it just does it all under the hood and it's like seamlessly. It's almost like if you were not working with a virtual environment. That's my initial experience at least. So, yeah, it does seem to make it easier. And yeah, I think Armin Roner, her and Simon Millison were writing things like, well, this could become the tool, like when you teach somebody python from the start that it's just go use uv. Right, instead of, hey, go look in three different places. Exactly. And I'll add that it also installs Python for you behind the scenes, which is great. I recently had some CI job that I converted to uv, and it's nice to just rely on things being installed for you behind the scenes and for beginners is great because obviously Python installation has been a big hurdle for many people, and not just installing it, but also managing it over time. And yeah, by building on the Python standalone builds project, uv is really helpful here. It's the same for hatch, also can be used. PDM can be used to install Python from that project. But I love the way that uv solves it by doing it kind of seamlessly and transparently for you. Yeah. Awesome. So is the tooling site also something you do at work or you work at Cloudflare? Right, right. What are you working on now? So, right now at Cloudflare, I'm working on a rust service that allows customers to store and query their logs inside Cloudflare. It's a beta product for now. Ironically, throughout my career, even though I love Python and it's kind of the first tool, the first language I always reach for, the kind of the central language of the company has always been a different one. So I worked in C for a long time, and we used Python to automate our build process and prototype and so on. And now at Cloudflare, we use Rust and go a lot. And Python is something that we use again for prototyping a lot. They use this for testing, functional testing, integration testing and so on. So, yeah, whenever I have to automate something or prototype something, I reach for Python. Yeah, you hear that a lot. But then with Rust we have the performance potential and the compiler and all that. How is rust working out for you? Yeah, it's been. They say Rust has a steep learning curve. I didn't know either rust or go go was kind of like, you immediately get it. It's a very small language. Rust is quite different. But I'm loving it. I'm so happy to work with Rust. Yeah, it's interesting how there's this rust and python love between these communities. There's very good support to build binary python modules and Rust using maturin. I think the Astral team also uses that under the hood. And then obviously now we have this amazing developer tooling that's written in Rust. It seems like it's a good marriage of programming languages. Yeah, it's interesting how more rust is getting into our python ecosystem mainly through the astral work. Cool. Totally different question mindset for developers. How important is this mindset in becoming effective developer? It's so important, I think, you know, like there's kind of this Zen attitude that you need when you're dealing with code. Things aren't always easy. You kind of have to be ready to be surprised and, you know, sometimes smile at when you get, find another bug after you already solved half a dozen. So that kind of like. Yeah, going with the flow and being open and kind of taking each hurdle as it comes, that I think is a big part for me. So, yeah, I think it's important and there are so many sides to it. How do you, how are you effective? I think you always have to, have to stay open to learn, learn new, new things and kind of get out of your comfort zone a lot. That is kind of like what I, what I find really helps you, helps you develop as a, as an engineer a lot. Yeah, it seems like especially in our field, the comfort zone is very small and the outside comfort zone is very big. You have to go out that comfort zone a lot. Do you have an example where like one time you really had a challenging bug or situation where you had to apply some hardcore mindset techniques? Yeah, yeah, definitely. I mean, just yesterday I found a deadlock in kind of like a large operation that we were running and I actually took it as a win in a way, because now I know what I'm dealing with. Before it was just part freezing up. Now it's a deadlock and I had my work cut out for me and I'm looking forward to kind of go into this next battle. Nice. Yeah. I'd rather have a clear cut stack trace or something than some silent freezing or non explicable. I don't have the stack trace yet. Okay. At least in the next step. Yeah. That you can reproduce it. Yeah. Excellent. So last question. We always ask about books. What are you currently reading? And if nothing specific, if you have a book tip for audience. Yeah, definitely. I am the kind of person that always reads too many books at the same time. Right now, the manager's path by Camille Fournier. It's an Oreilly book about a guide to being an engineering manager, which is great, definitely recommended. And I'm rereading a fantastic other book called Data Intensive Applications by Klepmann, which is a great one. Also an oral title. I read that digitally and I got the paper copy. Now I'm rereading it. That's so funny. I just accidentally clicked on that title on my Kindle today. Yeah. Yeah. But I didn't want to read it right now, but maybe it does a signal. Also, on the python side, one of the books that has shaped me more than any other in recent years was architectural patterns in Python by Harry possible and Bob Gregory, which is a great. Starts an entire journey. Yeah. It's amazing on how deep they go on the software patterns and TDD and very clean code. I need to read it again. It's only like 200 something pages, but it's pretty. Damn. It's a short book. It's a really good read. I found it. I went reading all the kind of the classic titles about these things after reading that book, and I still go back to that book because it kind of puts it all together and makes it so actionable. As a python developer, I really love that. You mean design patterns, right? I guess, yeah. I read some of the domain driven design blue book, the Evans book, right? Oh yeah, that's a big one and a classic one, so. Right, yeah. So definitely big recommendation. And I love the way that they combine it with TDD. Do you do TDd in your daily coding or depends? It depends, but I love it. Whenever I can I do that. I find it liberating. It took me actually. We've always written a lot of unit tests, but I'm a late convert to test first development and I love it. Always recommended. Yeah. So that can be challenging, right? If you don't have the design in your mind or you just quickly prototyping. But maybe that's also a mindset thing you have to work around, same as people cling to monkey patching. And in your book you showed a way to avoid that. Maybe you want to elaborate on that because I found that an interesting insight. Do you want to? Yes, absolutely. So monkey patching is something that, let's start like this. Testing is hard. Usually the code that you're testing has dependencies on big things like production database. You're doing I o, you're talking to other services and being able to write a unit test for that is hard. So people either they'll kind of go down the way of having everything in integration tests, which are slow and they'll, you know, they won't point you to the problem. They're usually doing too many things at once. Or if you do unit testing then people reach for monkey patching where you basically just kind of take that network call or that database query and you just kind of edited out of your code because Python is so dynamic and you can just replace these functions with stubs that give you canned response and that's a really fast way to get it done. But it actually doesn't force you to decouple the code that you're testing. What you really should be doing is to think about what dependencies you have and try to encapsulate them. So then you can actually pass those, let's say your database abstraction to the code that you have and let it act on that. If you're testing, you can pass in a memory database or even maybe something more abstract that just basically gives you the records like a repository interface or something like that. You can just pass that to the code and that gives your test a lot of flexibilities, but it also improves the design of your code. So I. Repository pattern. It's also in Percival's book, right? Yeah, that is this link of DDD and TDd. So domain driven design and test driven development. There's also a great video by Harry Percival about trying to write tests without Mackie patching that I would recommend. I think if you can. Yeah, we'll find it and link it. Yeah, that's pretty important. But usually it comes down to dependency injection or just making it more flexible by receiving more arguments or whatever. Right? Yeah, I think that is generally the lesson, whether that be kind of like a full blown dependency injection framework or just something very humble like you pass a function to a function. Yeah, which we can in python or an interface or protocol. Nowadays in Python we have typing protocol which basically lets you do duck typing, but still makes it kind of possible to do type checking on it. So any object that kind of has the right attributes. Yeah, we have an article about that. I will link that as well. Yeah, cool. Well, these last questions were all not scripted, but thanks for answering those as well. Yeah, so thanks for hopping on and people go check out the hyper modern Python articles, but better the book because there's so much more in it and it's more up to date. And in closing, any final piece of advice or CTA or call to action for our audience of Python developers. Yeah, I mean, start simple, but try to make the cost of your developer tooling as low as possible. And yeah, give my book a try and let me know what you think about it. Yeah, we will. Awesome. Well, thanks, Claudio, so much and it was great to have you on the. You have a great day. Pleasure to be here. Thank you. Bye. We hope you enjoyed this episode. To hear more from us, go to Pibyte friends, that is Pibit es friends and receive a free gift just for being a friend of the show. And to join our thriving community of Python programmers, go to pibytes community, that's Pibit es community. We hope to see you there and catch you in the next episode.