Hypermodern Python Projects

00:00 What would a modern Python project look like? Maybe it would use poetry rather than pip directly for

00:05 its package management. Perhaps its test automation would be controlled by Nox.

00:10 You might automate its release notes with release drafter. The list goes on and on,

00:15 and that list is the topic of this episode. Join me and Claudio Jolovitz as we discuss

00:21 his hypermodern Python project and template. This is Talk Python To Me, episode 362,

00:28 recorded April 6th, 2022.

00:30 Welcome to Talk Python To Me, a weekly podcast on Python. This is your host, Michael Kennedy.

00:48 Follow me on Twitter where I'm @mkennedy and keep up with the show and listen to past episodes

00:53 at talkpython.fm and follow the show on Twitter via at talkpython.

00:57 We've started streaming most of our episodes live on YouTube. Subscribe to our YouTube channel over

01:03 at talkpython.fm/youtube to get notified about upcoming shows and be part of that episode.

01:08 This episode is sponsored by Microsoft for Startups Founders Hub. Check them out at

01:14 talkpython.fm/founders hub to get early support for your startup. And it's brought to you by

01:20 Compiler from Red Hat. Listen to an episode of their podcast as they demystify the tech industry.

01:26 over at talkpython.fm/compiler. Transcripts for this and all of our episodes are brought to

01:33 you by Assembly AI. Do you need a great automatic speech to text API? Get human level accuracy in

01:38 just a few lines of code. Visit talkpython.fm/assemblyai.

01:42 Claudio, welcome to Talk Python To Me.

01:45 So happy to be here.

01:46 I'm so happy to have you here. It's great to be talking to you. And this is one of those episodes

01:51 that's going to be so fun because what it's going to turn out to be, I'm pretty sure, is diving into

01:56 a ton of little tools. And I can tell you, just doing a little bit of research and putting together

02:01 some show notes for this, like, oh, there's that thing. And oh, look, this too. Oh, I didn't know

02:05 about this. So you've assembled this conglomeration of tools and techniques that you're putting under the

02:13 hyper modern banner. And I think it's going to be a lot of fun to talk about. So yeah, we're going to have a

02:18 good time. Looking forward. Indeed, same. Now, before we get into that, let's talk about your

02:23 story. How'd you get into programming and overhear to Python? I think one day my dad, that must have

02:27 been in the 80s, came back with and said, I bought a computer and I was really excited. I imagined,

02:33 you know, there's going to be a room filled with all these machines and ran down the corridor and

02:39 turned out to be like some kind of keyboard as it seemed to me. So there was a Commodore 64.

02:45 And initially we just, you know, played all those great 8-bit games. And eventually I started

02:51 programming a little bit in basic. And I think that's kind of when I really found out how much

02:56 fun this is. And, you know, then I think I was interested in a lot of other non-computer things

03:03 for a long while. I went to uni, I studied law.

03:07 As most programmers do, of course.

03:09 And, but somehow this, the interest in formal systems always stayed with me and law, especially

03:16 continental law, German law is very much like a little bit like a calculus tracing back to ancient

03:23 Rome. And I got interested in logic. And there's a small research community working on applying AI and

03:32 logics to legal theory. And that was really my gateway drug to, to get back into programming

03:37 really logics. I think I programmed this like a little flashcard system to help me prepare for the,

03:43 for the law exams. And yeah, eventually I decided I want to get really deep into this. And I started

03:51 studying computer science and pretty much never, never went back to law after that. So I have a law

03:56 degree, but yeah, working as a software engineer.

03:59 It's interesting. I hadn't really thought about it with law. I have a friend who's a lawyer and

04:03 in software. So I know it's, it's, it happens for sure, but thinking about the way you have to

04:09 mentally sort of solve the problems and the constraints of like legal contracts and laws

04:15 and stuff and how they apply. That's actually kind of a similar skill to thinking through solving a

04:19 computer programming problem with APIs and what the computer can do and stuff. Right.

04:24 And it's such a human way of thinking. So it's, it's really interesting from an AI point of view,

04:29 because it's not the kind of really clear logical deductions that you have, but there's a lot of

04:35 everyday knowledge that you need to have and the feasible rules. Yeah.

04:39 So it's quite exciting.

04:41 Yeah. Very neat. Now, what kind of a code and what kind of stuff are you doing these days?

04:45 I've been working mostly on a, on cybersecurity. So I'm working for a company almost 14 years,

04:53 that's doing cybersecurity as a service. So we're working mostly on C++ services or high performance,

05:01 data intensive services. We're using Python mostly for, to automate the build system, testing and releases,

05:09 processes, but also for prototyping. So algorithms, that's like really handy before you implement it in

05:15 a high performance way.

05:17 Yeah. I think Python is used frequently for that. Like let's prototype this. And then if

05:22 once we completely decide it works right, then we're going to write it in C++ or Rust. That's

05:27 not the most common use of Python, but it certainly is one that people have said, oh,

05:30 this is really good because you can prototype so quickly. Sometimes people just decide,

05:34 and also this will just work fine for what we're doing. It's actually, it's plenty fast. Or they

05:39 decide, you know, maybe not, right? Maybe they need C++, but it's still a cool use case.

05:43 Yeah.

05:43 Now let's kick off our conversation with some thoughts from a former guest, Mahmoud Hashemi. He had a

05:50 really interesting way of sort of presenting Python to people who are not deep in the Python language and

05:57 said, basically, it's actually, when people say Python is great for prototyping, for example,

06:02 well, they might be talking about one of three things or some combination of there. It could be

06:07 when people say, oh, Python is good for this, or Python is like that. They might be talking about the

06:11 language, or they might be talking about the standard library, or more and more these days,

06:16 they're talking about the third party ecosystem with, I don't even know how many libraries, but I

06:21 gotta look this up because it changes so fast. Right now at the time of recording, 368,000 libraries. So when

06:28 people mention Python, they often mean one or more of those different things. And we're going to talk about

06:34 hyper modern Python. So I think we should frame it a little bit in the sense of like, well, you know, what is

06:40 modern about the language? Or what is kind of modern about the standard library? And obviously, the ecosystem

06:46 where a lot of it's, it's happening. So from your point of view, what is modern Python?

06:51 Before we get to hyper modern?

06:53 Yeah, yeah, we definitely, we can talk about the language, the standard library, the ecosystem.

07:01 I'd also add the community. I think that's something that really defines Python.

07:06 Yeah, I agree.

07:07 Yeah. And all that tooling that evolved in the ecosystem. So about the language, what really,

07:14 because my, you know, my story is, I think I got into Python. Python was it like Python 2.3?

07:20 So you've been through the journey, you've been through the great split and the rejoining.

07:25 I pretty much missed a lot of the pain of the Python 2.3 transition. I've been busy with C++ and then

07:31 came back to Python. And for me, it was just the enthusiasm of rediscovering all the great,

07:37 like how expressive Python had become. One of the things that really get me excited about modern Python

07:43 is type annotations. I just find them so helpful to structure programs, to make APIs clear,

07:51 to help me think about my code and to keep it maintainable and readable. So I use them

07:56 pretty much always. And I always run my Pi in strict mode. Even I'd even use it in small scripts.

08:03 And it's, of course, very helpful in large systems. Absolutely. I don't know that I've,

08:09 in fact, I'm, I'm pretty sure I've never gone end to end and taken a large system and completely made it

08:15 100% my Pi checked, you know? Yeah. For me, I'm with you. I absolutely love

08:21 the types. And I use them a lot to sort of drive the tooling intelligence. For example, like if

08:28 you've got a data access layer, you could, you could talk about what is exchanged at the boundary there

08:32 so that your editors are all of a sudden super smart about autocomplete. And, you know, I was just doing

08:38 a massive overhaul to the course, Python courses website and change, change, like it was 110 commits

