362-hypermodern-python.vtt

WEBVTT

00:00:00.000 --> 00:00:02.280
- Hello, YouTube.


00:00:02.280 --> 00:00:03.360
Hello, Claudia.


00:00:03.360 --> 00:00:04.640
Thanks everyone for-- - Hello.


00:00:04.640 --> 00:00:05.480
- Hello, hello.


00:00:05.480 --> 00:00:07.640
Thanks for joining us for the live stream and the recording.


00:00:07.640 --> 00:00:10.260
If you got comments, please put them into the live chat.


00:00:10.260 --> 00:00:11.100
If you're watching this live,


00:00:11.100 --> 00:00:12.640
we'll try to make it part of the show.


00:00:12.640 --> 00:00:16.240
Claudia, are you ready to kick this off?


00:00:16.240 --> 00:00:17.200
- Let's go.


00:00:17.200 --> 00:00:18.040
- All right.


00:00:18.040 --> 00:00:21.880
Claudio, welcome to Talk Python to Me.


00:00:21.880 --> 00:00:23.280
- So happy to be here.


00:00:23.280 --> 00:00:25.240
- I'm so happy to have you here.


00:00:25.240 --> 00:00:27.640
It's great to be talking to you.


00:00:27.640 --> 00:00:28.960
And this is one of those episodes


00:00:28.960 --> 00:00:32.240
that's gonna be so fun because what it's gonna turn out


00:00:32.240 --> 00:00:35.360
to be I'm pretty sure is diving into a ton of little tools.


00:00:35.360 --> 00:00:38.280
And I can tell you just doing a little bit of research


00:00:38.280 --> 00:00:40.200
and putting together some show notes for this,


00:00:40.200 --> 00:00:42.480
like, oh, there's that thing and oh, look this too.


00:00:42.480 --> 00:00:43.560
Oh, I didn't know about this.


00:00:43.560 --> 00:00:48.560
So you've assembled this conglomeration of tools


00:00:48.560 --> 00:00:51.400
and techniques that you're putting under


00:00:51.400 --> 00:00:53.560
the hyper modern banner.


00:00:53.560 --> 00:00:55.280
And I think it's gonna be a lot of fun to talk about.


00:00:55.280 --> 00:00:57.640
So yeah, we're gonna have a good time.


00:00:57.640 --> 00:00:58.640
Looking forward.


00:00:58.640 --> 00:00:59.640
Indeed, same.


00:00:59.640 --> 00:01:03.560
Now, before we get into that, let's talk about your story.


00:01:03.560 --> 00:01:07.760
How did you get into programming and over here to Python?


00:01:07.760 --> 00:01:13.200
So I think one day my dad, that must have been in the 80s, came back with and said,


00:01:13.200 --> 00:01:15.200
"I bought a computer."


00:01:15.200 --> 00:01:16.720
And I was really excited.


00:01:16.720 --> 00:01:25.240
I imagined there's going to be a room filled with all these machines and ran down the corridor


00:01:25.240 --> 00:01:29.840
and turned out to be some kind of keyboard, as it seemed to me.


00:01:29.840 --> 00:01:33.320
So there was a Commodore 64.


00:01:33.320 --> 00:01:38.920
And initially, we just played all those great 8-bit games.


00:01:38.920 --> 00:01:42.920
And eventually, I started programming a little bit


00:01:42.920 --> 00:01:43.440
in BASIC.


00:01:43.440 --> 00:01:48.880
And I think that's kind of when I really found out


00:01:48.880 --> 00:01:49.880
how much fun this is.


00:01:52.920 --> 00:02:00.840
And then I think I was interested in a lot of other non-computer things for a long while.


00:02:00.840 --> 00:02:07.720
I went to uni, I studied law. >> As most programmers do, of course.


00:02:07.720 --> 00:02:18.360
>> Yeah. But somehow the interest in formal systems always stayed with me, and law,


00:02:18.360 --> 00:02:24.200
especially continental law, German law is very much like a little bit like a calculus,


00:02:24.200 --> 00:02:33.240
tracing back to ancient Rome. And I got interested in logic. And there's a small


00:02:33.240 --> 00:02:40.920
research community working on applying AI and logics to legal theory. And that was really my


00:02:40.920 --> 00:02:46.560
my gateway drug to get back into programming, really, logics.


00:02:46.560 --> 00:02:57.480
And I think I programmed this like a little flashcard system to help me prepare for the


00:02:57.480 --> 00:03:00.680
for the law exams.


00:03:00.680 --> 00:03:01.880
Nice.


00:03:01.880 --> 00:03:02.720
Yeah.


00:03:02.720 --> 00:03:09.760
Eventually, I decided, you know, I have to, I want to get really deep into this.


00:03:09.760 --> 00:03:13.120
and I started studying computer science


00:03:13.120 --> 00:03:17.600
and pretty much never went back to law after that.


00:03:17.600 --> 00:03:22.400
So I have a law degree, but working as a software engineer.


00:03:22.400 --> 00:03:23.240
- It's interesting.


00:03:23.240 --> 00:03:24.840
I hadn't really thought about it with law.


00:03:24.840 --> 00:03:27.800
I do have a friend who's a lawyer in software.


00:03:27.800 --> 00:03:30.700
So I know it happens for sure,


00:03:30.700 --> 00:03:34.960
but thinking about the way you have to


00:03:34.960 --> 00:03:37.640
mentally sort of solve the problems


00:03:37.640 --> 00:03:43.480
and the constraints of like legal contracts and laws and stuff and how they apply. That's


00:03:43.480 --> 00:03:47.400
actually kind of a similar skill to thinking through solving a computer programming problem


00:03:47.400 --> 00:03:51.760
with APIs and what the computer can do and stuff, right?


00:03:51.760 --> 00:03:57.040
And it's such a human way of thinking. So it's really interesting from an AI point of


00:03:57.040 --> 00:04:03.440
view because it's not the kind of really clear logical deductions that you have, but there's


00:04:03.440 --> 00:04:10.800
a lot of everyday knowledge that you need to have and the feasible rules.


00:04:10.800 --> 00:04:12.440
So it's quite exciting.


00:04:12.440 --> 00:04:14.000
Yeah, very neat.


00:04:14.000 --> 00:04:18.600
Now what kind of code and what kind of stuff are you doing these days?


00:04:18.600 --> 00:04:27.080
So I've been working mostly on cybersecurity.


00:04:27.080 --> 00:04:35.880
So I'm working for a company for almost 14 years that's doing cybersecurity as a service.


00:04:35.880 --> 00:04:45.920
So we're working mostly on C++ services, so high performance data intensive services.


00:04:45.920 --> 00:04:55.620
And we're using Python mostly to automate the build system, testing releases, but also


00:04:55.620 --> 00:04:56.800
for prototyping.


00:04:56.800 --> 00:05:01.760
or algorithms that's really handy


00:05:01.760 --> 00:05:06.280
before you implement it in a high-performance way.


00:05:06.280 --> 00:05:08.720
- Yeah, I think Python is used frequently for that.


00:05:08.720 --> 00:05:10.000
Like, let's prototype this,


00:05:10.000 --> 00:05:12.880
and then if once we completely decide it works right,


00:05:12.880 --> 00:05:15.640
then we're gonna write it in C++ or Rust.


00:05:15.640 --> 00:05:17.800
That's not the most common use of Python,


00:05:17.800 --> 00:05:19.400
but it certainly is one that people have said,


00:05:19.400 --> 00:05:20.220
oh, this is really good


00:05:20.220 --> 00:05:21.960
because you can prototype so quickly.


00:05:21.960 --> 00:05:25.120
Sometimes people just decide,


00:05:25.120 --> 00:05:27.520
and also this will just work fine for what we're doing.


00:05:27.520 --> 00:05:29.000
Actually, it's plenty fast.


00:05:29.000 --> 00:05:31.160
Or they decide, you know, maybe not, right?


00:05:31.160 --> 00:05:33.840
Maybe they need C++, but it's still a cool use case.


00:05:33.840 --> 00:05:34.680
- Yeah.


00:05:34.680 --> 00:05:39.520
- Now, let's kick off our conversation


00:05:39.520 --> 00:05:42.760
with some thoughts from a former guest, Mahmoud Hashemi.


00:05:42.760 --> 00:05:47.760
He had a really interesting way of sort of presenting Python


00:05:47.760 --> 00:05:51.160
to people who are not deep in the Python language


00:05:51.160 --> 00:05:52.440
and said basically it's actually,


00:05:52.440 --> 00:05:56.400
When people say Python is great for prototyping, for example,


00:05:56.400 --> 00:05:59.680
well, they might be talking about one of three things


00:05:59.680 --> 00:06:00.880
or some combination of there.


00:06:00.880 --> 00:06:03.760
It could be when people say, oh, Python is good for this


00:06:03.760 --> 00:06:05.080
or Python is like that.


00:06:05.080 --> 00:06:07.360
They might be talking about the language


00:06:07.360 --> 00:06:10.200
or they might be talking about the standard library


00:06:10.200 --> 00:06:11.920
or more and more these days,


00:06:11.920 --> 00:06:14.040
they're talking about the third-party ecosystem


00:06:14.040 --> 00:06:17.280
with I don't even know how many libraries.


00:06:17.280 --> 00:06:19.560
I gotta look this up 'cause it changes so fast.


00:06:19.560 --> 00:06:24.360
Right now at the time of recording, 368,000 libraries.


00:06:24.360 --> 00:06:26.580
So when people mention Python,


00:06:26.580 --> 00:06:30.880
they often mean one or more of those different things.


00:06:30.880 --> 00:06:33.180
And we're gonna talk about hyper modern Python.


00:06:33.180 --> 00:06:36.000
So I think we should frame it a little bit


00:06:36.000 --> 00:06:37.560
in the sense of like, well,


00:06:37.560 --> 00:06:39.380
what is modern about the language


00:06:39.380 --> 00:06:42.300
or what is kind of modern about the standard library?


00:06:42.300 --> 00:06:47.000
And obviously the ecosystem is where a lot of it's happening.


00:06:47.000 --> 00:06:52.000
So from your point of view, what is modern Python


00:06:52.000 --> 00:06:53.540
before we get the hyper modern?


00:06:53.540 --> 00:07:00.240
- Yeah, definitely we can talk about the language,


00:07:00.240 --> 00:07:03.080
the standard library, the ecosystem.


00:07:03.080 --> 00:07:04.880
I'd also add the community.


00:07:04.880 --> 00:07:08.280
I think that's something that really defines Python.


00:07:08.280 --> 00:07:09.120
- Yeah, I agree.


00:07:09.120 --> 00:07:14.620
- Yeah, and all that tooling that evolved in the ecosystem.


00:07:14.620 --> 00:07:17.700
So about the language, what really--


00:07:17.700 --> 00:07:21.700
because my story is I think I got into Python--


00:07:21.700 --> 00:07:25.140
Python was it, like Python 2.3?


00:07:25.140 --> 00:07:25.700
And I--


00:07:25.700 --> 00:07:27.460
>>Luis: So you've been through the journey.


00:07:27.460 --> 00:07:29.300
You've been through the great split.


00:07:29.300 --> 00:07:29.940
>>Christiane: But I missed--


00:07:29.940 --> 00:07:30.820
>>Luis: The rejoining.


00:07:30.820 --> 00:07:32.940
>>Christiane: I pretty much missed a lot of the pain


00:07:32.940 --> 00:07:35.540
of the Python 2.3 transition.


00:07:35.540 --> 00:07:38.740
I've been busy with C++ and then came back to Python.


00:07:38.740 --> 00:07:41.540
And for me, it was just the enthusiasm


00:07:41.540 --> 00:07:46.980
of rediscovering all the great, like how expressive Python had become.


00:07:46.980 --> 00:07:52.540
One of the things that really get me excited about modern Python is type annotations.


00:07:52.540 --> 00:08:00.460
I just find them so helpful to structure programs, to make APIs clear, to help me think about


00:08:00.460 --> 00:08:03.380
my code and to keep it maintainable and readable.


00:08:03.380 --> 00:08:05.620
So I use them pretty much always.


00:08:05.620 --> 00:08:09.100
And I always run mypy in strict mode.


00:08:09.100 --> 00:08:16.940
I'd even use it in small scripts and it's of course very helpful in large systems.


00:08:16.940 --> 00:08:23.020
Absolutely. Yeah, you know, I don't know that I've, in fact, I'm pretty sure I've never gone


00:08:23.020 --> 00:08:29.660
end-to-end and taken a large system and completely made it 100% mypy checked, you know.


00:08:29.660 --> 00:08:38.780
For me, I'm with you. I absolutely love the types and I've, I use them a lot to sort of drive the


00:08:38.780 --> 00:08:41.540
the tooling intelligence.


00:08:41.540 --> 00:08:43.740
For example, like if you've got a data access layer,


00:08:43.740 --> 00:08:46.300
you could talk about what is exchanged


00:08:46.300 --> 00:08:47.780
at the boundary there,


00:08:47.780 --> 00:08:50.100
so that your editors are all of a sudden


00:08:50.100 --> 00:08:51.980
super smart about auto-complete.


00:08:51.980 --> 00:08:56.980
And I was just doing a massive overhaul to the course,


00:08:56.980 --> 00:08:59.980
Talk Python courses website,


00:08:59.980 --> 00:09:03.860
and I changed like, it was 110 commits in this PR,


00:09:03.860 --> 00:09:05.300
it was like ridiculous.


00:09:05.300 --> 00:09:08.180
But before I checked them all in, I went through


00:09:08.180 --> 00:09:10.340
And I said, okay, look for all the type warnings,


00:09:10.340 --> 00:09:12.020
look for anything that might have become


00:09:12.020 --> 00:09:14.300
like out of sync along the way.


00:09:14.300 --> 00:09:16.100
And I caught like one or two things


00:09:16.100 --> 00:09:19.760
before I accepted the merge the PR back in.


00:09:19.760 --> 00:09:21.740
So like, it's just, yeah,


00:09:21.740 --> 00:09:26.180
I absolutely think that's one of the most important additions


00:09:26.180 --> 00:09:29.100
- And they also, it's so nice how you can leverage them


00:09:29.100 --> 00:09:30.300
at runtime as well.


00:09:30.300 --> 00:09:32.740
It's not only that they allow you to check your code


00:09:32.740 --> 00:09:37.740
in a way that doesn't require hitting every code path,


