Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.
This is episode 291, recorded July 6, 2022, and I'm Brian Hawkins.
Hey, I'm Michael Kennedy.
Good to see you, Michael. It's been a while.
Yeah, good to see you, Brian, as well. Fun as always.
There's just a never-ending flow of fun stuff to talk about. I know we've got good stuff to share today, as always.
Yes, we do. Why don't you kick us off?
Licensing. Something everybody's super psyched about.
But I think you'll find this project interesting, and I don't know how you'll receive it, but I was like, wait a minute, what? This is odd.
So this project comes to us from Tom Nyhoff, and he sent this in and said, you know, it occurred to me that we have licenses for things like pytest.
So I could go search for pytest, and over on GitHub, or my programming lens, over on GitHub, I could check this out.
And what is the license? Well, it looks like the license is MIT.
So if I want to use pytest, I'm buying into the MIT license, right?
Yeah, kind of.
Maybe. Sometimes.
Only if you ship with it.
So it's going to be able to put pytest.
That's true.
But, you know, there are libraries like Request or whatever that you might, you know, ship, right?
Yeah.
So I'll just put pytest in here and see what we get.
So this project is called Python Project Insight, and it only has about 5,300 packages parsed in so far.
But the idea is you can say, load the dependencies, and it'll show you the licenses.
So for example, for pytest, we have the MIT license.
But pytest depends upon packaging and import lib metadata, and Colorama, and PyParsing, and Adders, and typing extensions.
Well, packaging has the Apache license.
Colorama has the BSD license.
Adders has MIT license.
So does pytest.
And then the Python Software Foundation has typing extensions.
So I don't know.
What do you think of that?
It is interesting.
And I don't know what to do with it.
I don't either.
I'm like, wait a minute.
I have to kind of sort of consider the transit of closure of the dependencies for their licenses.
And I had never really, I'm sure people are there, well, of course, Michael.
Of course, that's how it works.
But for me, I hadn't really thought about it.
I look at the project or the library and it has this license.
Like another one could be, you know, that you would build on before, more likely would be like requests.
So if we load the dependencies for requests, you have Apache, BSC, MIT, and Mozilla split across that one project.
So, yeah, I just think this is pretty wild.
I'm pointing out that TensorFlow is one of the more wild ones.
If you load up TensorFlow, there's just lots of different licenses here.
Like sample the GitHub licensing options, basically.
So if I was shipping a commercial project, a commercial product with Python that used a whole bunch of dependencies, I do know that this transitive closure stuff, the stuff that I'm actually shipping with, I really am supposed to list those and have those licenses listed in somewhere.
Right, in a sense, because you are shipping the dependencies of a thing in order for that thing to work, right?
Yeah, so you're at least saying, I'm using this, it's here, and here's the license for it.
I think that's the case.
I'm not a lawyer, of course.
But there's a whole bunch of these tools, like pytest, for instance, that we use that we don't ship.
Those are a different story.
And that's kind of a different license thing.
But I don't know about the packages.
Are these like the packages that these are shipping?
They're there.
They're not really being sold.
But do you have to list the licenses of the things that you're depending on?
I don't know.
I don't know either.
I think maybe in some times it doesn't matter.
But if it was GPL rather than LGPL, right, for example, that might be something you care about.
You know, I don't know.
I would love to hear people who really understand this super well, if they could like maybe tweet at us or comment on the YouTube stream or something like that about exactly what that means.
But I do think it's pretty interesting information.
Like mostly this shows the licenses, but it also shows the total size of installing the project and what libraries it depends upon.
So you can kind of like poke around with that as well.
That is that's actually pretty useful and interesting information as well that you don't really think about is how big of a download do I get if I put all these things, all these things together?
So, yeah.
Yeah.
And you can pile them up.
So you can say I'm using TensorFlow.
I'm using SK Learn.
I'm using Request or whatever.
Then you can say like, OK, for those three, tell me about what the story is.
You know what I mean?
Yeah.
And it gets a little more interesting still.
I guess maybe that's not quite right.
But that just comes with SciPy.
But anyway, yeah.
Something like that, right?
Yeah.
Yeah, neat.
So anyway, thanks, Tom, for sending that in and sharing it with us.
Well, I think I'll switch gears a little bit and talk about data classes.
So I actually really like data classes.
Have you used data classes much, Mike?
Michael?
Some, they definitely have some very neat properties.
I find myself kind of when I'm on the edge of using a data class, I'm like, maybe Pydantic.
But Frozen is a cool option.
You can add slots.
Slots makes so many things awesome in terms of lower memory usage, faster attribute access,
all kinds of things.
And if it's just slots equal true on the class definition, that's kind of nice.
Yeah, it is.
So Trey Hunter is a Python trainer.
And he came up with this cool tool on his Python morsels site called the undata class.
And it's actually also a library that he released, a little tool that's undata class.
And the idea is he was thinking, like, what would be the equivalent of a data class?
If you didn't write a data class, if you wanted to have the same sort of functionality, what would you do in a normal class?
So he's got this cool tool down.
And the example shows, yeah, it shows here slots, just a point with XYZ, all floats, and also shows frozen sets and slots.
But I'm going to turn those off.
And you just change the class and it changes the output.
And he prints out what an equivalent class would be if you didn't use data classes.
So actually, I'm not, and I tried to make sure I understood all of this.
So one of the things that it's kind of neat that it just, it's part of a learning tool that he's got that it shows you, you know, what you get with data classes.
But there's not a lot of description around, like, what all this means.
So this is sort of a fun thing to help you look up stuff, I guess.
So right off the bat, if we just have XYZ, you have a dunder init that takes XYZ as input values and assigns them.
And it comes with a nice wrapper class.
And then an EQ, a dunder EQ, which is for equality.
And one of the things I wanted to look up was to make sure I understood is what it does is it says if the other thing, if I'm getting compared with something else, if that other thing is also my same type in this case point, then you can do the equality comparison.
Otherwise, the raise and not implemented.
And that's just kind of a convention because Python.
And then what happens is Python will try to call EQ on the other thing of like reverse the order and stuff because it's kind of how Python works.
But it's one of those hidden sort of things is you need to kind of know that if you don't know what to do in an EQ class or an EQ function, raise not implemented.
And then Python goes from there.
And then resetting, though, if you if you give it slots, all the slots does is add slots to it.
And that's it, which is kind of cool.
And what slots does.
Yeah.
And what slots does is it makes it so that you can't add later.
So if you can't add a W attribute later to your point.
But then if you do frozen, it does a whole bunch of stuff.
Oh, you get a whole bunch more dunder methods.
But mostly these are just raising raising exceptions so that, you know, if you try to change it, it raises.
So anyway, this is kind of cool.
Yeah.
Do you see the dunder in it, the constructor implementation when you add frozen?
It doesn't say self dot X.
It's a it calls set adder like behind the scenes.
And then it implements set adder and del adder and raises exceptions if you try to mess with it.
Pretty wild.
That's cool.
We're also going to link to a couple a couple articles that that Trey wrote about.
He wrote about this, about how he wrote this.
And one of the things I'm bringing this up partly because I like data classes and it's kind of cool for people to learn what they are.
But in his developing this, he says he came up with having a great use case for the match case, new match case blocks in Python using Sentinel objects, which I'm not sure what he's talking about there.
So I'll take that.
Look at that.
Using text wrap ddent, which I love.
And it's nice to see somebody else using that slice.
And then an AST.
So he's using AST in here.
So it's kind of a cool, fun example of using that.
Anyway.
Cool.
Yeah.
A lot of cool stuff.
And actually, go back to the first one.
The first tab you got there.
Yeah.
One of the things I appreciate from this example is you just say class point, X colon float, Y colon float, Z colon float.
Yeah.
And put the data class attribute on it.
Look how much it's doing for you, right?
Like it's not just the typed values, but it's protecting the read-write ability, making it read-only.
It's getting a wrapper definition.
It's getting a hash ability, equality, not equality effectively by.
All right.
There's a lot of cool things it's adding for you there.
Yeah.
And he's-
He can appreciate the data class.
He's suggesting doing other stuff like using keyword-only and fields, different fields to see if you can change how it works.
But yeah, I'll have to play with this more.
And a reminder to everybody that is like data classes are almost enough, but you need more.
We'll also look at adders because adders is kind of a superset of data classes.
Right.
Yeah.
Fantastic.
That's great.
Cool.
All right, Brian, the next one I got here.
This one's for you.
Okay.
All right.
So let's go back.
We'll take a two-step process to approach this.
Did you ever use Lynx?
L-Y-N-X?
Yeah, like a long, long time ago.
I remember SSH.
I know.
I think I telneted into the mainframes back of the university and I'd run L-Y-N-X.
This predated the graphical web.
I mean, it's insane, right?
So, but it's a browser that is pure text in the terminal.
Today we have all these fancy browsers, but one of the things you had a lot of was like
keyboard shortcuts and other types of things you could do, right?
Yeah.
Well, now that it's 30 years later, what if we could go back to a time a little bit like
that?
So I want to introduce you to the Qt browser, Q-U-T-E browser.
Okay?
Okay.
So what is this?
The Qt browser is also like kind of in need of a homepage refresh, but it's a keyboard focused
browser with a minimal GUI.
And what's interesting is it's built with Python.
Okay.
So it's a full web browser built with Python.
And it's kind of like a, like a Vimper or one of these other ones that lets you do Vim
like control and behavior of it.
A little bit like, a little bit like links, but it's actual, actually Chrome more or less,
at least the Chrome runtime.
So this one was sent in.
I'm going to make sure I give him credit for giving a shout out.
This was sent in to us by Martin Boris.
And it's, it's pretty neat.
So it's a browser, let me switch up my screen share just for you for a sec.
Stop.
And then I'm going to add the Qt browser.
You ready?
Where is it?
There.
All right.
So look at this bad boy.
So this is the browser.
And how do I go to places?
Well, I can click on things like here's a link I can click on.
But if I want to go somewhere, I press O and it pulls up a place I can open.
Look at this.
I got my history.
Oh, that's pretty cool.
I want to go to like, I'll go to talk Python.
How do I, if I want to do a command, I hit colon and here's all my commands.
I've like my tab, I give focus and control and so on.
Over here and it's type F.
So if I want to, if I want to navigate, for example, I'm here on the talk Python page.
What if I want to go to courses, I type F and then everything, see how everything gets a letter above it.
That's pretty great.
Yeah.
L, D, D, G.
If I want to go to D, I just press D and then we're off on the talk by then training site and so on.
So I could open, I could say open and I could search for pytest and I'll pull up my tests and so on.
And I can do a new tab.
I got to remember how to do that.
Yeah.
We're going to say tab clone.
And I come over here.
I know there's a bunch of good commands that I'm not following.
Like very much like if I was actually using Vim.
Yeah.
If I could search for pytest and book, I could come over here, right?
Like that.
And I can hit, is it control or Windows control?
Ooh, that's a good book.
Yeah, I heard that's a good book.
So I can like cycle through my tabs, see how minimal my tabs are and stuff right there.
Oh yeah.
It's on the bottom.
It's got all these little commands.
So anyway, and I can type colon Q.
Boom, we're out.
Nice.
What do you think of this?
Yeah.
What do you think of that?
I actually love the cute browser.
I haven't used it much, but I definitely know about it because the Florian Bruin who started
the browser, he's a pytest contributor and also one of the technical reviewers for the
pytest book.
So really cool guy.
But I love the idea of being able to just use a browser with a keyboard and not have to touch
the mouse at all.
That's like, that's next level.
It's pretty neat.
Yeah.
Let's see.
Out in the audience, Kim Van Wijk.
Hey, Kim.
Says, I resigned myself to using a mouse more than I want to.
Cute browser may be the way to go.
Thanks to the tip.
Awesome.
Yeah.
And Alvaro says, are those VS Code shortcuts?
I suppose only if you have the Vim binding set in VS Code.
But then I sort of, yes.
Well, of course you do.
Why wouldn't you?
What are you, a monster?
Can you even do Emacs bindings?
I don't know.
You could do non-Vim bindings.
Yeah.
Right.
But then people would look down on you.
Right, Brian?
But I don't do Vim stuff in mine.
I know that you probably do, though.
Yeah.
I use Vim everywhere, especially in VS Code.
So, nice.
Nice.
But I think people should check it out.
It's kind of a cool project.
And also, it helped push forward some of the, some pytest things.
We got some new features because of this.
It's cool.
Yeah.
Oh, that's great.
I installed it with Homebrew.
So, that was easy to install.
You can install it with apt on Linux.
I'm not sure about Windows.
But they've got a quick start guide.
So, you can follow along to see like, you know, what, what you might want to do.
Like, it's, it's not super obvious.
No, that cheat sheet is, I have an iChart key binding.
It's a bit of an iChart.
I suspect you can zoom it.
There you go.
It's still small.
But, yeah.
I do like the navigation, pressing like F and then just a letter to navigate instead of using your mouse to follow the links.
That's pretty cool.
Do you remember those, like, those templates that people used to have, like, back in the day for, like, in, like, Office tools where they would overlay.
You would put them, it was actually an overlay on your keyboard.
Yeah.
It would go over the, like, the function keys to, so that you could remember which functions did what during what application.
And if you switch to Word, you put a different, or probably WordPerfect at the time, you put a different template over it.
And, yeah.
Yeah.
I'm going to use Lotus 1, 2, 3.
Give me the function key overlay.
Yeah.
Okay.
I'm just showing.
Yeah, it's a little like that.
It is.
Showing how old I am.
So, let's talk about something new.
I'm sure they still teach that in college.
Yeah.
No, they don't.
Although, in college, I had to teach.
I was a TA for, like, a computers 101 class during grad school.
And links was one of the things we had to teach.
And I was like, nobody's going to use this.
Yeah.
But it was part of the curriculum.
Yeah.
That's awesome.
Anyway.
So, let's switch to something new, like, async.
So, I think we've talked about court probably several times.
And court is a, it's like Flask, but it's async.
It actually is the, does the entire, it supports the Flask API, or I think, and sort of looks
the same, but it's async instead.
But there's a problem.
It's super close.
You can basically, everywhere you have the word Flask, if you replace it with the word
court, it more or less works.
So, like, import lowercase flask.
You import lowercase court.
If you create an object, capital F Flask, you use capital court, and then it lets you do async,
basically.
Cool.
But there's an ecosystem around both of them now.
So, there are extensions to Flask.
Some of them work on court.
There's extensions to court.
I don't know if any of those work on Flask.
But the people behind both of them kind of are supportive of the whole thing.
And so, court is actually now part of the pallets project, is the big news.
And pallets is the project that includes Flask and a whole bunch of other stuff.
But because of this, it will help maybe the maintainers kind of work together a little bit
better and smoother to iron this out.
So, the big difference, of course, is that Flask has a whiskey server behind it.
Server is the right word?
And court is ASCII.
So, asynchronous.
But the, it's, so this is cool.
Well, why do we care a little bit?
Is that it used to be that really you had to do async.
If you wanted async, you had to do court.
But now Flask, as a Flask 2.0, you do have some async capabilities, but it's still using
a single-threaded server.
So, there are some limitations.
So, kind of interesting to read about this.
There is an async and await.
page on the Flask website that talks about really what the trade-offs are, what the performance
and the background tasks and how to do that within, without shifting to court.
But then also talks about, at some point, you might want to just switch to court instead.
Along this line is, I was thinking about this partly while I was looking at this other article
from Steve Pate that called, should you use async on your next Python web application?
Which I was, I wanted to bring this up because I was curious about what your take on it was.
The first part is, it's a really nice history.
It talks about the history of web server interfaces with Python, with the timelines and Whiskey and ASCII.
And then how ASCII.io came into play and how UVicorn is popular and Unicorn.
I don't know how to say that.
I'm pretty sure it's Gunicorn because it's short for green unicorn.
Okay.
So the last bit should still be pronounced unicorn.
So I'm going to go with G.
Okay.
And then there's Hypercorn, which is the asynchronous web server that's similar.
Anyway, so it talks about this, but then at the end, the conclusion, it talks about all the different frameworks.
The conclusion is, most people don't need async on their web server.
And I was curious what your reaction to this conclusion is.
I have some thoughts, but let me pull up some first.
Okay.
So here's my thought.
It depends.
It depends on how far you need to push it towards the edge.
I was surprised how far you can get without async in terms of concurrency.
So I recently did an in-person class.
Imagine that over Zoom, but live in person.
I actually have some more to say about that.
It's kind of related.
But anyway, I just did a course with some folks who are doing FastAPI.
And they said, look, this async stuff that we're doing adds some complexity to the way that we got our right code.
We're not sure whether or not there's a trade-off.
So what we did is we actually ended up writing a FastAPI app with using the sync and the async version of SQLAlchemy, and then using async and an async version of FastAPI endpoints.
Okay.
With the database that we had as the backend, and the database was not the limiting factor because it was at like 10% CPU while this was happening.
It was just chilling.
Yeah.
But with a real database, Postgres as the backend, what we found was we could do, I can remember this right.
Oh boy.
I'll give you, I can certainly give you the relative bit.
So with the synchronous version, we got way more scalability than we thought.
So it was like 75% performance of the async version.
Okay.
So that seems way higher because the database had, like most of the things we were doing is just waiting on the database.
But because we were running in G Unicorn with UVicorn workers, I was really just in G Unicorn with threads, you know, Python doesn't do threading well, except when it's listening on a network socket or doing a few other things that will release the GIL.
And guess what?
When you're talking to the database, you're listening to a network socket.
So there's all these points that naturally free up the threading.
And actually got us like 75% of the way there, but we still got 25 to 30% more performance out of the async version.
And it was like, I think it was five worker processes running on my eight core machine, talking to Postgres.
And we were getting something like, you know, like 2000 requests per second versus 1500 a second, or maybe it was 1000 and 1500, something like that was a lot of requests per second.
But we did get more performance out of the async version.
So my depends is like that last 25, are you like that close to your performance?
I would say 95% of the web apps are not maxed, right?
They're not maxed out with like multiple servers trying to deal with it.
95% of servers are doing important work, but they're probably still have a lot of capacity left.
So it's like, it depends.
Are they like, do you need that last 25% or does it not really matter?
Yeah.
And also like, those are my thoughts.
What's the load like on your typical, I mean, what are your levels anyway?
Right.
So if you, if you already have, like for instance, if you already have an application running, you can measure it and see, see what your load is looking like.
And how many people you have.
And then if you, if you think, oh, I might, I might increase my, what if we double?
Then you can kind of guess what your load is going to look like if you double and stuff.
So interesting.
Yeah.
I recommend people check out this locus thing because it's so easy to say a typical user clicks on the page between five and 15 seconds.
They might go log in.
They might go log in some of the time.
They might go hit the homepage.
They might hit the about.
And then you can say, I would like to see how many users I can take.
And if, if you're 10 X, what you need, you know, it doesn't matter whether you use async or not, but there is a performance benefit.
It's just not as massive as it might sound.
The, the other bit that I want to like point out is the, the one, one statement that like depends on what you're using.
Also like I can't find the, the bit here, but it, he was talking about how one application he had, he was thinking about, oh, I might, I might do a async except for he was using a payment gateway that didn't have an async version.
So he had to use a synchronous for that.
And since synchronous somewhere you kind of have, is this true?
If it's synchronous somewhere, you have to be synchronous everywhere or that not really true.
You know, if, sorry, say that if it's sync, async, it's async everywhere or sync.
It's sync everywhere.
Either one is either one of those true.
If I, like, if I have a, if I've got an application and, and I do need to hit a gateway that's synchronous, do I need to, if I isolate it, I guess I can probably do asynchronous and hide it that way.
But yeah, I mean, you're, you just don't get as good a scalability there and you kind of block up the processing.
If you do the sync for the async one, you can do like a wrapper where you say like, we're going to do some async work, but I'm just going to call that and block.
Because all the other stuff above it doesn't want to deal with being async.
Yeah.
So it's easier to go from sync to async to like have part of it be async.
The other way around is a little more tricky.
It can mess it up a bit.
Okay, cool.
Yeah.
Nice.
Interesting conversation.
Thanks a lot.
Absolutely.
It sure is.
Is that it?
Is that all of our items?
Are we?
I think that all of our items?
I think so.
Yeah.
What?
You got any extras for us?
I don't.
No.
Okay.
I have some.
Let me pull them up here.
Locus.
Look, let me tell you about it now.
It's great.
All right.
No, I have three things I want to tell people about.
Number one is I did a talk at Python Web Conference, the HTMX and Flask one that I've done in some
other places, but that was a fun talk, like a 45 minute Flask plus HTMX goodness there.
And so that video, along with all the other Python Web Conf 2022 talks are now on YouTube.
So people can check that out.
Cool.
Did you know that the Python Web Conference had five days and I think it was like four or five tracks all day.
So there are a ton of videos.
There's like 150 videos or something on there.
I mean, look at this scroll bar here.
It's probably going to like page as I get to the bottom too.
Yep.
Look at that.
So there was a lot of talks that people can come check out if they're interested in that.
That's pretty cool.
One of them being HTMX that I did.
Yeah.
I want to watch your talk.
You've given that a couple of times, haven't you?
Yeah.
I've given it a couple of times.
Basically, the way it worked is like when I was working on that course and really like playing with those ideas,
I submitted to a bunch of conferences and those conferences were either a year out or they were like a month out or something.
Right.
That's how that ended up so spread out.
The other one is I mentioned the browser.
That was fun.
But how about the browser-asaurus?
Okay.
This is a macOS only tool, but there's probably something like it for the others.
So here's the thing.
Suppose I'm in Typeora, which is a Markdown editor, or I'm in a PowerPoint and it's got a link and I click it.
By default, it opens in the default browser.
But depending on what you're doing, you might want it to be like, oh, sometimes I wanted to open in Vivaldi,
but other times I wanted to open in like say the cute browser or Orion or some odd thing like that.
Right.
So the idea with this thing is that you click a link and when it opens up, instead of opening in the default browser,
the browser-asaurus is the default.
And then you have keyboard shortcuts like F for Firefox, E for Edge, S for Safari.
And you say, well, which one do you want to open in right now?
And it basically just delegates to the different browsers you register it with.
So you can hit T for Tor or F for Firefox when you click a link.
That's kind of cool, right?
That is pretty cool.
Yeah.
I haven't been convinced that I would use that or not, but I do appreciate it.
And I feel like maybe someone sent that in and if they did, I'd really appreciate it.
But yeah, I don't have any notes I sent it in.
So anyway, that's pretty cool.
If you find yourself, you know, copying, going to different browsers a lot and you're on Mac,
I know that's like a small, a rapidly decreasing Venn diagram.
But if you're in that space, this might be a cool option for you.
Yeah.
What is it written with anyway?
TypeScript mostly.
Okay.
So speaking of browsers, I just found this because I was like, is links dead?
Can I use something like links now?
And there's a browser called Broush, which is a text-based browser.
So that's still a thing.
Cool.
I had to try this out.
Oh my gosh.
I love it that it kind of has text, but it like 8-bit pixelated.
Yeah.
It takes the images and makes them terrible.
It takes the images and makes them look like what you would get.
Yeah.
So I'll have to give this a try.
Yeah.
And you've run it in Docker.
Of course you do.
All right.
Pretty cool.
All right.
Oh, let's.
Yeah.
Go ahead.
One more before we get to our joke.
Okay.
The other one is I talked about doing a live class.
So I actually have an announcement for a live class that I'm doing.
So obviously people know I have a bunch of online courses and of course I'm going to keep, I'm already working on the next one of those and we've got a bunch coming there.
But I want to try some experiments.
Something where people can attend a class in person with other people, right?
If they sort of help each other along.
And I've tried this before, this cohort thing, but I think I've got a better platform, a better way to do it.
So over at, this link I'm going to put in the show notes, I'm doing a FastAPI and MongoDB.
So basically FastAPI, Pydantic, Beanie and MongoDB course.
That is going to be a four day, six day course over two weeks.
And it has a couple hours a day.
And.
Oh, wow.
We'd have a bunch of people there working together on some fun stuff.
And I'll be live teaching every session.
So it's going to be like a live course as if you were attending it in person, just remotely.
Because it's 2022 and it's not a, I guess it's not post post COVID all the way.
But anyway, it's, it's got a really cool set of topics that we cover.
It talks about async.
It talks about Mongo, Beanie, Pydantic, FastAPI, of course.
We even use Locus at the end to test it out.
I'm, I think this would be a fun.
This looks great.
Cool.
Yeah.
Awesome.
I think it'll be fun too.
I think it'll be neat to have this experience with people.
And I've tried this before, but all my prior attempts were, they were good, I think,
but they were like, yeah, take the online course.
And then we'll do like a community type thing.
This is like a live course that I'm just teaching one off for that group of people that sign up.
So we'll see how that goes.
If it goes really well and people love it, then I'll do more of these.
If not, then maybe less of them.
I don't know.
We'll see how it goes.
But this is happening August 8th to 19th.
So it has a real date because it has, you know, a real live aspect to it.
Nice.
Cool.
All right.
Cool.
And Mario on the on says, that's my stack right there.
Oh, yeah.
That's a good stack, right?
There's some really good stuff to talk about there.
I've been using Beanie and FastAPI for stuff.
And obviously, Monk.
Yeah.
Speaking of courses, one question out there.
How's the pytest course going?
It is going.
It's creeping forward, but life has gotten in the way.
And we'll get it out.
It's awesome that you're having.
Yeah.
It's awesome that you're working on that.
It takes a while to create a course, doesn't it?
Longer than I thought.
I'm like, man, I already wrote the book.
I can totally pop a course out in a couple of days.
Yes, of course.
Would you say that as a junior developer, you might think about this differently than after
somebody's been doing it for a while?
Yeah.
This cracked me up.
So I can't remember who shared this.
It's a great joke you got here.
Somebody shared it on Twitter.
Sorry, I can't.
I don't know who.
But OK, so in a job interview, you've got somebody gets asked, where do you see yourself
in five years?
And the junior developer in this interview question shows a picture of the black hoodie with multiple
screens and light up keyboard.
Just I'm in Hackersome.
Five screens.
Yeah.
Totally coding.
Yeah.
Senior developer, where do you see yourself in five years?
On a farm.
Pumpkin farming with cows and apples.
And you know what?
I'm about done.
I love it.
Yeah.
My personal thoughts are, why not both?
This is just a view of the inside his office and then outside.
Working from home, man.
That's right.
Working from home.
Yeah.
All right.
I have maybe the one that preceded that, the one that, or maybe is in between these two
that might precipitate the second.
Okay.
All right.
So this is a tweet from Programming Humor.
It's a strange language, that JS.
JavaScript is such a strange language.
Nobody can understand it.
But if they manage to, then they create their own framework.
Yes.
Everyone's got their JavaScript front-end framework or something like that.
Yeah.
And you know you've made it when the framework you've invented starts showing up on job requirements.
That's right.
With four years experience.
We're only two years old.
Exactly.
Yeah.
Well, good episode, Michael.
Thanks for showing up again.
You bet.
Fun as always.
Thanks, everybody.
We'll see you later.
In the slack and everything.
Bye.