08:46 in this PR. It was like ridiculous. But before I checked them all in, I went through and I said, okay,

08:51 look for all the type warnings, look for anything that might've become like out of sync along the way.

08:56 And I caught like one or two things before I accepted the, or merged the PR back in. So it's

09:02 just, yeah, I absolutely think that's one of the most important additions.

09:05 And they also, it's so nice how you can leverage them at runtime as well. It's not only that they

09:10 allow you to check your code in a, in, in a way that doesn't require hitting every, every code path,

09:16 but you can build a data validation on top of it. And so many more.

09:21 Yeah, absolutely. I mean, look at libraries like Pydantic and FastAPI that are making interesting

09:26 runtime use out of it.

09:28 Absolutely.

09:28 And speaking of modern Python, like there's the, there was that proposed change to make

09:34 typing more efficient where it wouldn't actually import the things until really needed it. Or I

09:40 can't remember the exact PEP, but it was a way to sort of delay type information imports until you're

09:44 doing something like my PY and the Pydantic people and fast, you know, Sebastian and FastAPI. I was like,

09:49 wait, wait, wait, wait, wait, wait, we need this. Like, this is how our thing works. If you take away the

09:54 actual meaning other than for verification.

09:56 Yeah. I think the stringification of the, of the types that makes it really hard for these use cases. And, and

10:03 there's this other approach where they, where they basically lazily evaluate the types, I think, to avoid this

10:10 string problem. Yeah. I don't know if they've, I think it's still an open question of how to, how to proceed this. They, they, they,

10:16 we should have gotten the string types already and then decided to take some more time to,

10:22 to find a good solution for everybody. Yeah. I think that was, was sort of delayed. I can't

10:27 remember the total outcome, but I think it was like, we needed to think about this more and make sure all

10:31 the use cases are covered. Right. Yeah. Cool. Okay. Well, that's the language. One thing that we could

10:37 talk about real quick, that's pretty timely is this PEP. I just had Brett Cannon and Christian on

10:44 to talk about PEP 594, removing dead batteries from the standard library, which, you know,

10:51 it's pretty interesting. The idea is a lot of these libraries had been added. These core modules have

10:57 been added to the standard library in like 1992. And they've, they might not still be relevant.

11:03 For example, CGI is not the most common way to do web apps anymore. We've got micro whiskey and

11:08 the unicorn and all those things. Right. So does that still make sense to maintain them? Yeah.

11:13 I think that the set of libraries to remove them was pretty non-controversial because they're just

11:19 very, very old, obsolete, and also basically unmaintained. CPython is, has, I think like 90

11:27 core developers and they, they have like 1,600 open PRs right now. So it's very hard to maintain a huge

11:35 standard library with so little human resources. Yeah. So I think that was, yeah, pretty a good step.

11:43 What I really find interesting is, is the vision behind it. Like where, where, where should the standard library go?

11:51 How, what are the criteria in the future to, to include libraries? For example, we, I think usually,

11:57 recently we got a Tomlip into the, standard library. Right. Yeah. To join JSON and CSV and XML and all

12:04 those. Yeah. It's, it's, it started as a, as a PyPI library called Tomli and it's been adopted

12:11 quickly by a lot of the tools out there. And now it's part of the, or it will be a part of the standard

12:16 library. So this is, for example, this is something that is important to solve a, a bootstrapping

12:23 problem in the packaging ecosystem, because we have PyProject Toml now, and how is pip going to

12:30 pass the PyProject Toml file? For example, how are the other tools going to, to pass it? So it's,

12:35 it's very advantageous to have it in the standard lib, but we probably don't want to have passes for

12:40 every file format out there. I agree. So in fact, a lot of the ones that were removed

12:46 in PEP 594 are actually having to do with file formats. So you've got like AIFC, which is an audio

12:53 format. You have audio op, is it like the sun AU format? There's a bunch of, bunch of things like

12:59 that. Right. So yeah. I don't want to dive too much into that because we've done a whole show on it,

13:04 but I do think it's interesting to think about this as a modern, like the first step in a modernization

13:09 of the standard library. Right. Yeah. And then where it really blows open. And I think an

13:13 interesting inter, inter exchange sort of cross influence here is, as I already mentioned, the

13:18 368,000 external packages that are building on a lot of the new language features that I think are,

13:25 are super cool. And how much, you know, looking back, if that world existed already, how much smaller

13:31 would the standard library be? Right? Like, would your lib ever have to be in there? Well, we got requests.

13:35 I don't know. Maybe not. It could make a lot of sense for it actually to be there, like this

13:38 bootstrapping problem you talked about, but maybe it doesn't, right? Like, I think different choices

13:42 would be made, but yeah. What are your thoughts on the sort of ecosystem from the PYPI perspective?

13:48 Mm-hmm. So if we look at the, at the 30, the third party libraries, I think for me, modern Python is a

13:55 lot about expressive, expressive types, like Adhors for me is like the best example really to how to write

14:01 well-structured code using Adhors just got a new API, which is really, really nice. And I can definitely

14:09 recommend having a look at it. So it's become very easy to define immutable value objects, essentially,

14:18 that will allow you to basically structure your domain logic in a really expressive way.

14:23 Yeah, no, I was going to say that it did get a new API recently. I forgot that it,

14:26 it kind of inspired data classes and then it sort of turned the tables on it a bit, right? And sort of

14:31 rethought about how some of its stuff was offered as well, right?

14:34 I love that we have data classes in the standard library because it's like a mini Adhors that you

14:40 always have at your disposal, even when you don't want to take on third-party dependencies,

14:44 but it's definitely always worth looking at Adhors. It's very fast and has a lot of features and it

14:50 doesn't have this problem that you can only really update it once per year.

14:56 Yeah. And that's a super interesting point. You know, they considered putting requests in the standard

15:01 library for a while and requests is under the, I can't remember the exact organization,

15:05 but it's under an official PSF. Maybe it is, I think it is just the PSF organization now on GitHub,

15:11 right? It's sort of officially Python in a sense, but they decided not to put it into the standard

15:16 library, not because it didn't fit or it wasn't good enough, but because it would actually slow down

15:20 the development of requests and constrain it too much. And that's sort of similar here as well,

15:24 right? Adders can come out every day with new stuff and data classes yearly, right?

15:29 This portion of Talk Python To Me is brought to you by Microsoft for Startups Founders Hub.

15:36 Starting a business is hard. By some estimates, over 90% of startups will go out of business in just their

15:42 first year. With that in mind, Microsoft for Startups set out to understand what startups need

15:48 to be successful and to create a digital platform to help them overcome those challenges. Microsoft for

15:53 Startups Founders Hub was born. Founders Hub provides all founders at any stage with free resources to

16:00 solve their startup challenges. The platform provides technology benefits, access to expert guidance and

16:06 skilled resources, mentorship and networking connections, and much more. Unlike others in the industry,

16:12 Microsoft for Startups Founders Hub doesn't require startups to be investor backed or third-party

16:18 validated to participate. Founders Hub is truly open to all. So what do you get if you join them?

16:24 You speed up your development with free access to GitHub and Microsoft Cloud computing resources

16:29 and the ability to unlock more credits over time. To help your startup innovate, Founders Hub is

16:35 partnering with innovative companies like OpenAI, a global leader in AI research and development,

16:40 to provide exclusive benefits and discounts. Through Microsoft for Startups Founders Hub,

16:45 becoming a founder is no longer about who you know. You'll have access to their mentorship network,

16:49 giving you a pool of hundreds of mentors across a range of disciplines and areas like idea validation,

16:56 fundraising, management and coaching, sales and marketing, as well as specific technical stress

17:01 points. You'll be able to book a one-on-one meeting with the mentors, many of whom are former founders

17:06 themselves. Make your idea a reality today with the critical support you'll get from Founders Hub.