00:09:37.740 --> 00:09:42.740
but you can build data validation on top of it


00:09:42.740 --> 00:09:44.700
and so many more.


00:09:44.700 --> 00:09:45.540
- Yeah, absolutely.


00:09:45.540 --> 00:09:48.140
I mean, look at libraries like Pydantic and FastAPI


00:09:48.140 --> 00:09:52.420
that are making interesting runtime use out of it.


00:09:52.420 --> 00:09:53.380
- Absolutely.


00:09:53.380 --> 00:09:54.660
- And speaking of modern Python,


00:09:54.660 --> 00:09:58.700
like there was that proposed change


00:09:58.700 --> 00:10:01.500
to make typing more efficient


00:10:01.500 --> 00:10:04.220
where it wouldn't actually import the things


00:10:04.220 --> 00:10:06.260
until it really needed it.


00:10:06.260 --> 00:10:07.580
Or I can't remember the exact pep,


00:10:07.580 --> 00:10:11.020
but it was a way to sort of delay type information imports


00:10:11.020 --> 00:10:12.620
until you're doing something like mypy


00:10:12.620 --> 00:10:16.140
and the pydantic people and Sebastian at FastAPI


00:10:16.140 --> 00:10:19.700
is like, "Wait, wait, wait, wait, wait, wait, wait, wait.


00:10:19.700 --> 00:10:21.940
We need this, like this is how our thing works.


00:10:21.940 --> 00:10:23.900
If you take away the actual meaning


00:10:23.900 --> 00:10:27.500
other than for verification, it's gonna be a problem."


00:10:27.500 --> 00:10:30.540
- The stringification of the type


00:10:30.540 --> 00:10:33.420
that makes it really hard for these use cases.


00:10:33.420 --> 00:10:35.580
And there's this other approach


00:10:35.580 --> 00:10:40.580
where they basically lazily evaluate the types, I think,


00:10:40.580 --> 00:10:44.400
to avoid this string problem.


00:10:44.400 --> 00:10:45.740
- Yeah. - I don't know if they've,


00:10:45.740 --> 00:10:47.380
I think it's still an open question


00:10:47.380 --> 00:10:49.020
of how to proceed this.


00:10:49.020 --> 00:10:54.880
We should have gotten the string types already


00:10:54.880 --> 00:10:59.640
and then decided to take some more time


00:10:59.640 --> 00:11:02.100
to find a good solution for everybody.


00:11:02.100 --> 00:11:04.320
- Yeah, I think that was, it was sort of delayed.


00:11:04.320 --> 00:11:05.600
I can't remember the total outcome,


00:11:05.600 --> 00:11:07.920
but I think it was like, we needed to think about this more


00:11:07.920 --> 00:11:10.960
and make sure all the use cases are covered, right?


00:11:10.960 --> 00:11:13.120
Cool.


00:11:13.120 --> 00:11:15.840
Okay, well, that's the language.


00:11:15.840 --> 00:11:18.680
One thing that we could talk about real quick,


00:11:18.680 --> 00:11:21.240
that's pretty timely, is this pep


00:11:21.240 --> 00:11:24.400
I just had Brett Cannon and Christian on


00:11:24.400 --> 00:11:27.800
to talk about PEP 594,


00:11:27.800 --> 00:11:31.040
removing dead batteries from the standard library,


00:11:31.040 --> 00:11:34.400
which, you know, it's pretty interesting.


00:11:34.400 --> 00:11:38.200
The idea is a lot of these libraries had been added,


00:11:38.200 --> 00:11:41.760
these core modules have been added to the standard library


00:11:41.760 --> 00:11:45.960
in like 1992, and they might not still be relevant.


00:11:45.960 --> 00:11:48.360
For example, CGI is not the most common way


00:11:48.360 --> 00:11:50.000
to do web apps anymore.


00:11:50.000 --> 00:11:52.960
We've got micro-WSGI and G-Unicorn


00:11:52.960 --> 00:11:54.080
and all those things, right?


00:11:54.080 --> 00:11:57.120
So does that still make sense to maintain them?


00:11:57.120 --> 00:12:00.800
- Yeah, I think the set of libraries


00:12:00.800 --> 00:12:05.000
to remove them was pretty non-controversial.


00:12:05.000 --> 00:12:05.920
- Yeah, I agree.


00:12:05.920 --> 00:12:09.160
- They're just very, very obsolete


00:12:09.160 --> 00:12:11.580
and also basically unmaintained.


00:12:11.580 --> 00:12:18.000
And it's, CPython has, I think, like 90 core developers


00:12:18.000 --> 00:12:24.000
and they have like, I don't know, 1,000,


00:12:24.000 --> 00:12:28.120
1,600 open PRs right now.


00:12:28.120 --> 00:12:35.760
So it's very hard to maintain a huge standard library


00:12:35.760 --> 00:12:39.640
with so little human resources.


00:12:39.640 --> 00:12:49.040
So I think that was a good step.


00:12:49.040 --> 00:12:52.480
What I really find interesting is the vision behind it.


00:12:52.480 --> 00:12:57.320
Where should the standard library go?


00:12:57.320 --> 00:13:02.320
what are the criteria in the future to include libraries?


00:13:02.320 --> 00:13:07.080
For example, we think recently we got Tomlib


00:13:07.080 --> 00:13:09.920
into the standard library.


00:13:09.920 --> 00:13:13.780
- Yeah, to join JSON and CSV and XML and all those, yeah.


00:13:13.780 --> 00:13:18.480
- It started as a PyPI library called Tomli,


00:13:18.480 --> 00:13:19.760
and it's been adopted quickly


00:13:19.760 --> 00:13:21.580
by a lot of the tools out there.


00:13:21.580 --> 00:13:25.480
And now it's part of the,


00:13:25.480 --> 00:13:29.080
that will be part of the standard library.


00:13:29.080 --> 00:13:33.000
So this is, for example, this is something that


00:13:33.000 --> 00:13:38.480
is important to solve a bootstrapping problem


00:13:38.480 --> 00:13:40.360
in the packaging ecosystem,


00:13:40.360 --> 00:13:43.720
because we have PyProjectTOML now,


00:13:43.720 --> 00:13:46.060
and how is pip going to pass


00:13:46.060 --> 00:13:53.240
the PyProjectTOML file, for example?


00:13:53.240 --> 00:13:55.200
How are the other tools going to pass it?


00:13:55.200 --> 00:13:58.840
So it's very advantageous to have it in the standard lib.


00:13:58.840 --> 00:14:01.120
But we probably don't want to have passes


00:14:01.120 --> 00:14:06.000
for every file format out there.


00:14:06.000 --> 00:14:07.080
- I agree.


00:14:07.080 --> 00:14:11.640
In fact, a lot of the ones that were removed in PEP 594


00:14:11.640 --> 00:14:14.000
are actually having to do with file formats.


00:14:14.000 --> 00:14:17.600
So you've got like AIFC, which is an audio format.


00:14:17.600 --> 00:14:21.200
You have audio op, you've got, what is it?


00:14:21.200 --> 00:14:23.080
Like the sun AU format.


00:14:23.080 --> 00:14:25.780
there's a bunch of things like that.


00:14:25.780 --> 00:14:28.380
So yeah, I don't wanna dive too much into that


00:14:28.380 --> 00:14:29.980
because we've done a whole show on it,


00:14:29.980 --> 00:14:31.900
but I do think it's interesting to think about this


00:14:31.900 --> 00:14:35.140
as a modern, like the first step in a modernization


00:14:35.140 --> 00:14:37.900
of the standard library, right?


00:14:37.900 --> 00:14:38.740
- Yeah.


00:14:38.740 --> 00:14:42.820
- And then where it really blows open,


00:14:42.820 --> 00:14:45.740
and I think an interesting inter exchange


00:14:45.740 --> 00:14:49.180
sort of cross influence here is the,


00:14:49.180 --> 00:14:53.020
as I already mentioned, the 368,000 external packages


00:14:53.020 --> 00:14:55.300
that are building on a lot of the new language features


00:14:55.300 --> 00:14:57.240
that I think are super cool.


00:14:57.240 --> 00:15:03.020
And how much, looking back, if that world existed already,


00:15:03.020 --> 00:15:07.100
how much smaller would the standard library be, right?


00:15:07.100 --> 00:15:08.860
Like would your lib ever have to be in there?


00:15:08.860 --> 00:15:11.940
Well, we got requests, I don't know, maybe not.


00:15:11.940 --> 00:15:14.420
It could make a lot of sense for it actually to be there,


00:15:14.420 --> 00:15:16.240
like this bootstrapping problem you talked about,


00:15:16.240 --> 00:15:17.180
but maybe it doesn't, right?


00:15:17.180 --> 00:15:19.820
Like I think different choices have been made,


00:15:19.820 --> 00:15:23.560
But yeah, what are your thoughts on the ecosystem


00:15:23.560 --> 00:15:25.700
from the PyPI perspective?


00:15:25.700 --> 00:15:33.740
- Yeah, so if we look at the third party libraries,


00:15:33.740 --> 00:15:40.660
I think for me, modern Python is a lot about expressive


00:15:40.660 --> 00:15:44.740
types like address.


00:15:44.740 --> 00:15:46.420
For me, it's like the best example really


00:15:46.420 --> 00:15:49.180
to how to write well-structured code


00:15:49.180 --> 00:15:54.180
using, Adders just got a new API,


00:15:54.180 --> 00:15:57.620
which is really, really nice.


00:15:57.620 --> 00:16:00.440
And I can definitely recommend having a look at it.


00:16:00.440 --> 00:16:07.340
So it's become very easy to define immutable value objects,


00:16:07.340 --> 00:16:10.500
essentially, that will allow you


00:16:10.500 --> 00:16:15.140
to basically structure your domain logic.


00:16:15.140 --> 00:16:17.300
I really expressed that. - That's interesting, yeah.


00:16:17.300 --> 00:16:18.140
Yeah, they did get a new API.


00:16:18.140 --> 00:16:20.600
- The API-- - It's not frozen.


00:16:20.600 --> 00:16:21.520
Sorry.


00:16:21.520 --> 00:16:22.840
- Yeah, no, I was gonna say that it did get


00:16:22.840 --> 00:16:23.740
a new API recently.


00:16:23.740 --> 00:16:27.100
I forgot that it, it kind of inspired data classes


00:16:27.100 --> 00:16:30.200
and then it sort of turned the tables on it a bit, right?


00:16:30.200 --> 00:16:35.180
And sort of rethought about how some of its stuff


00:16:35.180 --> 00:16:36.360
was offered as well, right?


00:16:36.360 --> 00:16:39.400
- I love that we have data classes in the standard library


00:16:39.400 --> 00:16:41.720
because it's like a mini address


00:16:41.720 --> 00:16:44.500
that you always have at your disposal,


00:16:44.500 --> 00:16:46.360
even when you don't want to take on


00:16:46.360 --> 00:16:51.160
third-party dependencies, but it's definitely always worth


00:16:51.160 --> 00:16:52.660
looking at errors.


00:16:52.660 --> 00:16:55.900
It's very fast and has a lot of features in it.


00:16:55.900 --> 00:16:58.800
Doesn't have this problem that you can only


00:16:58.800 --> 00:17:00.880
really update it once per year.


00:17:00.880 --> 00:17:04.440
- Yeah, and that's a super interesting point.


00:17:04.440 --> 00:17:06.440
They considered putting requests


00:17:06.440 --> 00:17:07.840
in the standard library for a while,


00:17:07.840 --> 00:17:11.920
and requests is under the, what is it under?


00:17:11.920 --> 00:17:13.980
I can't remember the exact organization,


00:17:13.980 --> 00:17:15.520
but it's under an official PSF.


00:17:15.520 --> 00:17:19.640
Maybe I think it is just the PSF organization now


00:17:19.640 --> 00:17:20.880
on GitHub, right?


00:17:20.880 --> 00:17:24.680
It's sort of officially Python in a sense.


00:17:24.680 --> 00:17:27.400
But they decided not to put it into the standard library,


00:17:27.400 --> 00:17:30.280
not because it didn't fit or it wasn't good enough,


00:17:30.280 --> 00:17:31.900
but because it would actually slow down


00:17:31.900 --> 00:17:34.300
the development of requests and constrain it too much.


00:17:34.300 --> 00:17:35.960
And that's sort of similar here as well, right?


00:17:35.960 --> 00:17:39.080
Adders can come out every day with new stuff


00:17:39.080 --> 00:17:42.000
and data classes yearly, right?


00:17:42.000 --> 00:17:43.560
- Absolutely, yeah.


00:17:43.560 --> 00:17:45.320
- I think that's an interesting aspect.


00:17:45.320 --> 00:17:47.760
like sort of modern Python as well, right?


00:17:47.760 --> 00:17:52.760
This ability to just continually deliver new features


00:17:52.760 --> 00:17:54.840
and adapt it as needed.


00:17:54.840 --> 00:17:58.680
- I also really love C Adder


00:17:58.680 --> 00:18:01.040
because you mentioned Pydentic before,


00:18:01.040 --> 00:18:02.680
but what I really like about C Adder,


00:18:02.680 --> 00:18:04.420
it has kind of a similar,


00:18:04.420 --> 00:18:11.120
so you can serialize and deserialize data classes


00:18:14.520 --> 00:18:17.520
and Adders.


00:18:17.520 --> 00:18:20.600
The difference between Pydantic and C Adders


00:18:20.600 --> 00:18:28.360
is that Pydantic uses inheritance to give you


00:18:28.360 --> 00:18:32.280
this functionality, whereas with C Adders,


00:18:32.280 --> 00:18:37.240
you just have your pure Python classes without any--


00:18:37.240 --> 00:18:39.360
they don't need to inherit from anything.


00:18:39.360 --> 00:18:43.880
You just have-- you decouple the serialization logic


00:18:43.880 --> 00:18:45.440
from your domain logic.


00:18:45.440 --> 00:18:49.360
And I think that brings a lot of advantages


00:18:49.360 --> 00:18:52.200
in structuring software.


00:18:52.200 --> 00:18:53.760
- This is the right one I have on the screen here,


00:18:53.760 --> 00:18:55.800
this C-A-T-T-R-S.


00:18:55.800 --> 00:18:56.960
- Right, yeah.


00:18:56.960 --> 00:18:57.960
- Yeah, interesting.


