Hey, Brian.
Hey.
I see that you've come wielding a staff of mighty power.
I was cleaning my office and I found the Python staff.
So I'm like, I'm working this out for the show.
Yeah, that was when we used to go to conferences.
Do you remember that?
Like people, they'd all get together.
I think they might be making a comeback.
I think so.
I think I might be attending some conferences in the future.
Awesome.
So am I.
I'm looking forward to it.
Before we get to our topics,
also want to say thank you to a new sponsor this week.
Not totally new, but new for recent times.
Compiler, the podcast from Red Hat.
So awesome to have the support from Red Hat.
We're going to be telling you more about them later.
But Brian, let's just mix it up.
Let's make it different.
This is episode 308, recorded November 1st, 2022.
I'm Michael Kennedy.
And I'm Brian Okken.
Let's do it.
I did want to talk about PyCon.
Yeah, so PyCon is coming up.
So when is it?
I wrote this down even so I could remember.
It's April 19th to the 23rd.
But we bring up PyCon US because the site just launched recently.
So pretty excited about that.
Linking to a blog post about the site launch and the call for proposals.
So again, it's going to be, let's just hop over to the big one.
It's kind of a cool look to it now.
It's an homage to some of the old ones because there's, what's the 20th anniversary special?
So it's some of the old pictures.
So you can try to see.
Oh, I see.
So it's a bunch of tiles.
And the different tiles are actually like the hero image or whatever.
Yeah.
From that year.
Or bits of it or something.
Yeah.
It looks cool.
So PyCon US is going to be April 19th to the 23rd.
Well, that's when the talks are.
It's longer.
So there's tutorials ahead of time.
And then there's hack days or whatever you call those afterwards.
So if you can stay longer, awesome.
But the talk part is the 19th through the 23rd.
Salt Lake City.
The site looks great.
The call for proposals is up.
And that's really kind of what I wanted to highlight is so people start thinking about your talks.
And of course, yeah, we've got some more information about talks coming up later in the show.
But the deadlines, what are the deadlines?
So we've got the CFP just opened, just opened the 18th.
And then it's through December 9th.
So, but don't wait until December.
Get those in early.
So anyway.
Yeah, excellent.
I think I'm going to submit some because I kind of think I want to go to PyCon this year.
I didn't go last year.
Have you thought about it yet, Michael?
Yeah, I've definitely thought about it.
I'm very much considering going.
You know, for me, it's like, is Talk Python going to get a booth and have like a bunch of presence there?
In which case, going to the conference means hanging out at the booth for three days, which is kind of awesome.
But also, it's like not exactly a conference.
Maybe I'll go low key and submit a talk and then just like cruise around the hall.
I haven't decided.
Right.
Do a bunch of podcast recording live there.
Right.
So there's there's tradeoffs to both, obviously.
So I got to got to think about what I might want to do.
Yeah, I think I'm going to submit some talks.
One of the things I wanted to bring up with submitting talks is to not to do it because it's a good experience to submit a talk.
Even if you don't get the talk, it's the process of going through that submittal process.
I think it's it's it's a growing growth experience, even if even if it gets rejected.
And don't feel bad because tons of people submit talks and they can't accept all of them, obviously.
So, yeah.
Yeah.
Absolutely.
Cool.
Yeah.
That'd be exciting.
I actually want to do a bit of bookkeeping before we move on.
Yeah, it's a good idea.
For people who typically attend our live stream recording, which we really appreciate that.
That's awesome.
We see a bunch of familiar faces in the chat already out here and we do that live on YouTube and then we polish it up and send it out to the world over the audio channels.
So I think you can get a lot out of the video version.
That said, we're moving the video version, right?
We are.
And it's my fault.
So I've got a periodic meeting that happens in my day job and it happens at noon on Tuesdays.
And that's when we usually used to record.
So we're just shifting it a little bit.
So we're going to do 11 a.m. on Tuesdays.
Exactly.
It's just an hour earlier on Tuesdays.
So I want to encourage people to go to Python Bytes.fm slash YouTube and it'll take you over to our channel.
If you subscribe and get notified, you'll just get a pop up when we're streaming live.
And if you've got time, you can drop it.
You don't have to plan too much about it.
So anyway, encourage people to be part of the YouTube experience here because we put a lot of stuff on the screen and it makes it even a little bit cooler, I think.
And while we're bookkeeping and it's 11, if you can make it 11 a.m. on Tuesdays, maybe you want to be on the show.
So reach out if you'd like to be a guest host.
We still do those.
Yeah, exactly.
I do.
I wonder if I've got anything to talk about.
Let's see.
How about NEIO?
NEIO is a framework that lets you build async things.
And when you first hear about it, it looks like it's kind of for making network libraries.
Like if you were making a low-level network app and you wanted it to be concurrent and asynchronous, like, well, you could use NEIO, which would be cool.
And it has the ability to be, how did Alex, the creator of it, put it?
Something like a framework that goes above the asyncio frameworks.
So it doesn't, like, if you think of Trio or Curio, those are replacements for asyncio.
Whereas NEIO will run on top and integrate with asyncio, or it will run on top of and integrate with Trio.
So you can kind of add it into whatever you're doing, which I think is pretty sweet.
But I think its little elevator pitch or whatever here sells it a bit short.
So I just wanted to talk about some awesome building blocks that people can use from NEIO that I think would make it really fun.
All right, so one of the 3.11 features actually is this idea of task groups.
And they also have this concept of task groups over, they had it originally in Trio, and then it comes over here about these groups.
And what you can do is you can basically create a task group, do a bunch of work on them, and then when it exits that width block, it's all finished.
So if you're not ready to go to 3.11, but you want to have task groups, here's one way to get it.
So that's one thing that's kind of cool.
It supports cancellation and timeout, which is important, especially as a group of related things.
But one of the things I want to touch on here that's pretty cool is the synchronization primitives.
Remember a few weeks ago, Guido wrote that article about people at a table and semaphores and stuff?
Yeah.
Yeah, so...
That's the thing.
Yeah, exactly.
So there's a couple of those types of primitives here that are really neat.
So they've got events, which allow you to just run up to a point and wait until some other asyncio thing comes along and says, now go.
And these are similar to the events that are built into the standard library, but they're not reentrant.
And they have a little bit...
They claim to have a better way of presenting a race condition, a little bit closer to Trio.
So there's those.
And one of the ones over here that's cool is capacity limiters.
I think I did talk about this one before.
So you can go over here and just say, I want to only do...
In this case, the example says, create a capacity limiter two.
I only want to do two things at a time.
But yeah.
Then, let's see.
Another one is this working with threads.
Pretty awesome.
So you can...
Given some function that is just a regular function, you can turn it into async, but actually have it execute on a background thread with two thread.
Wow.
Give it that.
And then you can await it just like other things that mix into your asyncio world.
You can also do it in reverse.
If you're over in a thread and you need to run it on the async event loop, you can also push it.
You can say from thread and to thread.
The two thread is the...
I believe the one that...
Now the from thread will push it back.
Back to the async event loop, which is cool.
Let's see.
Also, subprocesses are pretty awesome.
So you can do...
Like you have this idea of running your code in a thread because it's not async, but you want it to be kind of concurrent and mix it in.
You can do the same thing with subprocess.
And this is super cool.
So you can say just run process and then it becomes something that's a task that you can await along with your other things.
Nice.
Which is sweet.
And then you can even go as far as to open the process and then like asynchronously work with it.
So here's an example of where you open some process and then you create a text receive stream from its standard out and you just cruise around and read from it while it's running.
Awaiting all the time.
Wow.
That's neat, right?
Yeah.
So it just grabs it while it's printing out?
Yeah.
So basically what I think it does is it creates a stream that you can await and then it's just listening for process messages to come through.
And then it, you know, like the task kind of partially completes, right?
Because it's an async for loop.
So you asynchronously wait for an item to come in and then it kicks it one time around the loop and then it waits again.
And yeah, it's pretty cool how it juggles that.
Yeah.
And then finally here, the file support.
So you can now, instead of saying open, you just say any IO dot open file, but you can async await it.
You know, it's crazy.
Async with await.
There's a lot of crazy stuff happening.
But then you can await the reads and so on.
Now there's not actual asynchronous behavior in Python.
So how does it manage this?
Basically, it creates a wrapper that uses threads that does the file IO.
And then it just sort of coordinates the communication of the IO back and forth on the threads.
As soon as it comes back from IO, which should release the GIL because it's off doing its own thing in the OS.
So it should be pretty good anyway.
It looks like maybe I haven't used this, but it looks like it makes things like subprocesses and threads and normal async and await all kind of look the same.
Yeah, exactly.
It's like a unifying API across the different scenarios, which is really cool.
Once you kind of wrap it, you're like, oh, there's just a bunch of tasks.
I just call await on them.
Good to go.
Nice.
And then possibly it wouldn't be too much if you had to change your mind and have something be a subprocess or a thread.
Instead, it might not wreak havoc on your design too much.
Yeah, exactly.
You almost don't even have to worry about it.
As long as the parameters can be passed, right?
They've got to be pick a little bowl to go across the wire there.
But as long as they can be passed to the process as well as to a thread, then you just get a task back that talks to you.
It's cool.
I'll definitely take a look at this.
Just before I move off of this, I just want to say also I interviewed Alex Grunholm over on Talk Python.
When was that?
September.
Actually released it in October, though.
So effectively October or a couple weeks ago.
And people can check that out if they want to dive deep into it and hear that story.
Anyway, I feel like, yeah, yeah.
Thanks.
I do just feel like any I.O. sells itself a bit short.
Say, no, it's like a network library.
Like, oh, I don't need a network library.
But no, there's like all these little cool building blocks in there.
Pretty cool.
Have you used it?
Is it pretty nice to use?
I've not used it.
Okay.
I'm still working on getting my interesting projects more async capable, you know, before, like, for example, getting some of the web stuff in the front end can be more async and so on.
Then I can start bringing these fun ideas in more on real projects.
Back to your topic real quick.
Brandon and Audien says, if one was looking at submitting to PyCon, what's the difference between a tutorial versus a talk?
Time?
What else, Brian?
Hands on exercises?
Right.
So, tutorials are, what, like three hours or something?
I can't remember how long they are.
And, okay, so they're three hours.
They're also at a different time.
So, they're like not on the same day.
The day before or something.
I mean, I think they're like two or three days before.
I can't remember how many days before they run them.
I should have looked this up.
Yeah.
But they're before the conference.
So, you have to, you have more hotel tickets to get, for instance.
But since it's three hours and a talk is what?
Like 25 minutes or something?
25 minutes, yeah.
Half hour?
Since there are more work to prepare for a tutorial, you get paid for them.
You get a little stipend.
But also, people have to pay to talk, go to the tutorial.
So, you know.
But I think there are cool things.
I know a handful of the people we know do like to do tutorials if they can.
Yeah.
I think it's also a lot more guiding people through hands-on coding than it is, I'm here
to like present.
Yeah.
It's not a three hour.
It shouldn't be a three hour presentation.
It's like, we're going to present something and then have exercises for people to work on.
People bring their laptops in and stuff like that.
Yeah.
But then there's also, one of the things that people forget about is posters.
Posters are also pretty cool.
On the last day of the, on Sunday, I think it's on Sunday, they have the posters up.
The posters and the job fair, right?
Yeah, I think so.
The job fair and the posters at the same time.
And it really literally is a poster.
So that if you get one of the poster spots, you get a section where you get to have your
poster up and you can describe whatever you want on there.
Hopefully it's fairly entertaining to look at and read.
And then you get to hang out.
So let's say you've got a project you want to talk to people about.
It's not really a presentation.
You have your poster up and you just hang out there and then people come around and ask you
questions.
Yeah.
That's pretty neat.
Absolutely.
Yeah.
If you want to have a chance to just have a conversation around something you're working
on, but not go all in on a talk.
I tried to submit a keynote once.
Turns out you can't do it.
Oh, are they, do they ask people or something?
Keynotes are invite only, Michael.
You can't submit a keynote.
I'm like, well, I'm submitting one.
You can turn it down if you want.
They did.
It's all right.
Okay.
Now, I want to tell you about one more thing.
Awesome.
One awesome thing before we move on, Brian.
I'll tell you about compiler podcasts from Red Hat.
So super cool to have Red Hat come along and supporting the show.
And, you know, like pretty much everyone listening, you and I were fans of podcasts.
And so it's awesome to have this compiler from Red Hat supporting the show.
Really, really good show that they have themselves.
It's very highly edited and polished.
So that's excellent.
If you want to stay on top of tech without dedicating tons of time to it, you can listen
to compiler.
They present different perspectives and topics and insights from the tech industry, free from
jargon and judgment.
They want to discover where technology is headed beyond the headlines and create a place for
new IT professionals to learn, grow and thrive.
They help people break through barriers and challenges, turning code into community at all
the levels of the enterprise.
One recent interesting episode is the one about the great stack debate.
I love, love, love talking about, talking to people about their architecture and the trade
ops and choices that they made and what the costs and challenges and, you know, it smiled
and frowns that result from that.
So you can definitely check out the great stack debate.
That's a fun one.
They answer the question of whether software is like an onion or like it's lasagna or whether
it's some other more complicated dish.
So you can check that.
That's a lot of fun.
And it's actually first.
Yeah, go ahead.
Looks like the most recent one is about testing, too.
I better check that out.
Yeah.
You got to get in there.
They have a whole series on the compiler, the compiler series on software stacks.
And I guess testing is an important part of that.
It's awesome.
Yeah.
So learn about compiler at pythonbytes.fm/compiler.
The link is in your podcast player show notes.
I know you could just search for compiler and sign up, but follow the link and click on your podcast player there and subscribe.
That way it would really help us let them know that you heard about them from us.
So thanks to compiler for keeping this show going strong.
All right, Brian, what's next?
Well, I was going to talk about conference talks.
So some more.
So I think everybody should try because I actually I I was terrified to do my first talk and I think it was a good experience.
So Reuven Lerner, Reuven Lerner, friend of the show and all around awesome guy, wrote an article called how to propose a winning conference talk.
So we're linking to that.
And what there's a lot of there's a lot of articles on how to do a talk.
And what I like, what I really like about this is it's short.
There's a there's a few things that he focuses on.
One of the first is like coming up with ideas and he like part of his audience is also other trainers.
So but I think that more people are trainers than you realize.
So maybe you're maybe you actually teach people like Reuven does or, you know, you have a training gig.
But you could teach mentor or lead or coach in other ways just by being the resident Python guy or girl or woman or whatever at your company.
And when people come to you and ask questions.
So one of the some of those things are to come up with a list of things to talk about.
What questions do people ask you all the time?
Those are great things to break talks about.
Maybe what knowledge, what knowledge do you think people should have that they just don't know to ask about?
Those are also great topics.
And then also, where do you see that people just don't seem to get it?
And so somehow they're not getting some concept.
They don't quite get it from whatever they've sought out.
Those are also great things.
And if and if that if you're still stumped, he says, well, check out Stack Overflow.
What kind of questions come up there all the time?
Those are those are good things to maybe give a talk about.
So, hey, I got a cheat code for people listening.
OK.
What awesome thing did you hear about on Python bytes that was like new to you?
And there's not a talk at the conference.
I'm serious.
Yeah, exactly.
Yeah.
You know, rewind a handful of episodes and go through and go, that sounds interesting.
And, you know, spend a few hours researching it and come up with a talk.
Why not?
Right.
It's interesting to me.
I want to learn it.
And then I could present it.
You know, you could test drive these things.
So it's smaller regional conferences.
You could test drive them at meetups.
You could test drive them as like a YouTube video that you post somewhere or even a blog
post you write.
Like there's a bunch of let me take a shot at it and then build some confidence and then
submit it to PyCon US or Europe or wherever.
Yeah.
He goes on to talk about using an outline.
And even if you don't go for a talk, maybe I don't remember if I think PyCon US does ask
for this, but some don't.
But even if it's not asked for, come up with an outline with times.
And that part freaked me out.
I'm like, how do I do that?
But his example is fairly not scary.
It's kind of the bullet points of the sort of stuff you're going to talk about.
And how long you intend to talk about it.
And this is actually really important.
I, when I, when I finally embraced this and went, I got to think about this.
And I kind of do this hand in hand with this, the next step, the next step, he said, is you
don't just need an outline.
You need a summary and you kind of need a short summary and a long summary possibly.
And that's, and you should include, I can't remember where he wrote this down, but you
should include, what is it?
Um, the value that people get, what benefit they'll get from your talk and what knowledge
they'll get, what they'll have when they leave your talk and how will that help them?
And think about those.
And that while you're putting through your, your outline together too, as to where you
want to spend your time and, you know, be paying attention that you do want to have some,
some wrap up time possibly.
And you might want some introduction time.
So include that and think about those times.
And then you've got just these little tiny one or two minute, one or two or three or four
minute segments that you've got to come up with words for.
And that's actually a lot easier to deal with than thinking I got to come up with 25 minutes.
Right.
So yeah.
Like an example here, it says generate warnings, two minutes.
Could you spend two minutes talking about generating warnings?
I imagine you could.
Yeah.
And if it's important, put throw, throw some time into it.
But the, the, one of the things I wanted to highlight on this, I really liked this write
up.
He also, a couple more things.
One is submit the same talk to multiple conferences.
You can do that.
And you don't even have, it doesn't even have to be new.
You could have already submitted, presented it somewhere and it might already be on YouTube.
And you're like, really?
I can do that.
Yes, really.
You can do that.
Um, some people give talks at multiple conferences and it's fine.
You don't have to come up with a brand new talk for every conference.
Uh, the other thing is the, the list of outline, the list of topics.
My mistake, the first time I wrote, gave a talk was I did this.
I went, what are all the things I'd like to talk about?
And then I crammed them all into the, into one talk.
Um, this is not what you want to do.
You want to pick like, you know, one focused thing so that you can go at a reasonably comfortable
pace.
You don't want to be talking a hundred miles an hour.
People can't keep up with you.
There are some people I'm, I'm good.
Don't get me wrong.
There's some people that can talk really fast and pack a lot of information and they're really
good about it.
And it's still entertaining, but I think the average person would be better at trying to
go at a little slower pace.
So, yeah.
Yeah.
I totally agree about the, that, and you know, that could be your, like, you could come up
with that list of all the things you want to talk about.
And then that could be the source for two or three talks.
Yeah.
Yep.
Right.
Like, God, this is two, this is kind of like, this all stuff seems to be about fixtures.
So let's have to do a, like five things that are awesome about fixtures you didn't know.
And here's like why you should care about structuring your, I don't know, whatever.
And if they get rejected, but from every conference that you submitted to, you're still one because
you did all that, that work.
Just turn it into a, like a blog post or a, or a YouTube video or something.
Yeah, absolutely.
A bunch of good feedback from the audience.
John out there says a great place to give a talk is at the user group kind of matched
exactly the same time I said that.
So I definitely agree.
Green there.
Brandon says, give it a lunch and learn at your company.
Great idea.
Yeah.
That's a really good idea.
And casual viewer number three.
Um, does my team as a show and tell, like meeting on Fridays, a show off stuff.
People can talk about that'd be impactful.
Also a good place.
Yeah.
A lot of good ideas.
If the venue doesn't exist, you may well be able to create it.
Yeah.
And you might get, you might get promoted because of it.
Cause you're like, Oh, people will know that you're the expert in the company that they
didn't know before.
It's good.
That's right.
All right.
I want to come back to something that I know we talked about before, but a feature of it.
So we talked about Sanic when it came out, there was Sanic and Jopronto and a couple
other things.
This, I believe predates FastAPI even.
And it was one of the very first high, high performance async frameworks for Python.
Very cool.
Uh, I hadn't really been tracking it that much lately, but if you drop over by the GitHub,
uh, github.com/Sanic dash org, go to Sanic.
16,000 stars, 1,500 forks.
It's going really strong.
I, I totally did not.
I've not been tracking it well enough.
So this is, this is really fantastic.
So cool way to build asynchronous web apps and Python.
It's, it claims to be unopinionated and flexible.
It is the plastic that you build your APIs and your web apps out of as you like, rather than
being very structured in the way you put stuff together.
So if you're looking forward to that good, it's, I said, super fast.
Um, that was its original selling point and apparently used by millions of people, which
is pretty awesome.
So what I want to point out here is not Sanic exactly, but rather a new feature that was shared
with us by Felix and Felix pointed out that, Adam, one of the maintainers just added this
concept of a worker manager into the new version of Sanic.
So, if you, if you want to run background work, like I want to send an email or I want to
send, and do other, like lots of processing or computational work in the background, it's
going to block up not just a single request, but it's going to block up potentially the
whole web server, right?
You get a bunch of things that are querying tons of data or doing a bunch of computation,
then all of a sudden, or even calling other APIs, potentially that could log up the server,
especially if it can't be done asynchronously.
So they added this concept of kind of like a lightweight celery type of thing, where you can push
the work off to it and have it run in the background and manage that.
Okay.
Except for it's just an API inside of Sanic.
And it starts a sub process that hangs around and does that background work for you.
So it's like, you don't have to manage another server.
You don't have to set up celery or Redis and then some worker mechanism to process the messages
coming out of there.
You just kick the work over to this, worker manager and off it goes.
Nice.
Yeah.
That's pretty cool.
Pretty cool, huh?
Yeah.
And the way that it works is, basically you can hook into, some lifetime events.
Like you can use a decorator app dot before server start, and you can go make sure that
there's a queue that can be used for the communication across that.
And then you can handle on request.
And then, when a request comes in, you can like push work over, over to it.
Yeah.
Anyway, you can even get it to do like some cool little printout of like the status of what
the workers are up to and so on.
So anyway, pretty neat.
Uh, if you need to run asynchronous work and you're looking at a web framework, you know,
maybe check out Sanic.
It's got this, this cool feature and it's got a lot of nice async and await features as well.
Cool.
Nice.
All right.
Uh, that's it for our main items, isn't it?
I guess it is.
Yeah.
Uh, before we move off this real quick, casual viewer says FastAPI is something similar
called background task.
Okay.
Good to know.
And yeah, and you can also build those out of your, on your own, using like
multi-processing or something, but.
Or any IO.
Or any IO for sure.
One of the real challenges of all of those like roll your own things are usually what happens
is you, you farm out your web server.
So for example, on Talk Python Training, I think we have eight worker processes that are cruising
around waiting.
And like, as far as they're concerned, they are the website.
Right.
And if all those things start kicking off background work and they start starting their
own processes, it'll be like, why are there 17 worker processes cruising around?
I don't know what's going on.
So yeah, it's kind of cool to have something that's a little more structured, like that.
All right.
Uh, extras.
You said you got some extras.
Tell us about them.
Uh, well, stuck on the presentation thing.
Um, but, I ran across this, article called create presentations with, from Jupyter
notebooks.
And, I just wanted to link to it.
If you, if you're thinking about doing a presentation and you want to possibly just use your Jupyter
notebook, apparently it's built in.
I didn't know that it was just built in.
Um, so this just walks through the built-in features of how to, so you gotta, you've got
a Jupyter notebook, you walk, what you can even do some markdown.
You can do markdown Jupyter anyway, but there's ways to have both code and markdown together
with this, with IPython display markdown, which is cool.
Um, and then it, it goes through a couple more examples of things, but then there's this,
a dropdown.
You can just say view, view cell toolbar slideshow.
And then you select, you select slide for each of your, little cells and they become
slides in your presentation.
And then you can use, then you can use the built-in NB convert to convert it to,
uh, presentation.
So just got an HTML presentation right there.
So that's pretty neat.
You can say slide.
You can say it's a sub slide, a fragment.
You could skip and you could even make it notes just for like a presentation view.
That's pretty flexible for per cell in Jupyter.
That's awesome.
And then there's ways to either show it by default.
It shows the code, but you can have a hide the code apparently.
And then if you want to be able to, to, instead of doing the command line thing, if you want
to toggle back and forth while you're developing it, they're recommending using the rise
extension.
And I tried that.
I'm like, is this, is it really this easy?
And so I tried it out and sure enough, it's just, I just went through some of the examples
and it's really pretty cool.
And with rise, we've got like these examples and then you can just with rise, you can just
select this little, this little, icon here.
It looks like a graph and it just enters into slideshow mode.
Um, nice.
Then it, so what happens if you hit space in that mode?
Does it like automatically take you from one to one?
Okay, cool.
Yeah.
Very nice.
And you can, you can do the arrows back and forth and stuff.
You can, so you kind of, it doesn't look as good as the, the actual presentation at the
output, but especially if you're trying to like kind of toggle back and forth to see,
isn't like, is my, is my stuff too big?
Like right now I w I would totally alter this because it, it, it looks too, it doesn't look
good right now.
Um, but that's kind of what you do with slideshows is you sort of work, work with them until they
look good.
But anyway, so this is, something I wanted to share.
It was just this, if you want to try using Jupyter for your presentation, here's a link
kind of maybe take a look at this article.
Um, the other thing I wanted to point out as an extra is, what Python py test as
7.2 py test 7.2 released.
Uh, I don't normally like, I mean, I love, I'm personally, if I'm like ready to try every
new release that comes out, but why I'm bringing this up, is there's a couple of things that
bit us at work.
And I want to, if they might bite you, the PI library is now separated from py test.
So you don't get the PI library by default when you import, when you, you're installing
py test.
So if you are using the PI library, you just have to make that one of your own requirements.
You were cheating and not stating it as a requirement.
Cause I'd always be there.
We know.
I don't think we were, I don't think we were using it at all, but I think we may have
declared like, like py path or something like that.
Yeah.
Whatever.
Um, a couple more things, that I think is neat.
Um, a few releases ago, I added, the test paths, so that you can add a import path,
uh, to your, for where, like where your source code is.
And, for this release, they added a shell style wildcard support.
So that's pretty cool.
Um, and there's a whole bunch of cool features.
So, yeah, check out py tests if you're up for it.
Oh, one of the things, I'm really glad they deprecated nose.
I can't remember.
Can't remember where it's listed here, but they're, they're not using.
So set up this, just the keywords, set up and tear down.
You could define functions.
You were able to define functions, set up and tear down, and those were run automatically,
but those were run automatically because they were part of the nose support.
So even if you don't know what nose is, if you're using those, those are deprecated.
So stop using those.
Um, there's other ways to, to do set up and tear down with py test.
And so check that out if you're using that.
And I'm, and then the first edition of the py test book, I actually talked about set up and
tear down and luckily in the second edition, I took those out.
So yeah.
Very good.
You saw that.
Awesome.
Cool.
Uh, bit of followup on your Jupyter item here.
Henry Schreiner says, you can also use this in labs in JupyterLab, not the old notebook.
So if you want to use rise live editable presentations, that still requires the old notebook.
Same.
Okay.
So you can do use JupyterLab for presentations too.
Awesome.
Yeah.
Very cool.
And then also Brandon points out that background task from when we credited FastAPI may actually
come from starlet.
For those of you don't know, FastAPI is a layer on top of starlet.
So a lot of times what people perceive as a FastAPI feature is actually a starlet feature.
And, it also, Henry says that also now the notebooks now warn you, if you return
from a test on, sorry, now also warns you for a term from a pitest function, this would
be an error in pitest eight.
Okay.
Yeah.
Well, yeah, apparently some people were like returning true or false from their test functions
and, and wanting that to like indicate whether a test passed or failed.
Don't do that.
Didn't you just parse the print statements?
No, it's an exception.
If an exception happens, that's a failure.
So of course.
All right.
I got a few extras and we'll, we'll bust out some jokes.
These are quick.
Rich, the colorizing formatting, awesome TUI foundation is great.
Now available on PyScript.
So rich, yeah, you just, you just do rich things and just, you know, print this stuff
all out.
And guess what?
It now comes out as like colorized output and HTML, I guess.
I'm not sure, where the, the destination is going to land, but, it says rebel.
So I'm guessing, maybe, prints out in the rebel there.
Anyway, there's a bunch of notes on how to use rich in PyScript.
So if you like PyScript and you're tracking that project and you like rich, put them together.
Also, we talked about, YouTube videos and you could get a, make a talk.
You could just make it a video.
So I did a Python 311 in 100 seconds video that I released, yesterday, the day before.
I think it was yesterday actually.
Yeah.
Anyway, people can check that out if they've got a hundred seconds to spare and they want
to know what's cool about Python 311 and why it's neat.
Uh, that's fun.
Uh, links in the show notes there.
All right.
Ready for some jokes?
Yes.
Okay.
So here's one, it's titled laughter in Linux, but it's about windows.
So you might have to go back a ways for people to get this joke, but let's see.
I know you spent some time in windows, Brian.
Let me see what you think about this.
So here's like, sort of a karate master type of scenario.
And like the sensei says, it's time for you to look inward and start asking yourself the
big question.
What happened to the A and B drive?
Hmm.
Because it's all you see, right?
It's all you see.
It used to make that noise.
Pretty much.
If it's not a C drive, it makes noise.
It's my understanding from my history.
It, some of them make that, sort of a disky noise.
Are there like a CD seeking noise, but there's always a noise associated with a non C drive.
I know that's not always true, but it's fun.
All right.
Other one.
This one is not about OSs and discs, but rather databases and it's dating advice.
So here's a woman talking to a clearly nerdy programmer type.
And it says, what do you need for a good relationship?
The guy looks at her.
Obviously primary keys.
Primary keys.
Yeah.
So bad.
Anyway, that's what I got.
Dude from the IT crowd.
Okay.
Yeah.
I need to watch more TV to fully catch the means.
Don't I?
So, yeah.
Cool.
All right.
Well, always fun to have you here.
Definitely.
Thanks.
And thanks everybody for showing up an hour early.
I really appreciate it.
Yeah, absolutely.
Try to be the, we'll try to stick to that time for a while.
And I guess we'll let you know if we don't.
All right.
See y'all later.