17:11 To join the program, just visit talkpython.fm/foundershub, all one word, no links in your show notes.

17:17 Thank you to Microsoft for supporting the show.

17:20 I think that's an interesting aspect of like sort of modern Python as well, right? This ability to just

17:27 continually deliver new features and adapt it as needed.

17:32 I also really love C-Adder because you mentioned Pydantic before. What I really like about C-Adder, it has kind of a similar,

17:39 so you can serialize and deserialize data classes and adders. The difference between Pydantic and C-Adders is that

17:48 Pydantic uses inheritance to give you this functionality, whereas with C-Adders, you just have your pure Python classes

17:57 without any, they don't need to inherit from anything. You just have, you decouple serialization logic from

18:04 your domain logic. And I think that brings a lot of advantages in structuring software.

18:10 This is the right one I have on the screen here, this C-A-T-T-R-S.

18:14 Right. Yeah.

18:14 Yeah.

18:15 Yeah. Interesting. So you can do things like put a frozen decorator onto just a regular Python class and

18:22 hey, it's frozen. You can create an instance of it and you can say unstructure and you get a dictionary,

18:27 you can structure it back until it would type, it parses it back, which is quite neat.

18:31 Yeah.

18:31 This one's new to me. Like I said, we're going to go through a lot of those,

18:34 a lot of those different things. Anything else you want to like give a quick shout out to

18:38 into the broader ecosystem before, like we'll dig into your hypermodern ones that you're using as well.

18:43 If you haven't seen Rich and HTTPX, those are definitely some to check out. And HTTPX,

18:50 basically we talked about requests. HTTPX has a very similar interface, but gives you both async and

18:56 sync operations. Yeah.

18:58 That's definitely a wonderful project.

19:00 I use HTTPX a lot and it's really nice because it's so familiar if you know requests, but if you happen

19:06 to find yourself doing cool async stuff, you're not stuck not doing async for one of the most

19:12 important parts, which is calling services, right? So you can await doing a get or a post or whatever.

19:18 Yeah, it's really nice. I'm not 100% switched to it instead of requests, but it's definitely one of

19:23 my go-tos as well. Cool. All right. Well, so that's sort of some thoughts on modern Python and where things

19:29 are going. Then you created this series, which is almost like a little mini course on how should you,

19:37 from your perspective, how should you structure and build modern Python projects and what tools should you

19:42 bring in? Not just should you use HTTPX over requests, but should you use Knox for testing and things like that?

19:50 Yes, right.

19:50 You might say yes for Knox.

19:52 Given that you work on it, right? So you did this article, this six-part series article on it, which I'll definitely link to.

20:00 But then also you created a cookie cutter template that'll allow people to jump into it.

20:06 I find this to be really helpful. I do this sometimes with my classes. You're like, "Well, here's the thing we built at the end,

20:11 but if you just want to create your own version of it, here's a cookie cutter to actually just create it with your settings and your values,

20:19 so you don't have to go through rebuilding it from scratch." And cookie cutter has been really influential in that sense, don't you think?

20:25 Absolutely. When I wrote the articles, there was example code on GitHub and I saw people forking the repository and I was like, "Oh, no.

20:34 They're all going to end up with this example code that displays Wikipedia articles and you can so am I going to keep all the dependencies up to date?

20:44 And how do I even do that?" And I was like, "No, I have to find a better way." And cookie cutter was definitely a good way to set up a project template.

20:54 And also something that was much easier for me to keep up to date. So there's after two years, definitely quite a bit of drift between the article series, which is from January 2020,

21:07 and the cookie cutter as it is today.

21:10 Yeah.

21:10 Yeah.

21:11 Yeah.

21:11 It's hard to keep an article or a video or a talk or whatever as a living thing that evolves as we gain more experience and stuff.

21:19 But the cookie cutter template, that's like software.

21:21 Yeah.

21:21 Plastic.

21:21 You can make it open source and have contributors that do some work for you, which is really, I'm extremely grateful for all the contributions I got there.

21:31 Yeah, that's great.

21:32 I see a bunch of contributors there.

21:33 Now, first, let's start with the, just the term, hypermodern Python.

21:37 What's the story with the naming here?

21:39 I actually brought you, now this is only for those that have a camera in front of them, that this is,

21:44 this is hypermodern Python.

21:45 So this is not Python.

21:47 This is a hypermodern chess game written in 1925.

21:51 Oh, interesting.

21:52 So this is where the name hypermodern really comes from.

21:56 It was meant a little bit tongue in cheek.

21:58 And also, I was very conscious that how's Python going to look like two years after I've written this article series.

22:06 Yeah.

22:06 The ecosystem evolves so quickly.

22:08 I decided to stick all these images in the blog that are basically past versions of the future.

22:14 It's a thing called retrofuturism.

22:16 So they're basically all like images from the 1920s and so on about how people in the future may be going to fly to the opera using planes that look like little birds.

22:28 Yeah.

22:29 It's sort of a steampunk mechanical bird.

22:32 People are cruising along in here.

22:34 It's, yeah, it's a, it's a cool picture.

22:36 It's a cool idea.

22:36 So what is hypermodern?

22:38 I think basically it's just whatever I was excited about and didn't know about beforehand.

22:44 I had used some tools, like more of the standard tools, like setup tools and pip-tools and talks.

22:52 And coming back to Python, I thought, wow, let's just check out all the things that have happened.

22:59 And let's see how maybe that might solve a few of the problems that I had.

23:04 Nice.

23:05 Okay.

23:05 So then you put together the article, which is, you know, it's a serious article.

23:10 It's not just a couple of paragraphs, right?

23:12 It's, it's quite a bit of writing.

23:14 Six articles.

23:14 Yeah.

23:15 Six articles.

23:16 And my little, or maybe it was your website.

23:18 It's like 11 minutes reading for this part, that kind of, kind of thing.

23:21 So it goes into pretty good detail with examples.

23:24 And then you captured it in this cookie cutter because you said that to put it into practice,

23:28 that's a pretty good way.

23:29 Now using cookie cutter is super easy.

23:32 You know, I'm sure people have, are familiar with this, but cookie cutter, give it the name.

23:36 It asks a bunch of questions, right?

23:37 Right.

23:38 I think maybe the right way to explore this would be to talk about the features and the

23:44 steps of the cutter that it does, right?

23:47 There's on the page for the cookie cutter GitHub repo, there's a big section that says features.

23:52 And that sort of talks about the different aspects and angles dimensions you decided to

23:57 bring in and the tooling there.

23:59 So how about we just go through these and sort of dive into them?

24:02 I think, I think people are going to discover some cool tools here.

24:05 So first of all, if you're going to build something meaningful, you've got to get some libraries off

24:11 PyPI.

24:11 Like there's very few projects that have no dependencies that are rich these days and not just rich the

24:17 package, but you know, feature rich.

24:19 Let's talk about the first one here.

24:21 Okay.

24:21 Take us through it.

24:22 Yeah.

24:23 So poetry really solved the problem for me because it's basically the one tool approach.

24:28 You have one tool that does everything for you.

24:32 It will allow you to define metadata for your package, build the package for you so you can

24:38 publish it on PyPI.

24:40 It can manage environments for you, install all the dependencies of your project and your project

24:45 itself.

24:46 And it can also manage the dependencies itself.

24:49 So it has a resolution mechanism and it has a log file, which is for me, a really important

24:56 feature because not only is it good for deploying services in a, in a reproducible and deterministic

25:03 way, but it's also for running the checks on your code and making sure that the checks run exactly

25:10 the same locally on your machine and CI with on and on the machines of your collaborators.

25:17 Yeah.

25:17 They're not as familiar with the poetry lock file as I should be, but basically it's like

25:23 hitting your versions in a requirements.txt.