00:18:57.960 --> 00:19:02.380
So you can do things like put a frozen decorator


00:19:02.380 --> 00:19:05.440
onto just a regular Python class and hey, it's frozen.


00:19:05.440 --> 00:19:08.480
You can create an instance of it


00:19:08.480 --> 00:19:10.680
and you can say unstructure and you get a dictionary,


00:19:10.680 --> 00:19:12.440
you can structure it back and tell it what type,


00:19:12.440 --> 00:19:17.440
it parses it back, which is quite neat.


00:19:17.440 --> 00:19:18.320
This one's new to me.


00:19:18.320 --> 00:19:20.800
Like I said, we're going to go through a lot of those,


00:19:20.800 --> 00:19:22.360
a lot of those different things.


00:19:22.360 --> 00:19:24.360
Anything else you want to give a quick shout out


00:19:24.360 --> 00:19:26.560
to in the broader ecosystem before we'll


00:19:26.560 --> 00:19:30.760
dig into your hyper-modern ones that you're using as well?


00:19:30.760 --> 00:19:33.760
If you haven't seen Rich and HTTPx,


00:19:33.760 --> 00:19:37.320
those are definitely some to check out.


00:19:37.320 --> 00:19:39.640
And HTTPx, basically, we talked about requests.


00:19:39.640 --> 00:19:42.840
HTTPS has a very similar interface,


00:19:42.840 --> 00:19:47.840
but gives you both async and sync operations.


00:19:47.840 --> 00:19:54.400
So that's definitely wonderful.


00:19:54.400 --> 00:19:57.020
- I use HTTPS a lot and it's really nice


00:19:57.020 --> 00:19:59.880
because it's so familiar if you know requests,


00:19:59.880 --> 00:20:03.800
but if you happen to find yourself doing cool async stuff,


00:20:03.800 --> 00:20:06.320
you're not stuck not doing async


00:20:06.320 --> 00:20:08.360
for one of the most important parts,


00:20:08.360 --> 00:20:10.600
which is calling services, right?


00:20:10.600 --> 00:20:13.480
So you can await doing a get or a post or whatever.


00:20:13.480 --> 00:20:15.680
Yeah, it's really nice.


00:20:15.680 --> 00:20:17.680
Not 100% switch to it instead of request,


00:20:17.680 --> 00:20:20.180
but it's definitely one of my go-tos as well.


00:20:20.180 --> 00:20:23.880
Cool.


00:20:23.880 --> 00:20:27.220
All right, well, so that's sort of some thoughts


00:20:27.220 --> 00:20:29.860
on modern Python and where things are going.


00:20:29.860 --> 00:20:32.480
Then you created this series,


00:20:32.480 --> 00:20:36.840
which is almost like a little mini course


00:20:36.840 --> 00:20:39.400
on how should you, from your perspective,


00:20:39.400 --> 00:20:43.000
how should you structure and build modern Python projects


00:20:43.000 --> 00:20:44.340
and what tools should you bring in?


00:20:44.340 --> 00:20:48.120
Not just should you use HTTPX over requests,


00:20:48.120 --> 00:20:51.800
but should you use Knox for testing and things like that?


00:20:51.800 --> 00:20:54.380
I'm guessing you might say yes for Knox,


00:20:54.380 --> 00:20:57.400
given that you work on it, right?


00:20:57.400 --> 00:21:03.580
So you did this article, this six-part series article on it,


00:21:03.580 --> 00:21:04.800
which I'll definitely link to,


00:21:04.800 --> 00:21:09.120
But then also you created a cookie cutter template


00:21:09.120 --> 00:21:10.880
that'll allow people to jump into it.


00:21:10.880 --> 00:21:12.800
And I find this to be really helpful.


00:21:12.800 --> 00:21:15.040
I do this sometimes with my classes.


00:21:15.040 --> 00:21:16.640
Be like, well, here's the thing we built at the end,


00:21:16.640 --> 00:21:19.520
but if you just wanna create your own version of it,


00:21:19.520 --> 00:21:23.640
here's a cookie cutter to actually just create it


00:21:23.640 --> 00:21:25.840
with your settings and your values


00:21:25.840 --> 00:21:28.240
that you don't have to go through rebuilding it from scratch.


00:21:28.240 --> 00:21:31.440
And cookie cutter has been really influential


00:21:31.440 --> 00:21:33.320
in that sense, don't you think?


00:21:33.320 --> 00:21:34.600
Absolutely.


00:21:34.600 --> 00:21:39.400
When I wrote the articles, there was example code on GitHub.


00:21:39.400 --> 00:21:42.800
And I saw people forking the repository.


00:21:42.800 --> 00:21:44.400
And I was like, oh, no.


00:21:44.400 --> 00:21:47.040
They're all going to end up with this example


00:21:47.040 --> 00:21:51.120
code that displays Wikipedia articles in your console.


00:21:51.120 --> 00:21:55.160
And am I going to keep all the dependencies up to date?


00:21:55.160 --> 00:21:57.080
And how do I even do that?


00:21:57.080 --> 00:22:00.440
And I was like, no, I have to find a better way.


00:22:00.440 --> 00:22:03.200
And cookie cutter was definitely a good way


00:22:03.200 --> 00:22:05.960
to set up a project template.


00:22:05.960 --> 00:22:08.040
And also something that was much easier for me


00:22:08.040 --> 00:22:11.080
to keep up to date.


00:22:11.080 --> 00:22:17.720
So there's, after two years, definitely quite a bit of drift


00:22:17.720 --> 00:22:23.700
between the article series, which is from January 2020,


00:22:23.700 --> 00:22:27.800
and the cookie cutter as it is today.


00:22:27.800 --> 00:22:28.800
Yeah.


00:22:28.800 --> 00:22:29.560
Yeah.


00:22:29.560 --> 00:22:32.520
- Yeah, it's hard to keep an article or a video


00:22:32.520 --> 00:22:36.280
or a talk or whatever as a living thing that evolves


00:22:36.280 --> 00:22:38.180
as we gain more experience and stuff.


00:22:38.180 --> 00:22:40.040
But a cookie cutter template, right?


00:22:40.040 --> 00:22:42.520
That's like software, it's plastic.


00:22:42.520 --> 00:22:45.040
- You can make it open source and have contributors


00:22:45.040 --> 00:22:47.680
that do some work for you,


00:22:47.680 --> 00:22:50.520
which is really, extremely grateful


00:22:50.520 --> 00:22:52.920
for all the contributions I got there.


00:22:52.920 --> 00:22:54.440
- Yeah, that's great.


00:22:54.440 --> 00:22:55.800
I see a bunch of contributors there.


00:22:55.800 --> 00:22:59.520
Now, first let's start with just the term,


00:22:59.520 --> 00:23:02.560
Hypermodern Python. What's the story with the naming here?


00:23:02.560 --> 00:23:07.320
I actually brought you now this only for those that have a


00:23:07.320 --> 00:23:09.800
camera in front of them that this is this hyper modern


00:23:09.800 --> 00:23:14.800
Python. So this is not Python. This is hyper modern, hyper


00:23:14.800 --> 00:23:22.160
modern chess game, written in 1935. So this is where the name


00:23:22.160 --> 00:23:27.960
hyper modern really comes from. You know, it's a bit it was


00:23:27.960 --> 00:23:33.120
meant a little bit tongue in cheek. And also, I was very


00:23:33.120 --> 00:23:36.960
conscious that, you know, how how is going, how's Python going


00:23:36.960 --> 00:23:40.720
to look like two years after I've written this, this article


00:23:40.720 --> 00:23:48.480
series, yeah, the ecosystem evolves so quickly. And I


00:23:48.480 --> 00:23:51.920
decided to stick all these images in the in the blog that


00:23:51.920 --> 00:23:54.800
are basically past versions of the future. It's a thing it's


00:23:54.800 --> 00:23:56.600
called retrofuturism.


00:23:56.600 --> 00:24:00.760
So they're basically all images from the 1920s and so on


00:24:00.760 --> 00:24:03.680
about how people are, in the future,


00:24:03.680 --> 00:24:07.600
maybe going to fly to the opera using planes


00:24:07.600 --> 00:24:09.560
that look like little birds.


00:24:09.560 --> 00:24:14.120
Yeah, it's sort of a steampunk mechanical bird people


00:24:14.120 --> 00:24:16.720
are cruising along in.


00:24:16.720 --> 00:24:18.120
Yeah, it's a cool picture.


00:24:18.120 --> 00:24:20.880
It's a cool idea.


00:24:20.880 --> 00:24:22.640
So yeah, so what is hypermodern?


00:24:22.640 --> 00:24:26.600
I think basically it's just whatever I was excited about


00:24:26.600 --> 00:24:29.200
and didn't know about beforehand.


00:24:29.200 --> 00:24:34.400
I had used some tools, more the standard tools,


00:24:34.400 --> 00:24:38.560
like setup tools and pip-tools and talks.


00:24:38.560 --> 00:24:42.840
And coming back to Python, I thought, wow,


00:24:42.840 --> 00:24:45.480
let's just check out all the things that have happened.


00:24:45.480 --> 00:24:50.240
And let's see how maybe that might solve a few


00:24:50.240 --> 00:24:51.520
the problems that I had.


00:24:51.520 --> 00:24:54.480
So.


00:24:54.480 --> 00:24:56.720
- Nice, okay.


00:24:56.720 --> 00:24:59.440
So then you put together the article,


00:24:59.440 --> 00:25:03.960
which is, you know, it's a serious article.


00:25:03.960 --> 00:25:05.840
It's not just a couple of paragraphs, right?


00:25:05.840 --> 00:25:08.280
It's quite a bit of writing.


00:25:08.280 --> 00:25:11.720
Yeah, six articles and my little,


00:25:11.720 --> 00:25:13.800
maybe it was your website's like 11 minutes reading


00:25:13.800 --> 00:25:15.880
for this part, you know, that kind of thing.


00:25:15.880 --> 00:25:18.640
So it goes into pretty good detail with examples.


00:25:18.640 --> 00:25:20.640
And then you captured it in this cookie cutter


00:25:20.640 --> 00:25:23.040
because like you said, to put it into practice,


00:25:23.040 --> 00:25:24.920
that's a pretty good way.


00:25:24.920 --> 00:25:27.800
Now using cookie cutter is super easy.


00:25:27.800 --> 00:25:30.040
I'm sure people are familiar with this,


00:25:30.040 --> 00:25:31.800
but it's cookie cutter, give it the name,


00:25:31.800 --> 00:25:34.640
it asks a bunch of questions, right?


00:25:34.640 --> 00:25:37.120
But I think maybe the right way to explore this


00:25:37.120 --> 00:25:41.680
would be to talk about the features and the steps


00:25:41.680 --> 00:25:43.800
of the cookie cutter that it does, right?


00:25:43.800 --> 00:25:47.360
There's on the page for the cookie cutter GitHub repo,


00:25:47.360 --> 00:25:50.280
where there's a big section that says Features.


00:25:50.280 --> 00:25:52.920
And that sort of talks about the different aspects


00:25:52.920 --> 00:25:55.720
and angles and dimensions you decided to bring in


00:25:55.720 --> 00:25:57.200
and the tooling there.


00:25:57.200 --> 00:25:59.080
So how about we just go through these


00:25:59.080 --> 00:26:00.720
and sort of dive into them.


00:26:00.720 --> 00:26:02.480
I think people are gonna discover.


00:26:02.480 --> 00:26:04.800
Yeah, I think people are gonna discover


00:26:04.800 --> 00:26:05.760
some cool tools here.


00:26:05.760 --> 00:26:10.760
So first of all, you're gonna build something meaningful.


00:26:10.760 --> 00:26:15.080
You've got to get some libraries off PyPI.


00:26:15.080 --> 00:26:17.240
Like there's very few projects that have no dependencies


00:26:17.240 --> 00:26:21.480
that are rich these days, and not just rich the package,


00:26:21.480 --> 00:26:24.080
but feature rich.


00:26:24.080 --> 00:26:27.360
So let's talk about the first one here.


00:26:27.360 --> 00:26:30.000
Take us through it.


00:26:30.000 --> 00:26:34.360
So Poetry really solved the problem for me


00:26:34.360 --> 00:26:39.760
because it's basically the one tool approach.


00:26:39.760 --> 00:26:45.160
You have one tool that does everything for you.


00:26:45.160 --> 00:26:49.760
It will allow you to define metadata for your package,


00:26:49.760 --> 00:26:53.680
build the package for you so you can publish it on PyPI.


00:26:53.680 --> 00:26:56.880
It can manage environments for you,


00:26:56.880 --> 00:26:59.640
install all the dependencies of your project


00:26:59.640 --> 00:27:00.920
and your project itself.


00:27:00.920 --> 00:27:04.800
And it can also manage the dependencies itself.


00:27:04.800 --> 00:27:08.400
So it has a resolution mechanism.


00:27:08.400 --> 00:27:11.960
And it has a log file,


00:27:11.960 --> 00:27:16.040
which is for me a really important feature


00:27:16.040 --> 00:27:19.640
because not only is it good for deploying services


00:27:19.640 --> 00:27:23.160
in a reproducible and deterministic way,


00:27:23.160 --> 00:27:27.040
but it's also for running the checks on your code


00:27:27.040 --> 00:27:32.040
and making sure that the checks run exactly the same


00:27:32.040 --> 00:27:34.400
locally on your machine in CI


00:27:34.400 --> 00:27:39.120
with on and on the machines of your collaborators.


00:27:40.000 --> 00:27:44.680
- Yeah, I'm not as familiar with the Poetry lock file


00:27:44.680 --> 00:27:47.800
as I should be, but basically it's like


00:27:47.800 --> 00:27:52.280
pinning your versions in a requirements.txt, right?


00:27:52.280 --> 00:27:54.480
But so often people just write,


00:27:54.480 --> 00:27:55.680
you know, here's my requirements.


00:27:55.680 --> 00:27:59.160
I have requests or HTTPS and I have FastAPI


00:27:59.160 --> 00:28:01.400
and I have SQLAlchemy or SQL model.


00:28:01.400 --> 00:28:02.560
And you just type those out,


00:28:02.560 --> 00:28:05.280
then you pip install -r, you're good to go.


00:28:05.280 --> 00:28:09.480
Until you wanna go back to an old version


00:28:09.480 --> 00:28:12.020
that might have a bug, that that's the one in production.