25:26 Right.

25:26 Right.

25:26 But so often people just write, you know, here's my requirements.

25:29 I have requests or HCPX and I have FastAPI and I have SQLAlchemy or SQL model.

25:35 And you just type those out and you pip install -r and you're good to go until you want

25:40 to go back to an old version that might have a bug that that's the one in production.

25:44 But the bug might be because it has the old library of whatever.

25:49 Right.

25:49 And you don't know.

25:50 Right.

25:50 So you want to be able to pin those versions.

25:52 And then does the lock file also put the hashes in so they can't be fiddled with?

25:57 It does.

25:57 Yeah.

25:57 Yeah.

25:58 So it has the hashes and it gives you all the, basically the, all the indirect dependencies

26:04 as well.

26:05 So much like pip compile would do from the tools.

26:08 Yeah.

26:08 So, and that is tremendously useful.

26:11 Yeah, it absolutely is.

26:13 I'm a big fan of the pip-tools and pip compile.

26:16 We'll get to that later when we talk.

26:18 Yeah.

26:18 Yeah.

26:18 Yeah.

26:18 When we get to, there's a section, a whole section in the cookie cutter about it.

26:22 All right.

26:22 So it starts by setting up with poetry, right?

26:25 Absolutely.

26:26 Yeah.

26:26 I called poetry though, the one tool approach, and there has been a lot of work in the packaging

26:34 community to introduce standards, packaging standards that make it easier for the tools to

26:40 interoperate.

26:42 And I think this is actually a very good way to approach things in an ecosystem like

26:49 Python's to, to make it possible that you can define your package metadata for one tool,

26:55 like flit, and then use poetry to build the package or PDM and so many others.

27:02 And there has been a lot of great work that has made the packaging ecosystem more diverse.

27:09 Yeah.

27:10 Yeah.

27:10 There was some separation of the architectures of certain responsibilities, right?

27:15 Yes.

27:15 Yeah.

27:15 So there's perhaps six to one, which defined the metadata.

27:19 There was also an attempt to, to standardize log files, which I think would be great, but

27:24 that I've unfortunately has been rejected for now.

27:27 So I'm hoping that there will be more attempts in the future, but so as great as it is to work

27:33 with poetry, I definitely hope for the ecosystem to become even more diverse and more standardized,

27:39 to really give us more flexibility and interoperability.

27:44 Yeah.

27:44 Yeah, that is great.

27:45 Definitely seems like a lot of options are coming out around that these days.

27:49 And then the next one here is test automation with Knox.

27:53 What's your relationship with Knox, by the way?

27:55 Are you the maintainer or are you just a contributor or where's this?

27:59 I'm co-maintaining Knox.

28:00 Okay.

28:00 It was written by, by Thea Flowers and it has a large maintainer team.

28:04 At the time that I wrote the article series, I was just a fan of Knox and I started contributing

28:10 to it and I kind of ended up co-maintaining it.

28:13 Whoops, I'm contributing more than anyone else.

28:16 Does that make me more involved?

28:17 All right.

28:18 Yeah.

28:18 So tell us what the role of Knox plays in this.

28:20 So Knox is a great tool.

28:21 It's not just test automation.

28:23 It's really, it lets you automate basically all the developer tasks you have.

28:28 So this might be tests.

28:30 Okay.

28:30 It might be the other checks you have like linting, or it could be building your documentation or

28:37 building wheels.

28:39 If that's complicated in, in any way you can just, the great thing about Knox is that it uses

28:45 Python to let you define your, the tasks rather than basically having something like a make file

28:52 where you use the shell or in talks, you, you have an any file where you enter your commands,

28:57 right?

28:58 At least talks three.

28:59 I think talks for is also going to add Python configuration.

29:02 So Knox, it's really, so it's really inspired by talks.

29:06 I think so if you know talks, talks allows you to run tests on multiple versions of Python.

29:13 Yeah.

29:13 And it's been around for much longer.

29:15 It's very mature tool.

29:16 Knox is inspired by that.

29:18 It also lets you have this matrix of Python versions or even other things.

29:24 So you can similar to a pytest, you can parameterize your session functions and pass in,

29:32 say like a specific dependency that you want to test against in different versions.

29:37 So Knox is, is, is really useful if you want to have a single entry point into your, your project

29:45 maintenance, running all the tasks that you have and running them the same locally and on CI.

29:50 Yeah, this looks great.

29:51 I hadn't really explored this, this Knox file thing where you have these different tasks,

29:57 like a task, you know, task basically being a function.

29:59 Like, so you say like tests or lint, and you can just put a session decorator on it and just

30:04 say session dot install pytest, session dot run pytest or session install flake 8 and run it with

30:09 the parameters.

30:10 It's really nice and clean and it's, it's way better than a shell script.

30:15 I think it keeps you in Python, right?

30:16 Right.

30:17 Which is probably where you want to be on Python project.

30:19 And it runs on all the platforms.

30:20 So at some point I use make files to automate these things.

30:24 So the non-tox related things, I guess, don't work very well on windows.

30:29 So you don't have this problem.

30:31 Yeah, that's for sure.

30:33 Cool.

30:33 And then we kind of saw an example of that there, but linting with pre-commit and flake 8.

30:38 Right.

30:39 So it's about these two libraries.

30:40 I love pre-commit.

30:41 I actually, it wasn't in the first draft of the, of the article series.

30:47 I got some reviewers who commented on that.

30:50 I think Oni Fanchmitt from the pytest project and, and Hinnik Schlawak both mentioned that,

30:56 you know, you have to cover pre-commit.

30:57 And I was really skeptical.

30:59 I had made bad experiences with these kinds of pre-commit hooks that run.

31:05 So you make a git commit and then it doesn't work because you had some wrong white space in it.

31:13 And I thought my, I want my commits to be really snappy.

31:15 I'll, I just use Knox for that.

31:17 But after hearing these comments, I thought I'm going to give it a try, you know, like it's a new

31:22 tool, maybe it solves these problems much better.

31:24 And it really does.

31:25 I would really recommend anybody to give a pre-commit a try.

31:28 Basically you drop a YAML config in your project that defines the hooks that you want to run.

31:38 So this might be a hook that formats your code using black or that, that lints your code using

31:45 flake eight or so much more there.

31:47 There's an abundance of pre-commit hooks out there.

31:50 Oh wow.

31:50 Yeah.

31:51 There's, there's probably 20 pages in the list of pre-commit hooks that are at the top.

31:56 You click on supported hooks and pre-commit.com.

31:59 Right.

32:00 Pre-commit it's, so it's a git hook manager, but it's not just a git hook manager.

32:05 It's also a, a linter framework and a multi-linter multi-language linter framework.

32:10 So you can have your hooks written in, you know, Ruby, C++, you name it.

32:16 And it's very easy to use them in a Python project or basically any, any language project.

32:25 It works using git.

32:26 So basically installs the tools from their git repository and you can run them as part of your

32:35 git commits or all the other hook points that git offers, but you can also run it just in CI on your

32:43 entire code base.

32:45 And that's really what I, what I love about it is that it has this fail early philosophy.

32:50 So you really get very early feedback, but it also works to, as a gatekeeper for your default

32:56 branch and make sure that the, all the commits that go into your main branch are well-formed.

33:02 This is interesting.

33:03 I did have creator of pre-commit on the show quite a while ago.

33:08 I talked about it, but I hadn't, I think maybe some of these are new or I hadn't really appreciated

33:11 them before.

33:12 Like one that's really cool here is check JSON as a pre-commit and it checks JSON files for

33:18 parsable syntax.

33:19 So basically as part of your commits, it says, well, here's, I'm guessing here's a changed

33:24 JSON file.

33:24 Is this, you know, can it just basically be loaded with, you know, JSON.loadf or load, give it a

33:30 file.

33:30 Right. And another one is, yes, you're supposed to have unit tests, but you might not have unit

33:35 tests for everything.

33:36 So check AST just means like, can Python parse the files?

33:39 That's the word of like the compile, right?

33:41 In a sense.

33:43 Yeah.

33:43 I mean, those are just like the first couple out of this 20 pages.

33:46 So I'm, I need to come back to this and check Toml was another sort of similar to the check

33:50 JSON, check YAML, check up XML and so on.

33:53 Yes.

33:53 There's a, this repository called pre-commit hooks, and that has lots of very small hooks that

33:59 are tremendously useful.

34:01 And then you have larger tools that also offer integration with pre-commit like flake eight,

34:07 for example.

34:07 This portion of Talk Python To Me is brought to you by the compiler podcast from Red Hat.

34:15 Just like you, I'm a big fan of podcasts, and I'm happy to share a new one from a highly

34:21 respected and open source company compiler and original podcast from Red Hat.

34:27 With more and more of us working from home, it's important to keep our human connection

34:31 with technology.

34:31 With compiler, you'll do just that.

34:34 The compiler podcast unravels industry topics, trends, and things you've always wanted to know

34:38 about tech through interviews with people who know it best.

34:42 I was a guest on Red Hat's previous podcast, Command Line Heroes, and compiler follows along in that

34:58 excellent and polished style we came to expect from that show.

35:01 I just listened to episode 12 of compiler, how should we handle failure?

35:05 I really valued their conversation about making space for developers to fail so that they can learn

35:11 and grow without fear of making mistakes or taking down the production website.

35:15 It's a conversation we can all relate to, I'm sure.

35:18 Listen to an episode of compiler by visiting talkpython.fm/compiler.

35:23 The link is in your podcast player's show notes.

35:25 You can listen to compiler on Apple Podcasts, Overcast, Spotify, Pocket Cast, or anywhere you listen to your

35:31 podcasts.

35:31 And yes, of course, you could subscribe by just searching for it in your podcast player,

35:35 But do so by following talkpython.fm/compiler so that they know that you came from Talk Python To Me.

35:42 My thanks to the compiler podcast for keeping this podcast going strong.

35:47 On to continuous integration.

35:51 I feel like GitHub Actions has really sort of taken hold in the Python space as a way a lot of people are doing stuff there.

35:58 Absolutely. It feels like there was some kind of mass exodus from Travis CI to GitHub Actions.

36:04 It's so flexible and it goes way beyond just running tests and like the normal, what you'd normally

36:13 think of as CI. So you can automate a lot of your developer workflows centered around the collaboration with others.

36:21 Nice. The type of stuff I work on doesn't super lend itself well to GitHub Actions.

36:26 It does. It probably does somewhat, but it's not something I use that much.

36:29 But it seems like if you had a package that had maybe complicated builds or something like that, you could even use it to build your wheels and stuff like that, right?

36:38 Sure. Yeah. I mean, my the way I like to use it is to have most of the logic in Knox,

36:46 because that means I can always just test it locally and see if everything, you know, debug it easily.

36:51 And then I try to keep the GitHub Actions workflows pretty lightweight and just let them invoke Knox.

36:59 I usually have a matrix with that contains the Knox sessions.

37:04 So this might be the testing or running pre-commit or to lint the code or to build the documentations.

37:13 If that that's all valid, then the matrix has the Python versions that I want to test on.

37:19 Yeah.

37:20 If I'm working on a library, it's important to support not just the latest Python version, but probably Python 3.6 onwards, maybe even the upcoming Python version.

37:29 And then obviously platforms. So always, if you're, unless you're only working on one platform, try to have at least Linux and Windows, and then maybe, maybe macOS as well.

37:40 Yeah. Yeah. Yeah. This is neat. You know, people talk about, well, we can't really test this on Windows because I don't have a Windows machine or vice versa. Can't test it on Mac or so easy.

37:49 Yeah. So this here's your three platforms right here. Right.

37:52 I'm not saying it's easy to debug it. If something goes wrong and you're only working on macOS or Linux, you probably at some point want to have a virtual machine with the running windows.

38:02 If you don't have a physical Windows machine, but it's also not hard to get one these days, too. But otherwise, you know, it's very easy.

38:10 To integrate Windows in your CI.

38:12 Yeah, very cool. And then the next one has to do with documentation here.

38:16 Right there.

38:17 Sphinx, Mist, and Read the Docs. And one of the themes. So yeah, pretty.

38:22 When I wrote the articles, it was just Sphinx and Read the Docs. Mist hadn't happened yet. So, well, Mist, maybe let's start with Sphinx, because I guess many people will already be familiar with it. It's a Python documentation generator. It's also used for Python's own.

38:40 So for example, the library docs. It's been around for a long time.

38:46 It's a very expressive language to write technical documentation.

38:54 Sometimes too, sometimes too, sometimes too, sometimes too, sometimes too, sometimes too, sometimes too, sometimes too, sometimes too, sometimes too, sometimes too, sometimes too, sometimes too, sometimes too, sometimes too, sometimes too, sometimes too, sometimes too, sometimes too, sometimes too, sometimes too, sometimes too, sometimes too, sometimes too, sometimes too, sometimes too, sometimes too, sometimes too, sometimes too, sometimes too, sometimes too expressive. It's not the lightweight language that we know Markdown to be.

39:02 Right.

39:03 And Markdown has really conquered the world. And when I wrote the documentation chapter, I think I linked to an article by Eric Holcher from Read the Docs, comparing the two formats. And that was before, before Mist happened. And he said, you know, there's use restructured text. It's just so much more expressive. And it lets you have cross references. And all of these things has the powerful directives.

39:28 Anyway, now we have Mist. And Mist allows you to do essentially the same thing in Markdown. There's an extension syntax, and you can have directives, you can have cross references. And it's a lot of fun to write documentation in Mist. So this was a recent addition to the project template to support Markdown documentation.

39:50 And for those who don't know, I also I did have a show recently with the Mist folks, about Sphinx and Mist and so on. And there I learned that one of the things that's cool is you can inline restructured text. So if you get to a section, you're like, this is just Markdown. I want to do this. Do a little tiny bit of restructured text instead of living in it.

40:07 You actually need to do that.

40:09 You actually need to do that still for your generated API documentation. So Sphinx has this extension called AutoDoc that will take all the doc strings in your code and transform that into API documentation.

40:22 And that still doesn't have a replacement. What you do is you write your doc strings, you know, using restructured text, maybe using Google style doc strings or NumPy style doc strings. And then you use the AutoDoc directive to basically quote it in line in your Markdown documentation.

40:42 So that's a little bit of restructured text there. I think I'm working on filling this gap somewhere going on and I'm really looking forward to that feature coming because then everything will be just marked down.

40:54 Yeah, that'd be great for sure. I do want to give a quick shout out to Paul Everett's course that he wrote over at Doc Python on Sphinx. And listen, if you're interested, check out this free course that he put together for us over there. So that's worth checking out. Now I'll put a link in the show notes.

41:08 Now, if you're building a Python package that goes on PyPI, like not everything people build with Python goes on PyPI or even should be structured in the shape of a package potentially. But a lot of them are right. A lot of libraries are. So you talk about automating uploads to PyPI and test PyPI. Want to talk about the story there?

41:28 Yeah. So PyPI, the Python package index there actually has a sibling called test PyPI, which is just a separate instance. It's very useful to upload your wheels and sdiscs to test PyPI before you actually do a release because you can check them and see if everything is the way you expect it to be.

41:50 Yeah.

41:51 Yeah.

41:51 And basically install the package end to end. And in CI, what I like to do is I have the switch where if it's an actual release, I upload to PyPI. But in all the other cases, I just upload to test PyPI. So every commit that goes into the main branch is going to be built and uploaded to test PyPI.