00:28:12.020 --> 00:28:16.920
But the bug might be because it has the old library of whatever,


00:28:16.920 --> 00:28:17.420
right?


00:28:17.420 --> 00:28:18.500
And you don't know, right?


00:28:18.500 --> 00:28:20.740
So you want to be able to pin those versions.


00:28:20.740 --> 00:28:24.180
And then does the lock file also put the hashes in so they


00:28:24.180 --> 00:28:25.660
can't be fiddled with?


00:28:25.660 --> 00:28:26.860
>>Helge: It does, yeah.


00:28:26.860 --> 00:28:28.080
So it has the hashes.


00:28:28.080 --> 00:28:30.620
And it gives you all the-- basically,


00:28:30.620 --> 00:28:33.620
the other indirect dependencies as well.


00:28:33.620 --> 00:28:39.420
So much like pip compile would do for pip-tools.


00:28:39.420 --> 00:28:42.120
And that is tremendously useful.


00:28:42.120 --> 00:28:43.560
- Yeah, it absolutely is.


00:28:43.560 --> 00:28:46.460
I'm a big fan of the pip-tools and pip compile.


00:28:46.460 --> 00:28:49.560
We'll get to that later when you talk.


00:28:49.560 --> 00:28:50.760
Yeah, yeah, when we get to it,


00:28:50.760 --> 00:28:52.440
there's a section, a whole section


00:28:52.440 --> 00:28:54.000
in the cookie cutter about it.


00:28:54.000 --> 00:28:57.320
All right, so it starts by setting up with Poetry, right?


00:28:57.320 --> 00:28:58.720
- Absolutely, yeah.


00:28:58.720 --> 00:29:03.720
So I just say, so I called Poetry the one tool approach.


00:29:03.720 --> 00:29:06.800
And there has been a lot of work


00:29:06.800 --> 00:29:13.480
in the packaging community to introduce packaging standards


00:29:13.480 --> 00:29:20.120
that make it easier for the tools to interoperate.


00:29:20.120 --> 00:29:25.360
And I think this is actually a very good way


00:29:25.360 --> 00:29:27.920
to approach things in an ecosystem like Python's


00:29:27.920 --> 00:29:33.900
to make it possible that you can define your package


00:29:33.900 --> 00:29:37.380
metadata for one tool, like Flit,


00:29:37.380 --> 00:29:41.380
and then use poetry to build the package, or PDM,


00:29:41.380 --> 00:29:42.780
and so many others.


00:29:42.780 --> 00:29:46.960
And there has been a lot of great work


00:29:46.960 --> 00:29:52.180
that has made the packaging ecosystem more diverse.


00:29:52.180 --> 00:29:52.680
So--


00:29:52.680 --> 00:29:53.180
Yeah.


00:29:53.180 --> 00:29:55.660
Yeah, there was some separation of the architectures


00:29:55.660 --> 00:29:59.060
of certain responsibilities, right?


00:29:59.060 --> 00:29:59.740
Yes.


00:29:59.740 --> 00:30:03.540
So there's PEP 621, which defined the metadata.


00:30:03.540 --> 00:30:07.460
There was also an attempt to standardize log files, which


00:30:07.460 --> 00:30:09.540
I think would be great.


00:30:09.540 --> 00:30:13.340
But that PEP, unfortunately, has been rejected for now.


00:30:13.340 --> 00:30:17.260
So I'm hoping that there will be more attempts in the future.


00:30:17.260 --> 00:30:20.940
But so as great as it is to work with Poetry,


00:30:20.940 --> 00:30:23.100
I definitely hope for the ecosystem


00:30:23.100 --> 00:30:27.420
to become even more diverse and more standardized


00:30:27.420 --> 00:30:30.140
to really give us more flexibility


00:30:30.140 --> 00:30:32.900
and interoperability.


00:30:32.900 --> 00:30:34.500
- Yeah, yeah, that is great.


00:30:34.500 --> 00:30:36.620
Definitely seems like a lot of options


00:30:36.620 --> 00:30:38.700
are coming out around that these days.


00:30:38.700 --> 00:30:43.700
And then the next one here is test automation with Knox.


00:30:43.700 --> 00:30:46.460
So what's your relationship with Knox by the way?


00:30:46.460 --> 00:30:50.060
Are you the maintainer or are you just a contributor or?


00:30:50.060 --> 00:30:51.500
- I'm co-maintaining Knox.


00:30:51.500 --> 00:30:55.260
It was written by Thea Flowers


00:30:55.260 --> 00:31:00.060
and it has a large maintainer team.


00:31:02.260 --> 00:31:04.660
At the time that I wrote the article series,


00:31:04.660 --> 00:31:07.260
I was just a fan of Knox.


00:31:07.260 --> 00:31:09.020
And I started contributing to it.


00:31:09.020 --> 00:31:13.180
And I kind of ended up co-maintaining it.


00:31:13.180 --> 00:31:15.220
>> Whoops, I'm contributing more than anyone else.


00:31:15.220 --> 00:31:17.860
Does that make me more involved?


00:31:17.860 --> 00:31:21.180
All right, yeah, so tell us what the role of Knox plays.


00:31:21.180 --> 00:31:22.460
>> So Knox is a great tool.


00:31:22.460 --> 00:31:24.020
It's not just test automation.


00:31:24.020 --> 00:31:27.780
It's really-- it lets you automate basically


00:31:27.780 --> 00:31:29.940
all the developer tasks you have.


00:31:29.940 --> 00:31:32.040
So this might be tests.


00:31:32.040 --> 00:31:37.680
It might be the other checks you have, like linting.


00:31:37.680 --> 00:31:40.640
Or it could be building your documentation,


00:31:40.640 --> 00:31:47.560
or building wheels, if that's complicated in any way.


00:31:47.560 --> 00:31:52.820
You can just-- so the great thing about Nox


00:31:52.820 --> 00:32:02.940
is that it uses Python to let you define the tasks,


00:32:02.940 --> 00:32:06.180
rather than basically having something like a make file


00:32:06.180 --> 00:32:07.340
where you use the shell.


00:32:07.340 --> 00:32:13.260
Or in Tox, you have an ini file where you enter your commands.


00:32:13.260 --> 00:32:15.540
At least Tox 3, I think Tox 4 is also going


00:32:15.540 --> 00:32:17.380
to add Python configuration.


00:32:20.540 --> 00:32:25.660
So Knox, it's really inspired by Tox, I think.


00:32:25.660 --> 00:32:28.220
So if you know Tox, Tox allows you


00:32:28.220 --> 00:32:34.740
to run tests on multiple versions of Python.


00:32:34.740 --> 00:32:36.980
And it's been around for much longer.


00:32:36.980 --> 00:32:38.220
It's a very mature tool.


00:32:38.220 --> 00:32:42.620
Knox is inspired by that.


00:32:42.620 --> 00:32:47.900
It also lets you have this matrix of Python versions


00:32:47.900 --> 00:32:49.860
or even other things.


00:32:49.860 --> 00:32:52.820
So you can, similar to pytest,


00:32:52.820 --> 00:32:57.060
you can parameterize your session functions


00:32:57.060 --> 00:33:02.340
and pass in, say, like a specific dependency


00:33:02.340 --> 00:33:05.480
that you want to test against in different versions.


00:33:05.480 --> 00:33:11.180
So Nox is really useful if you want to have


00:33:11.180 --> 00:33:16.500
a single entry point into your project maintenance,


00:33:16.500 --> 00:33:18.500
running all the tasks that you have


00:33:18.500 --> 00:33:21.460
and running them the same locally and on CI.


00:33:21.460 --> 00:33:23.420
- Yeah, this looks great.


00:33:23.420 --> 00:33:27.260
I hadn't really explored this, this Knox file thing


00:33:27.260 --> 00:33:29.760
where you have these different tasks,


00:33:29.760 --> 00:33:32.580
like a task, you know, a task basically being a function,


00:33:32.580 --> 00:33:34.980
like so you say like tests or lint,


00:33:34.980 --> 00:33:36.860
and you can just put a session decorator on it


00:33:36.860 --> 00:33:39.020
and just say session.install pytest,


00:33:39.020 --> 00:33:42.100
session.run pytest or session install flake eight


00:33:42.100 --> 00:33:43.380
and run it with the parameters.


00:33:43.380 --> 00:33:45.500
It's really nice and clean


00:33:45.500 --> 00:33:48.700
and it's way better than a shell script.


00:33:48.700 --> 00:33:51.040
I think it keeps you in Python, right?


00:33:51.040 --> 00:33:51.880
- Right.


00:33:51.880 --> 00:33:54.360
- Which is probably where you wanna be on Python projects.


00:33:54.360 --> 00:33:57.180
- And it runs on all the platforms.


00:33:57.180 --> 00:34:00.860
At some point I used make files to automate these things.


00:34:00.860 --> 00:34:04.260
So the non-talks related things, I guess.


00:34:04.260 --> 00:34:08.660
And those don't work very well on Windows.


00:34:08.660 --> 00:34:09.500
- Yes.


00:34:09.500 --> 00:34:10.620
- You don't have this problem.


00:34:10.620 --> 00:34:11.900
- Yeah, that's for sure.


00:34:11.900 --> 00:34:12.940
Cool.


00:34:12.940 --> 00:34:14.740
And then we kind of saw an example of that there,


00:34:14.740 --> 00:34:18.160
but Linting with Precommit and Flake 8.


00:34:18.160 --> 00:34:20.260
- Right. - Tell us about


00:34:20.260 --> 00:34:21.100
these two libraries.


00:34:21.100 --> 00:34:23.740
- I love Precommit.


00:34:23.740 --> 00:34:26.700
Actually, it wasn't in the first draft


00:34:26.700 --> 00:34:28.900
of the article series.


00:34:28.900 --> 00:34:33.260
I got some reviewers who commented on that.


00:34:33.260 --> 00:34:38.260
I think Bonnie Funchmid from the pytest project


00:34:38.260 --> 00:34:41.460
and Henning Schlavack both mentioned


00:34:41.460 --> 00:34:43.500
that you have to cover Precommit.


00:34:43.500 --> 00:34:45.380
And I was really skeptical.


00:34:45.380 --> 00:34:51.300
I had made bad experiences with these kinds of pre-commit hooks


00:34:51.300 --> 00:34:51.980
that run.


00:34:51.980 --> 00:34:55.860
So you make a git commit, and then it


00:34:55.860 --> 00:35:01.620
doesn't work because you had some wrong whitespace in it.


00:35:01.620 --> 00:35:04.260
And I thought, I want my commits to be really snappy.


00:35:04.260 --> 00:35:07.080
I'll just use Nox for that.


00:35:07.080 --> 00:35:09.460
But after hearing these comments,


00:35:09.460 --> 00:35:11.700
I thought, I'm going to give it a try.


00:35:11.700 --> 00:35:12.460
It's a new tool.


00:35:12.460 --> 00:35:14.900
maybe it solves these problems much better.


00:35:14.900 --> 00:35:15.740
And it really does.


00:35:15.740 --> 00:35:20.260
I would really recommend anybody to give pre-committed try.


00:35:20.260 --> 00:35:23.740
Basically, you drop a YAML config


00:35:23.740 --> 00:35:30.380
in your project that defines the hooks that you want to run.


00:35:30.380 --> 00:35:35.780
So this might be a hook that formats your code using black


00:35:35.780 --> 00:35:42.140
or that lints your code using flake 8 or so much more.


00:35:42.140 --> 00:35:45.580
There's an abundance of pre-commit hooks out there.


00:35:45.580 --> 00:35:50.080
- Oh, wow, yeah, there's probably 20 pages


00:35:50.080 --> 00:35:53.380
in the list of pre-commit hooks that are at the top.


00:35:53.380 --> 00:35:57.500
You can click on supported hooks in pre-commit.com.


00:35:57.500 --> 00:36:01.280
- Right, and pre-commit,


00:36:01.280 --> 00:36:04.420
so it's a GitHub manager,


00:36:04.420 --> 00:36:06.420
but it's not just a GitHub manager.


00:36:06.420 --> 00:36:09.420
It's also a linter framework


00:36:09.420 --> 00:36:11.800
and a multi-language linter framework.


00:36:11.800 --> 00:36:16.800
So you can have your hooks written in Ruby, C++,


00:36:16.800 --> 00:36:22.020
you name it, and it's very easy to use them


00:36:22.020 --> 00:36:28.240
in a Python project or basically any language project.


00:36:28.240 --> 00:36:35.360
It works using Git, so basically installs the tools


00:36:37.000 --> 00:36:40.080
from their Git repository.


00:36:40.080 --> 00:36:45.080
And then you can run them as part of your Git commits


00:36:45.080 --> 00:36:51.520
or all the other hook points that Git offers.


00:36:51.520 --> 00:36:57.880
But you can also run it just in CI on your entire code base.


00:36:57.880 --> 00:37:01.520
And that's really what I love about it


00:37:01.520 --> 00:37:05.040
is that it has this fail early philosophy.


00:37:05.040 --> 00:37:08.320
So you really get very early feedback.


00:37:08.320 --> 00:37:11.440
But it also works as a gatekeeper


00:37:11.440 --> 00:37:13.720
for your default branch and make sure


00:37:13.720 --> 00:37:19.560
that all the commits that go into your main branch


00:37:19.560 --> 00:37:22.200
are well-formed.


00:37:22.200 --> 00:37:23.880
>>This is interesting.


00:37:23.880 --> 00:37:32.160
I did have a creator of pre-commit on the show


00:37:32.160 --> 00:37:32.920
quite a while ago.


00:37:32.920 --> 00:37:34.200
I talked about it.


00:37:34.200 --> 00:37:36.080
But I think maybe some of these are new,


00:37:36.080 --> 00:37:38.280
I hadn't really appreciated them before.


00:37:38.280 --> 00:37:41.420
Like one that's really cool here is check JSON


00:37:41.420 --> 00:37:43.640
as a pre-commit and it checks JSON files


00:37:43.640 --> 00:37:44.680
for parsable syntax.


00:37:44.680 --> 00:37:48.000
So basically as part of your commits,


00:37:48.000 --> 00:37:51.120
it says, well, I'm guessing here's a changed JSON file,


00:37:51.120 --> 00:37:54.920
is this, can it just basically be loaded with,


00:37:54.920 --> 00:37:58.440
JSON.loadf or load, give it a file, right?