42:12 You can't change what you put into PyPI. You can add new versions that replace it, but you can't change a version really.

42:19 The best you can do is yank the release. It's still going to be there for those who have pinned the version, but otherwise it'll be invisible to those who just want to get the latest release. But yeah, there's no replacing.

42:32 Yeah. So it's a nice reminder and automation to set up to remember there's test PyPI and automatically sort of have your project know and use it.

42:41 All right. Here's another one. I want to talk about stuff I was learning. This one is definitely new to me. And this is cool. Automate release notes with release drafter.

42:49 What's about release drafter? This is cool.

42:51 So release drafter takes the titles of your merged PRs and it creates a draft release. So the release in this sense is the GitHub release. That is something that you can see on the right hand side of the GitHub repo page.

43:10 You have this releases link and that basically gets you to either a list of tags or you can describe the changes. So it's essentially release notes on GitHub.

43:24 So I think the release drafter is really handy for that. Now actually you can, so GitHub releases have an auto generate button. So some of this functionality you will actually get even without using the release drafter action.

43:49 So I think the release drafter action is somewhat more flexible, what it gives you and basically means you're going to have to add a GitHub actions workflow for it and the configuration file.

44:03 So you can provide a template for your release notes and some, you know, replacement marker that a placeholder that where all the PR titles go.

44:15 I think it's cool. And it even has a draft, like you, you can see the draft release notes as well.

44:22 Yeah.

44:23 You can see it. And then you have a button to publish the draft release. And if you don't have a tag yet, that's also going to add a git tag to your repository.

44:32 So that's a really lightweight approach to the release notes question.

44:39 So I see that it has a what's changed, but I also saw in the release drafter had like bug fixes and stuff. Is there a way to teach it? Like these PRs are related to bugs and these are additions and stuff like that?

44:51 Yes. You can do that using labels on your PRs. So if it's a bug fix and you have a label, you know, then you can put it under a separate section.

45:00 Well, so basically just drive it with GitHub labels. Cool. All right. We got a lot to go through here. So maybe these next two are pretty quick here. Actually, the next three here.

45:07 You talked about this sort of article and the cookie cutter drifting quite a bit apart because so many things have changed. One thing that seems to be pretty stable is like since black came out, people are all about just black.

45:19 It hasn't seemed to gone out of style at all. I think that's pretty, pretty stable one, right?

45:24 It really makes a huge difference for productivity. And I feel if I'm contributing to somebody else's project, it makes things so much easier to know that there's a consistent style.

45:35 I don't need to be afraid to destroy somebody's, you know, well-crafted, handcrafted, formatted code. I can just run black. And it's also great, really helps readability. It's basically the style becomes invisible. So I love black. And black now, better status in January. So we now have like...

45:55 Official black.

45:55 Finally.

45:56 Well known as hash 000000. There's no more debate.

46:01 So yeah, I'm definitely, definitely a big fan of black.

46:04 Indeed. I also give a shout out to Predeer as well. And then sort of related, you have import sorting with iSort.

46:11 I've been using reorder Python imports for a long time, which is also a tool by Anthony Sotile, who wrote Precommit.

46:18 Yes. I wanted to give Anthony a shout out, but I wasn't 100% sure that I had the name just right in my memory. So I didn't want to like misattribute it. But yeah, he also did Precommit, which I had him on the show for.

46:27 Right. So these days, I actually like to use iSort, which is what everybody uses. It's since iSort 5, it's become much nicer to use. It uses the AST more. It has no trouble figuring out what your third party dependencies are.

46:42 And it has an option. It has these profiles to make it really easy to be compatible with black style.

46:49 And what I like to do is I like to put each import on a single line, which is actually what reorder Python imports does as well. And it greatly reduces the chance of merge conflicts.

47:03 Oh, right. Okay. Yeah, of course. Cool. A quick question, stepping back to the release drafter. Michael out in the audience says his biggest hurdle is for doing regular and good release for doing regular and good releases are change logs.

47:16 How does release drafter sort of fit into that? Basically, if you structure everything as a PR, it'll capture it?

47:23 Yes. So release drafter only drafts the GitHub release for you. If you want to have, say, a page in your Sphinx documentation, you're going to need to pull that out. There's actually a...

47:37 I'm sorry. That's his GitHub handle. I'm sure we should put a link later, but there's a tool that will pull the GitHub release and insert it into your Sphinx documentation. So you can do that.

47:50 And there's also TownCryer, which really should be mentioned, and Scriv, which was written by Ned Batchelder. Those are tools that allow you to add release notes to your PRs as snippets or fragments. And that scales very well if you have an open source project with many contributors. So yeah, it's still figuring out the best way to maybe integrate all of these in some way.

48:16 Sure. You can overdo it for sure. All right. I think a quick, just a quick shout out. Speaking of Ned Batchelder, we have pytest, Coverage.py, and CodeCov all in there is neat. And then CLI interface with Click. That's an interesting one, a popular one as well.

48:33 Absolutely. So that's from the Palace project. So the same family of projects like Flask. There's also a nice wrapper for Click called Typer.

48:42 Yes.

48:42 It's written by the FastAPI author.

48:44 Yeah. When I saw that using Click, I'm like, hmm, you're such a fan of types. Maybe Typer is also relevant here.

48:49 Actually, I just had another look at Typer and I think I do like it after all. I actually really like it. Initially, I was like, well, it's actually not so. I kind of like how Click gives you these decorators and separates your option help texts from the actual function.

49:06 But it is true that Typer really reduces duplication because you don't have to repeat the types of your options. They're just type annotations of your parameters. So that's really neat.

49:17 Nice. Continuing with the typing story, we've got two things here. A static type checking with mypy. I suspect a lot of people who are really into typing know about this.

49:25 Like the CLI, you run against your code and it'll make sure everything hangs together. If this function is calling that function with that variable, and you said that variable is one of the things that make sure that all is going to fit together.

49:35 And if you get that working, then you might be open to having something like mypyC for optimizations and so on, which is also interesting.

49:42 But one that maybe people haven't heard about is runtime type checking with Typeguard.

49:46 Right. I think it's really one of the most undervalued projects out there in the typing space. Typeguard is so useful.

49:54 When I first heard about it, I was like, why would you want to runtime type check your code?

49:59 If you have a static type checker, you know why?

50:02 Then you need to hit all the code paths.

50:05 Static type checking is great because it can just basically deduce the type correctness.

50:11 Typeguard is really useful if you're, for example, if you're interfacing with third-party libraries who may or may not have type annotations.

50:21 If they do, great.

50:22 But you know, how much do you trust them?

50:25 Right.

50:25 Yeah.

50:26 Just because it says it, nothing enforces that where it said it returns an int.

50:30 It could return none.

50:31 Yeah.

50:31 And it should have said optional int, but it didn't.

50:33 Your code can absolutely have type correctness as far as mypyC is concerned.

50:37 But that might be just because there are some any types or it's just kind of a loosey type because there's no way to be stricter about the actual types.

50:47 And Typeguard will check that.

50:48 So the way I like to use Typeguard is as a pytest plugin.

50:53 So you're basically running your test suite.

50:56 And if you have complete code coverage, that should give you a good chance to catch any type.

51:02 Oh, interesting.

51:03 So you can turn it on while your tests are running and it will runtime check everything.

51:07 But then in production, not turn it on?

51:10 Exactly.

51:10 You basically specify it.

51:13 So you install it next to pytest and then you pass an option.

51:17 I think it's Typeguard packages and pass the name of your package.

51:21 And then Typeguard is going to wrap every function in your code and check the parameter types and the return type.

51:31 So that's really useful.

51:33 It's also a library.

51:33 So if you want to explicitly check in production, you can also use Typeguard for that.

51:38 Nice.