00:37:58.440 --> 00:38:02.480
And another one is, yes, you're supposed to have unit tests,


00:38:02.480 --> 00:38:04.400
but you might not have unit tests for everything.


00:38:04.400 --> 00:38:07.600
So check AST just means like, can Python parse the files?


00:38:07.600 --> 00:38:10.880
That's sort of like the compile step, right?


00:38:10.880 --> 00:38:12.240
In a sense.


00:38:12.240 --> 00:38:14.000
So yeah, I mean, those are just like the first couple


00:38:14.000 --> 00:38:15.500
out of this 20 pages.


00:38:15.500 --> 00:38:18.840
So I need to come back to this and check TOML


00:38:18.840 --> 00:38:20.720
with another sort of similar to the check JSON,


00:38:20.720 --> 00:38:23.280
check YAML, check XML and so on.


00:38:23.280 --> 00:38:26.760
- Yes, there's a, this repository called pre-commit hooks


00:38:26.760 --> 00:38:29.680
and that has lots of very small hooks


00:38:29.680 --> 00:38:32.440
that are tremendously useful.


00:38:32.440 --> 00:38:36.520
And then you have larger tools that also offer integration


00:38:36.520 --> 00:38:38.680
with pre-commit, like Flake 8, for example.


00:38:38.680 --> 00:38:39.840
- Right, right, nice.


00:38:39.840 --> 00:38:43.960
All right, and then on to continuous integration.


00:38:43.960 --> 00:38:47.960
I feel like GitHub Actions is really sort of taking hold


00:38:47.960 --> 00:38:50.360
in the Python space is a way a lot of people


00:38:50.360 --> 00:38:51.680
are doing stuff there.


00:38:51.680 --> 00:38:53.680
- Absolutely, it feels like there was some kind


00:38:53.680 --> 00:38:57.740
of mass exodus from Travis CI to GitHub Actions.


00:38:58.980 --> 00:39:06.100
It's so flexible, and it goes way beyond just running tests


00:39:06.100 --> 00:39:11.140
and what you'd normally think of as CI.


00:39:11.140 --> 00:39:16.340
So you can automate a lot of your developer workflows


00:39:16.340 --> 00:39:20.380
centered around the collaboration with others.


00:39:20.380 --> 00:39:21.100
>>Nice.


00:39:21.100 --> 00:39:24.260
The type of stuff I work on doesn't superlend itself well


00:39:24.260 --> 00:39:26.580
to GitHub Actions.


00:39:26.580 --> 00:39:28.260
It does-- it probably does somewhat.


00:39:28.260 --> 00:39:31.260
But it's not something I use that much.


00:39:31.260 --> 00:39:34.140
But it seems like if you had a package that


00:39:34.140 --> 00:39:37.340
had maybe complicated builds or something like that,


00:39:37.340 --> 00:39:39.580
you could even use it to build your wheels and stuff


00:39:39.580 --> 00:39:41.460
like that, right?


00:39:41.460 --> 00:39:42.180
- Sure, yeah.


00:39:42.180 --> 00:39:46.420
I mean, the way I like to use it is


00:39:46.420 --> 00:39:49.860
to have most of the logic in Knox,


00:39:49.860 --> 00:39:52.820
because that means I can always just test it locally


00:39:52.820 --> 00:39:54.700
and see if everything--


00:39:54.700 --> 00:39:56.300
debug it easily.


00:39:56.300 --> 00:40:02.340
And then I try to keep the GitHub Actions workflows pretty


00:40:02.340 --> 00:40:06.300
lightweight and just let them invoke Nox.


00:40:06.300 --> 00:40:13.900
I usually have a matrix that contains the Nox sessions.


00:40:13.900 --> 00:40:19.540
So this might be the testing or running pre-commit


00:40:19.540 --> 00:40:23.820
or to lend the code or to build the documentation,


00:40:23.820 --> 00:40:28.460
and see if that's all valid.


00:40:28.460 --> 00:40:32.740
And then the matrix has the Python versions


00:40:32.740 --> 00:40:34.420
that I want to test on.


00:40:34.420 --> 00:40:36.380
If I'm working on a library, it's


00:40:36.380 --> 00:40:40.140
important to support not just the latest Python version,


00:40:40.140 --> 00:40:45.060
probably Python 3.6 onwards, maybe even the upcoming Python


00:40:45.060 --> 00:40:46.460
version.


00:40:46.460 --> 00:40:47.820
And then obviously, platforms.


00:40:47.820 --> 00:40:52.820
So always, unless you're only working on one platform,


00:40:52.820 --> 00:40:58.180
try to have at least Linux and Windows,


00:40:58.180 --> 00:41:01.300
and then maybe macOS as well.


00:41:01.300 --> 00:41:03.060
- Yeah, this is neat.


00:41:03.060 --> 00:41:04.020
You know, people talk about,


00:41:04.020 --> 00:41:06.060
well, we can't really test this on Windows


00:41:06.060 --> 00:41:07.780
'cause I don't have a Windows machine, or vice versa.


00:41:07.780 --> 00:41:09.300
Can't test it on Mac or...


00:41:09.300 --> 00:41:10.220
- So easy.


00:41:10.220 --> 00:41:13.900
- Yeah, so here's your three platforms right here, right?


00:41:13.900 --> 00:41:15.940
- I'm not saying it's easy to debug it


00:41:15.940 --> 00:41:18.380
if something goes wrong and you're only working


00:41:18.380 --> 00:41:20.980
on macOS or Linux, you probably at some point


00:41:20.980 --> 00:41:24.860
want to have a virtual machine running Windows


00:41:24.860 --> 00:41:27.780
if you don't have a physical Windows machine.


00:41:27.780 --> 00:41:30.860
But it's also not hard to get one these days too.


00:41:30.860 --> 00:41:35.700
But otherwise, it's very easy to integrate Windows in your CI.


00:41:35.700 --> 00:41:36.780
- Nice.


00:41:36.780 --> 00:41:37.620
Yeah, very cool.


00:41:37.620 --> 00:41:41.460
And then the next one has to do with documentation here.


00:41:43.620 --> 00:41:46.420
- Sphinx, Myst, and Read the Docs,


00:41:46.420 --> 00:41:49.740
and one of the themes, so yeah, pretty.


00:41:49.740 --> 00:41:54.140
- When I wrote the articles,


00:41:54.140 --> 00:41:58.420
it was just Sphinx and Read the Docs.


00:41:58.420 --> 00:42:00.120
Myst hadn't happened yet, so,


00:42:00.120 --> 00:42:06.020
well, Myst, maybe let's start with Sphinx,


00:42:06.020 --> 00:42:09.360
'cause I guess many people will already be familiar with it.


00:42:09.360 --> 00:42:11.180
It's a Python documentation generator.


00:42:11.180 --> 00:42:14.700
It's also used for Python's own documentation.


00:42:14.700 --> 00:42:18.340
So for example, the library docs.


00:42:18.340 --> 00:42:20.460
It's been around for a long time.


00:42:20.460 --> 00:42:24.460
And it normally uses restructured text,


00:42:24.460 --> 00:42:27.140
which is a very expressive language


00:42:27.140 --> 00:42:30.180
to write technical documentation.


00:42:30.180 --> 00:42:32.420
Sometimes too expressive.


00:42:32.420 --> 00:42:34.260
Sometimes too expressive.


00:42:34.260 --> 00:42:36.460
It's not the lightweight language


00:42:36.460 --> 00:42:40.740
that we know Markdown to be.


00:42:40.740 --> 00:42:43.940
And Markdown has really conquered the world.


00:42:43.940 --> 00:42:49.380
And when I wrote the documentation chapter,


00:42:49.380 --> 00:42:53.740
I think I linked to an article by Eric Holcher


00:42:53.740 --> 00:42:56.260
from Read the Docs comparing the two formats.


00:42:56.260 --> 00:42:59.700
And that was before Mist happened.


00:42:59.700 --> 00:43:06.060
And he said, use restructured text.


00:43:06.060 --> 00:43:07.900
It's just so much more expressive.


00:43:07.900 --> 00:43:10.220
And it lets you have cross-references and all


00:43:10.220 --> 00:43:15.020
these things as the powerful directives.


00:43:15.020 --> 00:43:17.100
Anyway, now we have Mist, and Mist


00:43:17.100 --> 00:43:20.500
allows you to do essentially the same thing in Markdown.


00:43:20.500 --> 00:43:25.300
There's an extension syntax, and you can have directives.


00:43:25.300 --> 00:43:29.300
You can have cross-references, and it's a lot of fun


00:43:29.300 --> 00:43:32.420
to write documentation in Mist.


00:43:32.420 --> 00:43:37.580
So this was a recent addition to the project template


00:43:37.580 --> 00:43:41.060
to support Markdown documentation.


00:43:41.060 --> 00:43:42.820
- And for those who don't know,


00:43:42.820 --> 00:43:45.740
I also did have a show recently with the Mist folks


00:43:45.740 --> 00:43:48.100
about Sphinx and Mist and so on.


00:43:48.100 --> 00:43:50.420
And there I learned that one of the things that's cool


00:43:50.420 --> 00:43:52.740
is you can inline restructured text.


00:43:52.740 --> 00:43:54.180
So if you get to a section and you're like,


00:43:54.180 --> 00:43:56.820
ah, this is just Markdown, I don't wanna do this.


00:43:56.820 --> 00:43:59.380
No, do a little tiny bit of restructured text


00:43:59.380 --> 00:44:02.500
instead of living in it, you know, for always.


00:44:02.500 --> 00:44:04.740
- You actually need to do that still


00:44:04.740 --> 00:44:08.820
for your generated API documentation.


00:44:08.820 --> 00:44:12.380
So Sphinx has an extension called AutoDoc


00:44:12.380 --> 00:44:14.620
that will take all the doc strings in your code


00:44:14.620 --> 00:44:18.460
and transform that into API documentation.


00:44:18.460 --> 00:44:23.140
And that still doesn't have a replacement.


00:44:23.140 --> 00:44:28.140
So what you do is you write your doc strings


00:44:28.140 --> 00:44:30.420
using restructured text,


00:44:30.420 --> 00:44:33.740
maybe using Google-style doc strings


00:44:33.740 --> 00:44:36.180
or NumPy-style docstrings.


00:44:36.180 --> 00:44:41.180
And then you use the auto-doc directive


00:44:41.180 --> 00:44:44.500
to basically quote it inline


00:44:44.500 --> 00:44:48.420
in your markdown documentation.


00:44:48.420 --> 00:44:50.980
So that's a little bit of restructured text there.


00:44:50.980 --> 00:44:53.060
I think they're working on filling this gap.


00:44:53.060 --> 00:44:54.500
There's some work going on


00:44:54.500 --> 00:44:59.100
and I'm really looking forward to that feature coming


00:44:59.100 --> 00:45:01.460
because then everything will be just markdown.


00:45:01.460 --> 00:45:03.260
- Yeah, that'd be great, for sure.


00:45:03.260 --> 00:45:05.640
I do want to give a quick shout out to Paul Everett's course


00:45:05.640 --> 00:45:08.900
that he wrote over at DocPython on Sphinx.


00:45:08.900 --> 00:45:11.060
If you're interested, check out this free course


00:45:11.060 --> 00:45:12.780
that he put together for us over there.


00:45:12.780 --> 00:45:14.060
So that's worth checking out.


00:45:14.060 --> 00:45:16.180
Now, I'll put a link in the show notes.


00:45:16.180 --> 00:45:22.460
Now, if you're building a Python package that goes on PyPI,


00:45:22.460 --> 00:45:26.100
like not everything people build with Python goes on PyPI,


00:45:26.100 --> 00:45:28.620
or even should be structured in the shape of a package,


00:45:28.620 --> 00:45:29.620
potentially.


00:45:29.620 --> 00:45:30.780
But a lot of them are, right?


00:45:30.780 --> 00:45:31.860
A lot of libraries are.


00:45:31.860 --> 00:45:36.860
So you talk about automating uploads to PyPI and test PyPI.


00:45:36.860 --> 00:45:41.860
Wanna talk about the story there?


00:45:41.860 --> 00:45:45.420
- Yeah, so PyPI, the Python package index there


00:45:45.420 --> 00:45:47.940
actually has a sibling called test PyPI,


00:45:47.940 --> 00:45:49.700
which is just a separate instance.


00:45:49.700 --> 00:45:55.620
It's very useful to upload your wheels and SDIs


00:45:55.620 --> 00:46:00.540
to test PyPI before you actually do a release


00:46:00.540 --> 00:46:06.060
because you can check them and see if everything is the way


00:46:06.060 --> 00:46:08.700
you expect it to be.


00:46:08.700 --> 00:46:12.460
Basically, install the package end to end.


00:46:12.460 --> 00:46:15.900
And in CI, what I like to do is I


00:46:15.900 --> 00:46:19.920
have the switch where if it's an actual release,


00:46:19.920 --> 00:46:21.260
I upload to PyPI.


00:46:21.260 --> 00:46:24.580
But in all the other cases, I just upload to test PyPI.


00:46:24.580 --> 00:46:28.220
So every commit that goes into the main branch


00:46:28.220 --> 00:46:32.620
is going to be built and uploaded to test PyPI.


00:46:32.620 --> 00:46:37.260
Yeah, you can't change what you put into PyPI.


00:46:37.260 --> 00:46:39.060
You can add new versions that replace it,


00:46:39.060 --> 00:46:41.700
but you can't change a version, really.


00:46:41.700 --> 00:46:44.420
The best you can do is yank the release.


00:46:44.420 --> 00:46:47.420
It's still going to be there for those


00:46:47.420 --> 00:46:49.100
who have pinned the version.


00:46:49.100 --> 00:46:53.020
But otherwise, it will be invisible to those who just


00:46:53.020 --> 00:46:54.460
want to get the latest release.


00:46:54.460 --> 00:46:57.700
But it's no over-replacing.


00:46:57.700 --> 00:47:00.740
Yeah, so it's a nice reminder and automation to set up


00:47:00.740 --> 00:47:04.980
to remember there's test PyPI and automatically have


00:47:04.980 --> 00:47:07.420
your project known and used.


00:47:07.420 --> 00:47:08.780
All right, here's another one.


00:47:08.780 --> 00:47:10.060
When I talked about stuff I was learning,


00:47:10.060 --> 00:47:11.580
this one is definitely new to me.