51:38 Yeah, it's got the type checked decorator, which probably you can just put that on stuff you want to make sure it's checked.

51:43 Exactly.

51:43 Okay.

51:44 Well, that's a good one to learn.

51:45 Another one is you create your project.

51:48 You start building it.

51:50 Two years later, you know, some feature is added.

51:53 Some other language feature might be not the way to do things.

51:56 So you talk about automated Python syntax upgrades with PyUp upgrade.

52:01 Yeah.

52:01 That's another Anthony Sotile tool.

52:04 So it's also, you can run it from pre-commit.

52:08 It's going to essentially pass the AST of your, so the abstract syntax tree of your code and look for things that have better ways to express them in your versions of Python.

52:22 So basically what you say, you drop Python 3.6 and automatically you get unions like the pipe.

52:31 Right, right.

52:32 Like int pipe none versus optional bracket int.

52:35 Something like that, right?

52:36 Yeah.

52:37 These kinds of things.

52:38 Or yeah.

52:39 Giving you nice set comprehensions.

52:42 Yeah.

52:42 Kind of like calls to the set built in.

52:45 Those of these.

52:46 And it's very nice if you're supporting multiple Python versions and you've been waiting to use this feature.

52:52 And now finally you can drop the last Python version that didn't support it and you get this for free.

52:58 I just run.

52:59 Yeah, that is interesting.

53:00 I hadn't really thought about that.

53:02 You know, some of these are not language features in the sense that people are thinking, oh, well now I can use async and await, which would take like a real important, significant change.

53:12 But it's just like, oh, you, you know, now you're able to, because of PEP 289, pass a generator directly to the min function or max or sum rather than a list comprehension, which then gets processed, right?

53:25 And that would just be more efficient across the board.

53:27 And so that just happens automatically, right?

53:29 Cool.

53:30 Yeah.

53:30 Very neat one.

53:30 All right.

53:31 Next.

53:31 Security audits.

53:33 There's Bandit.

53:34 Bandit is a tool that looks at your Python code and figures out if there are any things that may or may not give you a security vulnerability or any kind of security issue.

53:47 It flags some things like just importing a subprocess and you can no QA it.

53:54 I still find that useful because it just gives me a moment to think about all the implications of spawning other processes from our Python code.

54:03 And, but it, it has a lot of checks in your, in your Python code base.

54:08 So it's, it's very nice to use it to guard yourself against some.

54:12 Right.

54:13 Like it'll detect things like YAML dot load should be YAML dot safe load.

54:18 And I bet there's something there about pickling.

54:21 Yeah, for sure.

54:22 It's caught of me.

54:23 Could be.

54:24 All right.

54:25 Yeah, exactly.

54:26 Safety is the other one.

54:28 Yeah.

54:28 That basically just checks your dependencies.

54:30 So there's a, there's a curated database of security vulnerabilities and it's going to see if you have any dependency in a version that was vulnerable.

54:39 Nice.

54:40 And just stepping back to some moment, Nick Ma points out that hyper is amazing when it comes to the documentation in the --help option.

54:49 Yeah.

54:49 Pretty cool.

54:50 Let's see.

54:51 Going back to, yeah.

54:52 Checking the documentation with xdoc test.

54:55 So xdoc test is essentially a rewrite of a standard library or utility.

55:01 It's called doc test.

55:02 And what does it do?

55:04 So suppose you have a doc string with an example code that shows how you, how you're supposed to use a library or a function.

55:11 And you commonly write these with a, the Python interpreter prompt to give you like, what, what does the user type import my package?

55:20 And underneath you have the output of whatever, you know, functions you call it and so on.

55:26 So doc test runs these examples and sees if they produce the expected output, they don't throw a raise exceptions and so on.

55:34 xdoc test is a rewrite that uses the AST more than regular expressions, which is nice.

55:41 And it's also a bit more flexible.

55:42 So has a few nice features compared to doc test.

55:47 Right.

55:47 Cool.

55:47 So if you have an example in your documentation, here's a way to automatically make sure it's all good.

55:53 Also another audience question, follow up here.

55:56 Vasil asks, what do you think about services like Sink, S-N-Y-K, S-N-Y-K, S-N-Y-K, to check dependencies, like for security, right?

56:06 So you depend on Flask, Flask depends on it's dangerous, it's dangerous.

56:12 Who knows?

56:13 Theoretically could have some issue like that kind of check.

56:16 I'm thinking he's asking.

56:16 I haven't used S-N-Y-K yet.

56:17 So I'm only familiar with, with safety.

56:21 Nice.

56:21 Okay.

56:22 Cool.

56:22 Getting close to the end.

56:24 Then I have a question about all of these taken as a whole.

56:26 All right.

56:27 Generating API documentation with Autodoc and Napoleon.

56:31 Right.

56:31 So we talked about this before.

56:33 This takes, it takes your doc strings and generates API documentation.

56:36 Right.

56:37 And this is not a RESTful API, like Swagger, OpenAPI.

56:41 This is, this is like my Python libraries function documentation, right?

56:45 Exactly.

56:46 Yeah.

56:46 That's so the reference for your, the functions in your, in your package.

56:51 Got it.

56:52 Right.

56:52 Right.

56:52 Right.

56:53 Right.

56:53 And Napoleon is a tool that will add support for doc strings that are written Google style,

57:00 for example, or some other conventions for doc strings.

57:02 So Google style is pretty lightweight, which I'm a fan of that as well.

57:06 Yeah.

57:07 Yeah.

57:07 Yeah.

57:07 Declaring your arguments and, and returns.

57:10 Okay.

57:10 Nice.

57:10 Generate command line reference with Sphinx click.

57:14 So I'm guessing if you're using click might be relevant.

57:18 Right.

57:19 So you already have all your option help texts and, you know, command descriptions in, in click.

57:26 So why not just use them to generate the documentation.

57:29 And that's basically what Sphinx click does.

57:32 So it takes, so you, when you build your documentation and you use things like auto doc or Sphinx click,

57:39 you have to remember to install your own package.

57:41 And then these tools can just import it and read the, read all the documentation that you have inline in your code,

57:47 including click option up text.

57:50 Yeah.

57:50 Very cool.

57:50 All right.

57:51 You've done all the work documented it.

57:54 You've tested it.

57:54 It's good to go.

57:55 How are you going to release it?

57:56 Put it on GitHub.

57:57 And the last one is managed project labels with GitHub labeler.

58:00 So the idea of labeler is that you, instead of going through the web interface and then typing in all the,

58:10 color codes and hacks and so on, you, you can just use, a file that you put in your repository to manage all your,

58:18 all your labels for your PRs and for your issues.

58:21 So that's really helpful and makes it really easy if you're collaborating with other people.

58:26 Nice.

58:26 Yeah.

58:27 That's great.

58:27 Okay.

58:28 Well, that's your cookie cutter.

58:30 And in one fail swoop, in one single CLI cookie cutter command, you get all of these.

58:36 So when this runs, I should have just run it and played with it.

58:39 But does it give you an option to say, you know, don't install my pie or does it just kind of give it all to you?

58:46 What's the, I know cookie cutter has a lot of conditional behaviors and stuff.

58:50 Like what's the experience of using this to create a project?

58:52 I have personally resisted putting in too many options.

58:56 It's kind of, I try to find, to kind of show one way that works and also keep it maintainable.

59:03 So I don't have a lot of, I don't want the combinatorial explosion.

59:07 There's a little bit of options that it gives you.

59:10 So you can choose the license, for example, and cookie cutter allows you to hide or show parts of your file tree, depending on what the user chose.

59:19 But basically it's not meant to be the, all the different packaging tools, all the different ways like talks, knocks, the different CIs that there was a conscious decision to basically say, okay, here's one way to do it.

59:32 And I can really curate it and make sure that it all works.

59:36 Sure.

59:36 Keep it opinionated and straightforward and whatnot, right?

59:40 I suppose if people really wanted to use talks instead of knocks and they wanted to use typer instead of click, they could fork the repo, create their own template, right?

59:48 And roll with that.

59:49 Yeah.

59:49 Cool.

59:49 All right.

59:50 Well, very interesting.

59:51 One more quick audience question here from Michael says, can labeler, as in GitHub labeler, export existing settings?

59:58 It'd be great to unify labels across repos.

01:00:01 Any idea?

01:00:02 Right.

01:00:02 I think there is a separate tool to do that.

01:00:06 So I don't think that GitHub labeler does it, but I remember that that was actually a community contribution.

01:00:13 And I remember that the contributor who added this feature first went and exported the existing configuration from whatever we had in the repository.

01:00:23 Okay.

01:00:24 Yeah, cool.

01:00:24 So.

01:00:25 Yeah, very nice.

01:00:25 All right.

01:00:26 Well, we are just tiny bit out of time here.

01:00:30 So unfortunately, even though there's a bunch of other stuff I wanted to cover, I don't think we're going to be able to because we cover so many cool things.

01:00:37 You know, I did want to just give a quick shout out to your music.

01:00:41 And in addition to being a lawyer and a software developer and open source person, you also do like compositional stuff.

01:00:48 Right.

01:00:49 So you've got on your website, you've got a whole section.

01:00:51 How many videos here?

01:00:52 Like 10 different music videos that you've put together that are pretty neat.

01:00:56 You want to just give a quick shout out to that?

01:00:58 Yeah.

01:00:58 So I spent, I think, 10 years working both as a software engineer and a touring and recording musician.

01:01:06 Also as an arranger.

01:01:08 So I arranged some string quartets.

01:01:11 So I did arrangements for Naima Hussaini, who's a German indie singer.

01:01:17 Definitely check her.

01:01:19 Jack E.

01:01:20 I've been on tour with her already across all of Europe and wonderful reggae inspired singer.

01:01:27 And there are so many more.

01:01:29 Yeah.

01:01:30 It's, yeah.

01:01:32 I'm very grateful for the musicians I've been able to play with.

01:01:36 Yeah.

01:01:37 That's fantastic.

01:01:37 I listened to a bunch of them.

01:01:39 My favorite is Immer Alles Kustisch im Deutschen Theater.

01:01:43 That's the one with Naima Hussaini.

01:01:45 That was a really good one.

01:01:47 They're all good.

01:01:48 But that one was really excellent.

01:01:49 And then Michael also thinks that we should have a whole podcast about your compositional tools.

01:01:54 Do you use Python for any of this stuff?

01:01:56 Or is it kind of a separate world?

01:01:57 Sadly, it's pretty much a separate word.

01:02:00 I've been using Ableton a lot.

01:02:02 And we didn't really get into automating all of this with Python yet.

01:02:07 Not yet.

01:02:08 Not yet.

01:02:09 Also.

01:02:09 I think Lucas Lange does this kind of stuff, though.

01:02:12 Yeah.

01:02:13 Cool.

01:02:13 It can be done.

01:02:14 Yeah.

01:02:14 People should check out Fox.

01:02:15 Are you familiar with Fox.

01:02:17 And that whole programming with composition, building up music with Python?

01:02:22 Have you seen this?

01:02:23 I know.

01:02:23 Oh, my gosh.

01:02:25 I've got to check this out.

01:02:26 Every time I search for it, Fox.

01:02:27 I think it's Fox.

01:02:28 Python.

01:02:29 I think that's what it is.

01:02:30 Check out the videos.

01:02:31 There's some neat live coding music with Fox.

01:02:35 And Python.

01:02:35 Every time I just randomly pick one of these videos, it's not really necessarily the best one.

01:02:40 But there's some really neat ones of sort of like adding instruments in with Python.

01:02:43 It's cool.

01:02:44 People should check that out.

01:02:45 Yeah.

01:02:46 All right.

01:02:46 Well, we are out of time.

01:02:49 Really quickly.

01:02:50 Final two questions.

01:02:51 You're going to write some Python code.

01:02:53 What editor are you using these days?

01:02:54 I use Space Max.

01:02:55 I've been using Emacs for a long time and use it with VI bindings now.

01:03:00 I like it.

01:03:00 Right on.

01:03:01 And I'm almost hesitant to ask you for a notable PyPI package because we covered so many.

01:03:06 But maybe just like, you know, what one stands out to you?

01:03:08 Like you want to just give a shout out to either one we covered or...

01:03:10 I just named TypeGuard because it really deserves...

01:03:14 Okay.

01:03:14 TypeGuard 3 is going to come out hopefully soon, bringing new features.

01:03:18 Cool.

01:03:19 All right.

01:03:19 Well, final call to action.

01:03:21 People want to get started.

01:03:22 This hypermodern project idea that you've created, what do they do?

01:03:25 So just go to the cookie cutter hypermodern Python repo.

01:03:29 Check out the contributor guide and the code of conduct.

01:03:32 And we love contributors.

01:03:35 So...

01:03:36 Hold on.

01:03:36 How relevant is going back and reading the article?

01:03:39 Has it drifted too far or is it enough to get like some of the zen?

01:03:42 Or if you've listened to this, are you kind of good to go?

01:03:44 I think the article series is still fun to read.

01:03:47 I think these days what I would recommend is that you don't just take the example code.

01:03:53 Maybe just generate a default project from the cookie cutter and then take a look at that as well.

01:04:00 Because some things have changed in the two years.

01:04:03 But the article series kind of gives you the motivation for everything.

01:04:07 And it's probably also more fun to read than the user guide for the project template, which is also there and very detailed.

01:04:14 But yeah.

01:04:15 Yeah.

01:04:15 Fantastic.

01:04:16 All right.

01:04:16 Well, thank you so much for being on the show.

01:04:18 And congrats on the cool project.

01:04:19 Thank you very much.

01:04:20 You bet.

01:04:21 Bye.

01:04:21 Bye-bye.

01:04:22 Bye-bye.

01:04:23 This has been another episode of Talk Python To Me.

01:04:26 Thank you to our sponsors.

01:04:27 Be sure to check out what they're offering.

01:04:29 It really helps support the show.

01:04:30 Starting a business is hard.

01:04:33 Microsoft for Startups, Founders Hub, provides all founders at any stage with free resources and connections to solve startup challenges.

01:04:41 Apply for free today at talkpython.fm/foundershub.

01:04:46 Listen to an episode of Compiler, an original podcast from Red Hat.

01:04:50 Compiler unravels industry topics, trends, and things you've always wanted to know about tech through interviews with the people who know it best.

01:04:58 Subscribe today by following talkpython.fm/compiler.

01:05:02 Want to level up your Python?

01:05:04 We have one of the largest catalogs of Python video courses over at Talk Python.

01:05:08 Our content ranges from true beginners to deeply advanced topics like memory and async.

01:05:13 And best of all, there's not a subscription in sight.

01:05:16 Check it out for yourself at training.talkpython.fm.

01:05:19 Be sure to subscribe to the show, open your favorite podcast app, and search for Python.

01:05:23 We should be right at the top.

01:05:25 You can also find the iTunes feed at /itunes, the Google Play feed at /play, and the direct RSS feed at /rss on talkpython.fm.

01:05:34 We're live streaming most of our recordings these days.

01:05:38 If you want to be part of the show and have your comments featured on the air, be sure to subscribe to our YouTube channel at talkpython.fm/youtube.

01:05:45 This is your host, Michael Kennedy.

01:05:47 Thanks so much for listening.

01:05:48 I really appreciate it.

01:05:49 Now get out there and write some Python code.

01:06:07 I'll see you next time.

01:06:12 Thank you.