00:47:11.580 --> 00:47:13.620
And this is cool.


00:47:13.620 --> 00:47:17.300
Automate release notes with Release Drafter.


00:47:17.300 --> 00:47:18.540
Tell us about Release Drafter.


00:47:18.540 --> 00:47:19.140
This is cool.


00:47:19.140 --> 00:47:26.340
So Release Drafter takes the titles of your merged PRs


00:47:26.340 --> 00:47:30.820
And it creates a draft release.


00:47:30.820 --> 00:47:34.820
So the release, in this sense, is the GitHub release.


00:47:34.820 --> 00:47:37.460
That is something that you can see


00:47:37.460 --> 00:47:41.300
on the right-hand side of the GitHub repo page.


00:47:41.300 --> 00:47:44.260
You have this releases link.


00:47:44.260 --> 00:47:51.580
And that basically gets you to either a list of tags,


00:47:51.580 --> 00:47:56.260
or you can describe the changes.


00:47:56.260 --> 00:47:59.500
So it's essentially release notes on GitHub.


00:47:59.500 --> 00:48:03.540
- Surely there's some kind of weird inception


00:48:03.540 --> 00:48:06.460
where release drafter uses release drafter


00:48:06.460 --> 00:48:08.220
to build this change logs or something,


00:48:08.220 --> 00:48:09.660
I'm guessing, right?


00:48:09.660 --> 00:48:11.500
Probably. - I'm sure they do.


00:48:11.500 --> 00:48:13.860
So release drafter is really handy for that.


00:48:13.860 --> 00:48:20.940
Now, actually you can, so GitHub releases


00:48:20.940 --> 00:48:23.300
have an auto-generate button.


00:48:23.300 --> 00:48:26.980
So some of this functionality you will actually


00:48:26.980 --> 00:48:30.620
get even without using the release drafter action.


00:48:30.620 --> 00:48:38.540
So I think the release drafter action is somewhat more


00:48:38.540 --> 00:48:41.380
flexible, what it gives you.


00:48:41.380 --> 00:48:43.660
And basically means you're going to have


00:48:43.660 --> 00:48:47.820
to add a GitHub Actions workflow for it and the configuration


00:48:47.820 --> 00:48:48.380
file.


00:48:48.380 --> 00:48:52.900
And you can provide a template for your release nodes


00:48:52.900 --> 00:48:57.500
and some replacement marker that are placeholder


00:48:57.500 --> 00:49:01.860
that where all the PR titles go.


00:49:01.860 --> 00:49:02.740
- This thing is cool.


00:49:02.740 --> 00:49:04.900
And it even has a draft.


00:49:04.900 --> 00:49:10.380
Like you can see the draft release notes as well.


00:49:10.380 --> 00:49:11.220
Yeah.


00:49:11.220 --> 00:49:12.040
- You can see it.


00:49:12.040 --> 00:49:15.060
And then you have a button to publish the draft release.


00:49:15.060 --> 00:49:16.980
And if you don't have a tag yet,


00:49:16.980 --> 00:49:20.840
that's also going to add a get tag to your repository.


00:49:20.840 --> 00:49:21.680
- Cool.


00:49:21.680 --> 00:49:22.500
Oh yeah, that's really nice.


00:49:22.500 --> 00:49:27.500
lightweight approach to the release notes question.


00:49:27.500 --> 00:49:31.180
- So I see that it has a what's changed,


00:49:31.180 --> 00:49:33.300
but I also saw in the release drafter


00:49:33.300 --> 00:49:35.060
had like bug fixes and stuff.


00:49:35.060 --> 00:49:37.060
Is there a way to teach it?


00:49:37.060 --> 00:49:39.620
Like these PRs are related to bugs


00:49:39.620 --> 00:49:42.820
and these are additions and stuff like that?


00:49:42.820 --> 00:49:46.260
- Yes, you can do that using labels on your PRs.


00:49:46.260 --> 00:49:49.460
So if it's a bug fix, you have a label,


00:49:49.460 --> 00:49:52.500
you know, then you can put it under a separate section.


00:49:52.500 --> 00:49:55.540
- Cool, so basically just drive it, GitHub labels, cool.


00:49:55.540 --> 00:49:57.500
All right, we got a lot to go through here.


00:49:57.500 --> 00:50:00.340
So maybe these next two are pretty quick here.


00:50:00.340 --> 00:50:01.840
Actually, the next three here.


00:50:01.840 --> 00:50:07.360
You talked about this sort of article


00:50:07.360 --> 00:50:09.880
and the cookie cutter drifting quite a bit apart


00:50:09.880 --> 00:50:11.260
because so many things have changed.


00:50:11.260 --> 00:50:13.060
One thing that seems to be pretty stable


00:50:13.060 --> 00:50:14.340
is like since black came out,


00:50:14.340 --> 00:50:16.700
people are all about just black.


00:50:16.700 --> 00:50:18.660
It hasn't seemed to gone out of style at all.


00:50:18.660 --> 00:50:22.780
I think that's a pretty stable one, right?


00:50:22.780 --> 00:50:25.580
- It really makes a huge difference for productivity.


00:50:25.580 --> 00:50:30.260
And I feel if I'm contributing to somebody else's project,


00:50:30.260 --> 00:50:32.020
it makes things so much easier to know


00:50:32.020 --> 00:50:33.780
that there's a consistent style.


00:50:33.780 --> 00:50:37.580
I don't need to be afraid to destroy somebody's,


00:50:37.580 --> 00:50:41.380
you know, well-crafted, handcrafted formatted code.


00:50:41.380 --> 00:50:46.260
I can just run black and it's also great,


00:50:46.260 --> 00:50:47.980
really helps readability.


00:50:47.980 --> 00:50:49.820
It's basically the style becomes invisible.


00:50:49.820 --> 00:50:54.420
So I love black and black now left us a better status


00:50:54.420 --> 00:50:55.260
in January.


00:50:55.260 --> 00:50:56.300
So we now have


00:50:56.300 --> 00:51:00.820
- Official black.


00:51:00.820 --> 00:51:01.940
- Finally.


00:51:01.940 --> 00:51:04.660
- Well known as #000000.


00:51:04.660 --> 00:51:06.020
There's no more debate.


00:51:06.020 --> 00:51:06.860
- Right.


00:51:06.860 --> 00:51:10.820
So, yeah, I'm definitely a big fan of black.


00:51:10.820 --> 00:51:12.500
- Indeed.


00:51:12.500 --> 00:51:14.280
I also give a shout out to Predeer as well.


00:51:14.280 --> 00:51:15.620
And then sort of related,


00:51:15.620 --> 00:51:18.260
you have import sorting with isort?


00:51:18.260 --> 00:51:23.420
- So I've been using reorder Python imports for a long time,


00:51:23.420 --> 00:51:26.820
which is also a tool by Anthony Sautillier


00:51:26.820 --> 00:51:28.460
who wrote a pre-commit.


00:51:28.460 --> 00:51:30.060
- Yes, I wanted to give Anthony a shout out,


00:51:30.060 --> 00:51:31.740
but I wasn't a hundred percent sure


00:51:31.740 --> 00:51:33.500
that I had the name just right in my memory.


00:51:33.500 --> 00:51:35.140
So I didn't want to like misattribute it.


00:51:35.140 --> 00:51:36.640
But yeah, he also did pre-commit,


00:51:36.640 --> 00:51:38.280
which I had him on the show for.


00:51:38.280 --> 00:51:43.280
- Right, so these days I actually like to use isort,


00:51:43.900 --> 00:51:47.620
which is what everybody uses.


00:51:47.620 --> 00:51:52.380
It's since ISOD 5, it's become much nicer to use.


00:51:52.380 --> 00:51:53.860
It uses the AST more.


00:51:53.860 --> 00:51:57.580
It has no trouble figuring out what your third party


00:51:57.580 --> 00:51:59.100
dependencies are.


00:51:59.100 --> 00:52:01.980
And it has an option--


00:52:01.980 --> 00:52:05.140
so it has these profiles to make it really easy to be


00:52:05.140 --> 00:52:07.860
compatible with Black style.


00:52:07.860 --> 00:52:12.780
And what I like to do is I like to put each commit--


00:52:12.780 --> 00:52:15.900
sorry, each import on a single line, which is actually


00:52:15.900 --> 00:52:18.380
what reorder Python imports does as well.


00:52:18.380 --> 00:52:21.620
And it greatly reduces the chance of merge conflicts.


00:52:21.620 --> 00:52:23.660
- Oh, right, okay, yeah, of course, sure.


00:52:23.660 --> 00:52:26.460
Cool.


00:52:26.460 --> 00:52:30.420
A quick question, just stepping back to the release drafter.


00:52:30.420 --> 00:52:32.780
Michael out in the audience says,


00:52:32.780 --> 00:52:36.940
his biggest hurdle is for doing regular and good releases


00:52:36.940 --> 00:52:38.180
are change logs.


00:52:39.780 --> 00:52:44.420
How does Release Drafter sort of fit into that?


00:52:44.420 --> 00:52:47.020
Basically, if you structure everything as a PR,


00:52:47.020 --> 00:52:49.540
it'll capture it?


00:52:49.540 --> 00:52:54.900
Yes, so Release Drafter only drafts the GitHub release


00:52:54.900 --> 00:52:55.380
for you.


00:52:55.380 --> 00:53:02.300
If you want to have, say, a page in your Sphinx documentation,


00:53:02.300 --> 00:53:04.060
you're going to need to pull that out.


00:53:04.060 --> 00:53:12.500
There's actually, I think, Evi Joachim wrote--


00:53:12.500 --> 00:53:15.340
sorry, that's his GitHub handle.


00:53:15.340 --> 00:53:17.620
I'm sure.


00:53:17.620 --> 00:53:19.260
We should put a link later.


00:53:19.260 --> 00:53:22.420
But there's a tool that will pull the GitHub release


00:53:22.420 --> 00:53:25.420
and insert it into your Sphinx documentation.


00:53:25.420 --> 00:53:27.620
So you can do that.


00:53:27.620 --> 00:53:30.860
There's also Town Crier, which really should be mentioned,


00:53:30.860 --> 00:53:34.780
and Scriv, which was written by Ned Batchelder.


00:53:34.780 --> 00:53:38.540
Those are tools that allow you to add release notes


00:53:38.540 --> 00:53:42.380
to your PRs as snippets or fragments.


00:53:42.380 --> 00:53:47.300
And that scales very well if you have an open source project


00:53:47.300 --> 00:53:49.500
with many contributors.


00:53:49.500 --> 00:53:51.580
So yeah.


00:53:51.580 --> 00:53:52.580
>>Luis: Oh, that's cool.


00:53:52.580 --> 00:53:54.180
>>Sven: Still figuring out the best way


00:53:54.180 --> 00:53:59.740
to maybe integrate all of these in some way.


00:53:59.740 --> 00:54:00.240
But yeah.


00:54:00.240 --> 00:54:02.480
- Sure, you can overdo it for sure.


00:54:02.480 --> 00:54:04.400
All right, I think a quick, just a quick shout out,


00:54:04.400 --> 00:54:07.880
speaking of Ned Batchelder, we have pytest,


00:54:07.880 --> 00:54:12.320
coverage.py and CodeCov all in there is neat.


00:54:12.320 --> 00:54:16.880
And then CLI interface with Click.


00:54:16.880 --> 00:54:19.600
So that's an interesting one, a popular one as well.


00:54:19.600 --> 00:54:23.480
- Absolutely, so that's from the palace project.


00:54:23.480 --> 00:54:26.560
So the same family of projects like Flask.


00:54:26.560 --> 00:54:29.560
There's also a nice wrapper for Click called Typer.


00:54:29.560 --> 00:54:31.000
- Yes.


00:54:31.000 --> 00:54:33.720
- Written by the FastAPI author.


00:54:33.720 --> 00:54:34.800
- Yeah, when I saw that using click,


00:54:34.800 --> 00:54:36.720
I'm like, hmm, you're such a fan of types.


00:54:36.720 --> 00:54:38.860
Maybe typer is also relevant here.


00:54:38.860 --> 00:54:42.600
- I've actually, I just had another look at typer


00:54:42.600 --> 00:54:44.800
and I think I do like it after all.


00:54:44.800 --> 00:54:46.400
I actually really like it.


00:54:46.400 --> 00:54:50.340
Initially I was like, well, it's actually not so,


00:54:50.340 --> 00:54:54.480
I kind of like how click gives you these decorators


00:54:54.480 --> 00:54:58.440
and separates your option help texts


00:54:58.440 --> 00:55:00.540
from the actual function.


00:55:00.540 --> 00:55:05.320
But it is true that typer really reduces duplication


00:55:05.320 --> 00:55:09.560
because you don't have to repeat the types of your options.


00:55:09.560 --> 00:55:12.840
They're just the type annotations of your parameters.


00:55:12.840 --> 00:55:14.160
So that's really neat.


00:55:14.160 --> 00:55:15.000
- Nice.


00:55:15.000 --> 00:55:17.560
All right, let's see.


00:55:17.560 --> 00:55:20.840
So continuing with the typing story,


00:55:20.840 --> 00:55:22.320
we've got two things here.


00:55:22.320 --> 00:55:24.560
A static type checking with mypy.


00:55:24.560 --> 00:55:26.680
Suspect a lot of people who are really into typing


00:55:26.680 --> 00:55:28.120
know about this.


00:55:28.120 --> 00:55:29.580
the CLI, you run against your code,


00:55:29.580 --> 00:55:32.080
and it'll make sure everything hangs together.


00:55:32.080 --> 00:55:34.480
If this function is calling that function with that variable,


00:55:34.480 --> 00:55:36.600
and you said that variable is one of these things,


00:55:36.600 --> 00:55:39.320
it makes sure that all is going to fit together.


00:55:39.320 --> 00:55:41.300
If you get that working, then you


00:55:41.300 --> 00:55:42.780
might be open to having something


00:55:42.780 --> 00:55:45.600
like my.pyc for optimizations and so on,


00:55:45.600 --> 00:55:47.320
which is also interesting.


00:55:47.320 --> 00:55:49.160
But one that maybe people haven't heard about


00:55:49.160 --> 00:55:52.480
is runtime type checking with TypeGuard.


00:55:52.480 --> 00:55:53.640
>>Right.


00:55:53.640 --> 00:55:57.760
I think it's really one of the most undervalued projects


00:55:57.760 --> 00:56:02.480
out there in the typing space, TypeGuard is so useful.


00:56:02.480 --> 00:56:04.000
When I first heard about it, I was


00:56:04.000 --> 00:56:07.160
like, why would you want to runtime type check your code?


00:56:07.160 --> 00:56:10.240
If you have a static type checker,


00:56:10.240 --> 00:56:14.080
then you need to hit all the code paths.


00:56:14.080 --> 00:56:18.320
Static type checking is great because it can just basically


00:56:18.320 --> 00:56:21.440
deduce the type correctness.


00:56:21.440 --> 00:56:24.280
TypeGuard is really useful if you're--


00:56:24.280 --> 00:56:27.200
For example, if you're interfacing with third party


00:56:27.200 --> 00:56:31.600
libraries who may or may not have type annotations,


00:56:31.600 --> 00:56:32.480
if they do, great.


00:56:32.480 --> 00:56:36.200
But how much do you trust them?


00:56:36.200 --> 00:56:36.960
>>Luis: Right.


00:56:36.960 --> 00:56:38.520
Yeah, just because it says it, nothing


00:56:38.520 --> 00:56:41.400
enforces that where it said it returns an int.


00:56:41.400 --> 00:56:42.720
It could return none.


00:56:42.720 --> 00:56:45.000
And it should have said optional int, but it didn't.


00:56:45.000 --> 00:56:47.920
>>Chris: Your code can absolutely


00:56:47.920 --> 00:56:50.960
have type correctness as far as mypy is concerned.


00:56:50.960 --> 00:56:55.240
but that might be just because there are some any types


00:56:55.240 --> 00:56:57.400
or it's just kind of a loosey type


00:56:57.400 --> 00:57:01.440
because there's no way to be stricter about the actual types


00:57:01.440 --> 00:57:03.000
and TypeGuard will check that.


00:57:03.000 --> 00:57:07.220
So the way I like to use TypeGuard is as a pytest plugin.


00:57:07.220 --> 00:57:11.120
So you're basically running your test suite.


00:57:11.120 --> 00:57:14.480
And if you have complete code coverage,


00:57:14.480 --> 00:57:18.600
that should give you a good chance to catch any--


00:57:18.600 --> 00:57:19.440
- Oh, interesting.


00:57:19.440 --> 00:57:23.880
can turn it on while your tests are running and it will run time check everything but


00:57:23.880 --> 00:57:27.280
then in production not turn it on?


00:57:27.280 --> 00:57:28.280
>> Exactly.


00:57:28.280 --> 00:57:29.280
>> Okay.


00:57:29.280 --> 00:57:34.400
>> So you basically specify it.


00:57:34.400 --> 00:57:37.920
So you install it next to pytest and then you pass an option.


00:57:37.920 --> 00:57:47.360
I think it's type guard packages and pass the name of your package and then type guard


00:57:47.360 --> 00:57:55.400
is going to wrap every function in your code


00:57:55.400 --> 00:57:59.960
and check the parameter types and the return time.


00:57:59.960 --> 00:58:01.000
So that's really useful.


00:58:01.000 --> 00:58:01.920
It's also a library.


00:58:01.920 --> 00:58:04.840
So if you want to explicitly check in production,


00:58:04.840 --> 00:58:07.040
you can also use typeguard for that.


00:58:07.040 --> 00:58:07.680
>>Nice.


00:58:07.680 --> 00:58:10.240
Yeah, it's got the type checked decorator, which probably--


00:58:10.240 --> 00:58:11.780
you can just put that on stuff if you


00:58:11.780 --> 00:58:13.400
want to make sure it's checked.


00:58:13.400 --> 00:58:14.800
Nice.


00:58:14.800 --> 00:58:16.560
OK, well, that's a good one to learn.


00:58:16.560 --> 00:58:21.560
Another one is you create your project,


00:58:21.560 --> 00:58:26.340
you start building it, two years later,


00:58:26.340 --> 00:58:28.720
who knows some feature is added.


00:58:28.720 --> 00:58:31.580
Some other language feature might be not the way to do


00:58:31.580 --> 00:58:34.640
things, so you talk about automated Python syntax upgrades


00:58:34.640 --> 00:58:37.380
with pyup upgrade.


00:58:37.380 --> 00:58:40.280
Yeah, this is cool.


00:58:40.280 --> 00:58:42.760
- That's another Anthony Sotile tool.


00:58:42.760 --> 00:58:45.720
So it also, you can run it from pre-commit


00:58:45.720 --> 00:58:53.840
it's going to essentially pass the AST of your--


00:58:53.840 --> 00:58:56.560
so the abstract syntax tree of your code


00:58:56.560 --> 00:59:05.000
and look for things that have better ways to express them


00:59:05.000 --> 00:59:06.360
in your versions of Python.


00:59:06.360 --> 00:59:11.360
So basically, what you say you drop Python 3.6,


00:59:11.360 --> 00:59:19.080
And automatically, you get unions, like the pipe--


00:59:19.080 --> 00:59:21.040
>>Right, right, like int pipe none


00:59:21.040 --> 00:59:24.320
versus optional bracket int, something like that, right?


00:59:24.320 --> 00:59:25.040
Yeah.


00:59:25.040 --> 00:59:26.720
>>These kinds of things.


00:59:26.720 --> 00:59:32.640
Yeah, giving you nice set comprehensions of cost


00:59:32.640 --> 00:59:34.640
to the set built-in, those of these.


00:59:34.640 --> 00:59:37.400
And it's very nice if you are supporting


00:59:37.400 --> 00:59:39.680
multiple Python versions, and you've


00:59:39.680 --> 00:59:41.360
been waiting to use this feature.


00:59:41.360 --> 00:59:45.400
And now finally, you can drop the last Python version


00:59:45.400 --> 00:59:49.680
that didn't support it, and you get this for free.


00:59:49.680 --> 00:59:50.720
I just brought it for you.


00:59:50.720 --> 00:59:52.280
- Yeah, that is interesting.


00:59:52.280 --> 00:59:54.080
I hadn't really thought about that.


00:59:54.080 --> 00:59:55.600
Some of these are not language features


00:59:55.600 --> 00:59:58.480
in the sense that people are thinking,


00:59:58.480 --> 01:00:01.180
oh, well now I can use async and await,


01:00:01.180 --> 01:00:05.920
which would take a real important, significant change.


01:00:05.920 --> 01:00:09.640
But it's just like, oh, now you're able to,


01:00:09.640 --> 01:00:13.420
because of PEP 289 pass a generator directly


01:00:13.420 --> 01:00:15.300
to the min function or max or some


01:00:15.300 --> 01:00:17.520
rather than a list comprehension


01:00:17.520 --> 01:00:19.160
which then gets processed, right?


01:00:19.160 --> 01:00:22.540
And that would just be more efficient across the board.


01:00:22.540 --> 01:00:25.460
And so that just happens automatically, right?


01:00:25.460 --> 01:00:26.300
Cool.


01:00:26.300 --> 01:00:28.820
Yeah, very neat one.


01:00:28.820 --> 01:00:32.720
All right, next security audits.


01:00:32.720 --> 01:00:37.200
- So there's, there's Bannet.


01:00:38.220 --> 01:00:42.780
Banit is a tool that looks at your Python code


01:00:42.780 --> 01:00:47.020
and figures out if there are any things that may or may not


01:00:47.020 --> 01:00:51.560
give you a security vulnerability


01:00:51.560 --> 01:00:54.460
or any kind of security issue.


01:00:54.460 --> 01:00:59.080
It flags some things like just importing a sub process


01:00:59.080 --> 01:01:01.480
and you can no QA it.


01:01:01.480 --> 01:01:04.220
I still find that useful


01:01:06.260 --> 01:01:09.200
because it just gives me a moment to think about


01:01:09.200 --> 01:01:14.200
all the implications of spawning other processes


01:01:14.200 --> 01:01:15.320
from our Python code.


01:01:15.320 --> 01:01:22.120
But it has a lot of checks in your Python code base.


01:01:22.120 --> 01:01:28.940
So it's very nice to use it to guard yourself against some.


01:01:28.940 --> 01:01:33.520
- Right, like it'll detect things like yaml.load


01:01:33.520 --> 01:01:35.360
should be yaml.safeload.


01:01:35.360 --> 01:01:38.380
and I bet there's something there about pickling.


01:01:38.380 --> 01:01:39.220
(laughs)


01:01:39.220 --> 01:01:40.060
- Yeah, for sure.


01:01:40.060 --> 01:01:42.000
- It's gotta be.


01:01:42.000 --> 01:01:44.360
All right, and then, yeah, exactly.


01:01:44.360 --> 01:01:46.640
Safety is the other one, yeah?


01:01:46.640 --> 01:01:48.800
- That basically just checks your dependencies.


01:01:48.800 --> 01:01:52.300
So there's a curated database of security vulnerabilities


01:01:52.300 --> 01:01:56.600
and it's gonna see if you have any dependency


01:01:56.600 --> 01:01:58.320
in a version that was vulnerable.


01:01:58.320 --> 01:02:01.160
- Nice.


01:02:01.160 --> 01:02:04.560
And just stepping back just a moment,


01:02:04.560 --> 01:02:06.840
Nick Maw points out that Typer's amazing


01:02:06.840 --> 01:02:08.480
when it comes to the documentation


01:02:08.480 --> 01:02:11.860
in the --help option, which is pretty cool.


01:02:11.860 --> 01:02:15.560
Let's see, going back to, yeah,


01:02:15.560 --> 01:02:18.800
checking the documentation with xdoctest.


01:02:18.800 --> 01:02:23.320
- So xdoctest is essentially a rewrite


01:02:23.320 --> 01:02:27.640
of a standard library or utility, it's called doctest.


01:02:27.640 --> 01:02:31.520
And what does it do?


01:02:31.520 --> 01:02:34.560
So suppose you have a doc string with an example code


01:02:34.560 --> 01:02:38.640
that shows how you are supposed to use a library


01:02:38.640 --> 01:02:42.840
or a function, and you commonly write these


01:02:42.840 --> 01:02:46.720
with the Python interpreter prompt


01:02:46.720 --> 01:02:52.120
to give you like, what does the user type,


01:02:52.120 --> 01:02:56.080
import my package, and underneath you have the output


01:02:56.080 --> 01:02:59.480
of whatever functions you called and so on.


01:03:00.560 --> 01:03:04.480
And so doc test runs these examples


01:03:04.480 --> 01:03:07.520
and sees if they produce the expected output.


01:03:07.520 --> 01:03:08.760
They don't throw--


01:03:08.760 --> 01:03:10.280
raise exceptions and so on.


01:03:10.280 --> 01:03:14.320
xdoctest is a rewrite that uses the AST more


01:03:14.320 --> 01:03:17.120
than regular expressions, which is nice


01:03:17.120 --> 01:03:23.920
and is also a bit more flexible and has a few nice features


01:03:23.920 --> 01:03:25.600
compared to doc test.


01:03:25.600 --> 01:03:26.680
>>Victor: All right, cool.


01:03:26.680 --> 01:03:30.360
So if you have an example in your documentation,


01:03:30.360 --> 01:03:33.160
here's a way to automatically make sure it's all good.


01:03:33.160 --> 01:03:37.740
Also another audience question follow up here,


01:03:37.740 --> 01:03:41.200
Basil asks, what do you think about services like SYNC,


01:03:41.200 --> 01:03:43.660
a SNYK, sorry, S-N-Y-K,


01:03:43.660 --> 01:03:48.660
SNYK to check dependencies, like for security, right?


01:03:48.660 --> 01:03:52.860
So you depend on Flask, Flask depends on,


01:03:52.860 --> 01:03:55.200
it's dangerous, it's dangerous,


01:03:55.200 --> 01:03:57.660
who knows, theoretically could have some issue,


01:03:57.660 --> 01:04:00.260
like that kind of check I'm thinking he's asking for.


01:04:00.260 --> 01:04:05.260
I haven't used Snake yet, so I'm only familiar with safety.


01:04:05.260 --> 01:04:09.760
- Nice, okay, cool.


01:04:09.760 --> 01:04:13.980
Getting close to the end.


01:04:13.980 --> 01:04:16.260
Then I have a question about all these taken as a whole.


01:04:16.260 --> 01:04:19.380
All right, generating API documentation


01:04:19.380 --> 01:04:22.060
with Autodoc and Napoleon?


01:04:22.060 --> 01:04:24.420
- Right, so we talked about this before.


01:04:24.420 --> 01:04:25.940
This takes your doc strings


01:04:25.940 --> 01:04:27.900
and generates API documentation.


01:04:27.900 --> 01:04:32.900
And this is not a RESTful API, like Swagger OpenAPI.


01:04:32.900 --> 01:04:38.300
This is like my Python libraries function documentation.


01:04:38.300 --> 01:04:39.140
- Exactly, yeah.


01:04:39.140 --> 01:04:43.140
That's so the reference for the functions


01:04:43.140 --> 01:04:44.380
in your package.


01:04:44.380 --> 01:04:45.220
- Got it.


01:04:45.220 --> 01:04:51.380
- And Napoleon is a tool that will add support


01:04:51.380 --> 01:04:56.180
for doc strings that are written Google style, for example,


01:04:56.180 --> 01:04:58.900
or some other conventions for doc strings.


01:04:58.900 --> 01:05:01.140
So Google style is pretty lightweight,


01:05:01.140 --> 01:05:02.940
which is- - Yeah, I'm a fan of that as well.


01:05:02.940 --> 01:05:03.780
Yeah.


01:05:03.780 --> 01:05:06.960
- Yeah, declaring your arguments and returns.


01:05:06.960 --> 01:05:08.780
- Okay, nice.


01:05:08.780 --> 01:05:13.620
Generate a command line reference with Sphinx click.


01:05:13.620 --> 01:05:17.400
So I'm guessing if you're using click,


01:05:17.400 --> 01:05:20.480
this might be relevant.


01:05:20.480 --> 01:05:24.660
- Right, so you already have all your option help texts


01:05:24.660 --> 01:05:28.720
and command descriptions in Click.


01:05:28.720 --> 01:05:31.780
So why not just use them to generate the documentation?


01:05:31.780 --> 01:05:34.540
And that's basically what Sphinx Click does.


01:05:34.540 --> 01:05:39.540
So it takes, so when you build your documentation


01:05:39.540 --> 01:05:43.580
and you use things like Autodoc or Sphinx Click,


01:05:43.580 --> 01:05:46.580
you have to remember to install your own package.


01:05:46.580 --> 01:05:48.940
And then these tools can just import it


01:05:48.940 --> 01:05:53.940
and read the documentation.


01:05:53.940 --> 01:05:56.500
read all the documentation that you have in line


01:05:56.500 --> 01:06:00.080
in your code, including click option of text.


01:06:00.080 --> 01:06:00.980
- Yeah, very cool.


01:06:00.980 --> 01:06:05.020
All right, you've done all the work,


01:06:05.020 --> 01:06:07.700
you've documented it, you've tested it, it's good to go.


01:06:07.700 --> 01:06:10.060
Now you're gonna release it, put it on GitHub.


01:06:10.060 --> 01:06:11.860
And the last one is manage project labels


01:06:11.860 --> 01:06:13.440
with GitHub Labeler.


01:06:13.440 --> 01:06:18.540
- So the idea of Labeler is that you,


01:06:18.540 --> 01:06:21.500
instead of going through the web interface


01:06:21.500 --> 01:06:26.500
and then typing in all the color codes and hex and so on,


01:06:26.500 --> 01:06:32.500
you can just use a file that you put in your repository


01:06:32.500 --> 01:06:37.620
to manage all your labels for your PRs and for your issues.


01:06:37.620 --> 01:06:41.860
That's really helpful and makes it really easy


01:06:41.860 --> 01:06:43.960
if you're collaborating with other people.


01:06:43.960 --> 01:06:46.500
- Nice.


01:06:46.500 --> 01:06:48.660
Yeah, that's great.


01:06:48.660 --> 01:06:52.260
- Okay, well, that's your cookie cutter.


01:06:52.260 --> 01:06:57.040
And in one fail swoop, in one single CLI cookie cutter


01:06:57.040 --> 01:06:58.860
command, you get all of these.


01:06:58.860 --> 01:07:03.460
So when this runs, I should have just run it


01:07:03.460 --> 01:07:07.140
and played with it, but does it give you an option


01:07:07.140 --> 01:07:10.280
to say, you know, don't install my pie,


01:07:10.280 --> 01:07:12.140
or does it just kind of give it all to you?


01:07:12.140 --> 01:07:14.100
What's the, I know cookie cutter has a lot


01:07:14.100 --> 01:07:16.180
of conditional behaviors and stuff.


01:07:16.180 --> 01:07:17.940
Like, what's the experience of using this


01:07:17.940 --> 01:07:19.700
a creative project?


01:07:19.700 --> 01:07:23.660
I have personally resisted putting in too many options.


01:07:23.660 --> 01:07:24.860
It's kind of--


01:07:24.860 --> 01:07:28.700
I try to find-- to kind of show one way that works,


01:07:28.700 --> 01:07:31.080
and also keep it maintainable.


01:07:31.080 --> 01:07:34.300
So I don't have a lot of--


01:07:34.300 --> 01:07:36.140
I don't want the combinatorial explosion.


01:07:36.140 --> 01:07:39.100
There's a little bit of options that it gives you.


01:07:39.100 --> 01:07:41.180
So you can choose the license, for example.


01:07:41.180 --> 01:07:47.420
And Cookie Cutter allows you to hide or show


01:07:47.420 --> 01:07:51.340
parts of your file tree depending on what the user chose.


01:07:51.340 --> 01:07:53.260
But basically it's not meant to be


01:07:53.260 --> 01:07:57.140
all the different packaging tools,


01:07:57.140 --> 01:08:00.420
all the different ways like TOX, NOX,


01:08:00.420 --> 01:08:04.380
the different CIs, that there was a conscious decision


01:08:04.380 --> 01:08:07.460
to basically say, okay, here's one way to do it,


01:08:07.460 --> 01:08:11.380
and I can really curate it and make sure that it all works.


01:08:11.380 --> 01:08:14.580
- Sure, keep it opinionated and straightforward


01:08:14.580 --> 01:08:15.960
and whatnot, right?


01:08:15.960 --> 01:08:22.280
>> I suppose if people really wanted to use talks instead of


01:08:22.280 --> 01:08:24.500
Knox and they wanted to use typer instead of click,


01:08:24.500 --> 01:08:25.940
they could fork the repo,


01:08:25.940 --> 01:08:28.960
create their own template and roll with that.


01:08:28.960 --> 01:08:29.960
>> Yeah.


01:08:29.960 --> 01:08:32.580
>> Cool. All right.


01:08:32.580 --> 01:08:35.020
Well, very interesting.


01:08:35.020 --> 01:08:38.580
One more quick audience question here from Michael says,


01:08:38.580 --> 01:08:42.900
can Labeler as in GitHub Labeler export existing settings?


01:08:42.900 --> 01:08:46.440
It'd be great to unify labels across repos.


01:08:46.440 --> 01:08:47.280
Any idea?


01:08:47.280 --> 01:08:48.100
- Right.


01:08:48.100 --> 01:08:51.440
I think there is a separate tool to do that.


01:08:51.440 --> 01:08:54.200
So I don't think that GitHub Labeler does it,


01:08:54.200 --> 01:08:56.200
but I remember that that was actually


01:08:56.200 --> 01:08:58.840
a community contribution,


01:08:58.840 --> 01:09:02.360
and I remember that the contributor who added this feature


01:09:02.360 --> 01:09:08.280
first went and exported the existing configuration


01:09:08.280 --> 01:09:10.680
from whatever we had in the repository.


01:09:10.680 --> 01:09:11.720
- Okay, yeah, cool.


01:09:12.720 --> 01:09:14.440
Yeah, very nice.


01:09:14.440 --> 01:09:18.600
All right, well, we are just a tiny bit out of time here.


01:09:18.600 --> 01:09:21.840
So unfortunately, even though there's a bunch of other stuff


01:09:21.840 --> 01:09:24.000
I wanted to cover, I don't think we're going to be able to


01:09:24.000 --> 01:09:26.560
'cause we covered so many cool things.


01:09:26.560 --> 01:09:29.120
You know, I did want to just give a quick shout out


01:09:29.120 --> 01:09:30.440
to your music.


01:09:30.440 --> 01:09:33.960
And in addition to being a lawyer and a software developer


01:09:33.960 --> 01:09:34.880
and open source person,


01:09:34.880 --> 01:09:39.040
you also do like compositional stuff, right?


01:09:39.040 --> 01:09:42.000
So you've got on your website, you've got a whole section,


01:09:42.000 --> 01:09:45.080
How many videos here, like 10 different music videos


01:09:45.080 --> 01:09:48.360
that you've put together that are pretty neat.


01:09:48.360 --> 01:09:51.200
You want to just give a quick shout out to that?


01:09:51.200 --> 01:09:56.360
Yeah, so I spent, I think, 10 years working both


01:09:56.360 --> 01:10:01.560
as a software engineer and a touring and recording musician.


01:10:01.560 --> 01:10:05.000
Also as an arranger, so I arranged some string quartets.


01:10:05.000 --> 01:10:11.080
And so I did arrangements for Naima Hosseini,


01:10:11.080 --> 01:10:16.280
who's a German indie singer.


01:10:16.280 --> 01:10:17.720
Definitely check her out.


01:10:17.720 --> 01:10:20.680
Jackie, I've been on tour with her really


01:10:20.680 --> 01:10:26.960
across all of Europe and wonderful reggae-inspired


01:10:26.960 --> 01:10:28.000
singer.


01:10:28.000 --> 01:10:29.280
And there are so many more.


01:10:29.280 --> 01:10:34.640
Like, I'm grateful for all the musicians


01:10:34.640 --> 01:10:37.040
I've been able to play with.


01:10:37.040 --> 01:10:39.200
Yeah, that's fantastic.


01:10:39.200 --> 01:10:40.360
I listen to a bunch of them.


01:10:40.360 --> 01:10:45.360
My favorite is Immer Alles, Akustisch im Deutschen Theater.


01:10:45.360 --> 01:10:48.240
That's the one with Naeemi Hussaini.


01:10:48.240 --> 01:10:49.320
That was a really good one.


01:10:49.320 --> 01:10:52.080
They're all good, but that one was really excellent.


01:10:52.080 --> 01:10:54.120
And then Michael also thinks that we should have


01:10:54.120 --> 01:10:56.320
a whole podcast about your compositional tools.


01:10:56.320 --> 01:10:58.340
Quickly, do you use Python for any of this stuff


01:10:58.340 --> 01:11:00.200
or is it kind of a separate world?


01:11:00.200 --> 01:11:02.880
- Sadly, it's pretty much a separate world.


01:11:02.880 --> 01:11:05.560
I've been using Ableton a lot


01:11:05.560 --> 01:11:08.920
and didn't really get into automating all of this


01:11:08.920 --> 01:11:12.840
- Not yet, not yet also.


01:11:12.840 --> 01:11:15.400
- I think Lucas Blanger does this kind of stuff.


01:11:15.400 --> 01:11:17.200
- Yeah, cool.


01:11:17.200 --> 01:11:18.120
- It can be done.


01:11:18.120 --> 01:11:20.000
- Yeah, people should check out Fox.


01:11:20.000 --> 01:11:21.120
Are you familiar with Fox.


01:11:21.120 --> 01:11:24.680
And that whole programming with composition,


01:11:24.680 --> 01:11:26.160
sort of building up music with Python.


01:11:26.160 --> 01:11:27.000
Have you seen this?


01:11:27.000 --> 01:11:28.360
- I know.


01:11:28.360 --> 01:11:29.200
- Oh my gosh.


01:11:29.200 --> 01:11:32.480
Every time I search for it, Fox.


01:11:32.480 --> 01:11:33.760
I think it's Fox.Python.


01:11:33.760 --> 01:11:35.060
I think that's what it is.


01:11:35.060 --> 01:11:38.640
If you check out the videos.


01:11:38.640 --> 01:11:41.800
Yeah, there's some neat live coding music


01:11:41.800 --> 01:11:43.360
with Fox.in Python.


01:11:43.360 --> 01:11:45.520
Every time I just randomly pick one of these videos,


01:11:45.520 --> 01:11:47.240
it's not really necessarily the best one.


01:11:47.240 --> 01:11:50.520
But there's some really neat ones of adding instruments


01:11:50.520 --> 01:11:51.160
in with Python.


01:11:51.160 --> 01:11:52.320
It's cool.


01:11:52.320 --> 01:11:53.640
People should check that out.


01:11:53.640 --> 01:11:54.520
Yeah.


01:11:54.520 --> 01:11:57.840
All right, well, we are out of time.


01:11:57.840 --> 01:12:01.760
Claudio, really quickly, final two questions.


01:12:01.760 --> 01:12:04.000
If you're going to write some Python code, what editor


01:12:04.000 --> 01:12:05.800
are you using these days?


01:12:05.800 --> 01:12:07.040
I use SpaceMX.


01:12:07.040 --> 01:12:08.740
I've been using Emacs for a long time


01:12:08.740 --> 01:12:11.180
and use it with VI bindings now.


01:12:11.180 --> 01:12:12.020
I like it.


01:12:12.020 --> 01:12:12.860
- Right on.


01:12:12.860 --> 01:12:17.400
And almost has to ask you for a notable PyPI package


01:12:17.400 --> 01:12:18.600
'cause we covered so many,


01:12:18.600 --> 01:12:19.660
but maybe just like, you know,


01:12:19.660 --> 01:12:20.800
what one stands out to you?


01:12:20.800 --> 01:12:21.980
Like you want to just give a shout out to


01:12:21.980 --> 01:12:24.420
either one we covered or a different one.


01:12:24.420 --> 01:12:27.920
- I think I just name a TypeGuard


01:12:27.920 --> 01:12:29.220
'cause it really deserves.


01:12:29.220 --> 01:12:33.500
TypeGuard 3 is gonna come out hopefully soon


01:12:33.500 --> 01:12:34.660
bringing new features.


01:12:34.660 --> 01:12:35.980
So yeah.


01:12:35.980 --> 01:12:36.920
- Cool.


01:12:36.920 --> 01:12:38.320
- All right, well, final call to action,


01:12:38.320 --> 01:12:42.520
people wanna get started with this hypermodern project


01:12:42.520 --> 01:12:44.620
idea that you've created, what do they do?


01:12:44.620 --> 01:12:50.480
- So just go to the cookie cutter hypermodern Python repo,


01:12:50.480 --> 01:12:54.720
check out the contributor guide and the code of conduct


01:12:54.720 --> 01:12:57.280
and we love contributors, so.


01:12:57.280 --> 01:12:58.440
- I know.


01:12:58.440 --> 01:13:00.840
How relevant is going back and reading the article?


01:13:00.840 --> 01:13:02.800
Is it drifted too far or is it enough


01:13:02.800 --> 01:13:04.480
to get like some of the zen?


01:13:04.480 --> 01:13:07.640
Or if you've listened to this, are you kind of good to go?


01:13:07.640 --> 01:13:11.940
- I think that the article series is still fun to read.


01:13:11.940 --> 01:13:15.120
I think these days, what I would recommend


01:13:15.120 --> 01:13:18.840
is that you don't just take the example code,


01:13:18.840 --> 01:13:23.100
maybe just generate a default project from the cookie cutter


01:13:23.100 --> 01:13:25.520
and then take a look at that as well,


01:13:25.520 --> 01:13:28.180
because some things have changed in the two years,


01:13:28.180 --> 01:13:31.600
but the article series kind of gives you the motivation


01:13:31.600 --> 01:13:35.720
for everything, and it's probably also more fun


01:13:35.720 --> 01:13:38.520
to read than the user guide for the project template, which


01:13:38.520 --> 01:13:40.600
is also there and very detailed.


01:13:40.600 --> 01:13:42.760
But yeah.


01:13:42.760 --> 01:13:43.960
>>Victor: Yeah, fantastic.


01:13:43.960 --> 01:13:46.340
All right, well, thank you so much for being on the show,


01:13:46.340 --> 01:13:48.200
and congrats on the cool project.


01:13:48.200 --> 01:13:49.480
>>Christian: Thank you very much.


01:13:49.480 --> 01:13:50.160
>>Victor: You bet.


01:13:50.160 --> 01:13:50.840
Bye.


01:13:50.840 --> 01:13:52.400
>>Christian: Bye-bye.