Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.
This is episode 425, recorded March 24th, 2025.
I am Brian Okken.
And I'm Michael Kennedy.
We are excited to announce that this episode is brought to you by Posit Connect.
Listen to their segment later in the show.
You can also connect with us.
And if you go to our show notes and visit all the links, we're on Blue Sky and Mastodon mostly lately.
And if you'd like to actually thank you for listening, but also if you'd like to watch us live, you can check us out at pythonbytes.fm/live.
Usually Mondays at 10 a.m., but it's spring break this week, so we're doing it a little early.
And then finally, if you'd like to have all the links that we talked about delivered plus extra information delivered right to your inbox, go to pythonbytes.fm and sign up for the newsletter.
We don't spam you.
We just send you the newsletter.
What
do you got for us
today, Michael?
I want to kick off with a Twitter thread of all things.
And this one's pretty interesting.
So Armin Roeneker, original creator of Flask, put out a question.
And it got a lot more attention than I would imagine it justified.
And I found it so simple.
And I just found it pretty interesting.
Okay.
The question is, if you use Python, but you don't use UV, why?
You don't use it yet, why?
Right?
So I got like 215 responses, almost 1,000 likes, things like that.
So I want to just call out some of, I'm not going to go read all 215 top level.
He says, I'm going to call out some of the ones that I thought were interesting.
And just get your thoughts, Brian, as well.
So for example, someone said, I'm not going to also give attributes because there's a bunch.
take forever. So someone said, I get it replaces pip in pi e and v, but should I use it instead of
the built-in Python dash m v and v, v and v, right? Yes. Yes, you should. Yes, yes, you should also
do that. The reason I'm calling this out, the reason I'm making this a topic is there were a
lot of, I think a lot of misconceptions or a lot of people are like, what's UV? So I think those
are worth touching on. So what are the awesome things about using UV, V, E, and V instead of
Python, V, E, and V is, well, what if you don't have Python? Python, V, and V will just say error,
no Python, right? uv says, oh, well, why don't we just get you the latest version of Python? Or you
can say 3.12 or 3.11 or whatever version you want, or a specific minor version, right? Or build version,
right? 3.13.1 instead of 3.13.2, whatever, right? So it frees you from even having to worry about
having Python set up. I got two new computers, Brian, two new computers. I got a new laptop and
a new Mac mini, and I have not installed Python on it. And I'm actually was a little bit bugged
when something I had to brew install installed Python. I'm like, darn it, you're messing up my
flow, right? I don't want any Python in here other than virtual environments. And I want those to be
managed by uv. And the thing is, it's two seconds. Like with Pi, E, and V, what it does is it
downloads and it builds locally, which if you don't have it can take 10 minutes or more. With UV,
it takes two seconds, right? It's a thing of beauty.
Well, I just ran into the build,
a problem with the build recently, because if the, there's issues, especially on Windows,
when if you've got your dependencies mucked up somehow, it can cause you to have to recompile
some stuff and or try to recompile some stuff and and then you have to make sure they have the right
like compiler libraries on your computer and stuff like that so that's a mess.
Someone says but I need Python
installed to make
Python programs. I don't know yes but
oh it's the previous comment. But I mean it is installing it using uv to install like it isn't
installing it like you normally think but behind the scenes uv is putting it on your computer.
This
is an interesting one. I want to hear your thoughts on this. I'm anti this only because of my workflow, not against the person who made the comment. Because I don't use it because it places the VE and V folder inside of your project. And I can't run executables from there due to corporate policy. Many such use cases. No idea why Astral doesn't address this with more urgency. Someone responded, that sounds like a bad corporate policy.
Also, it does. You can configure it to do that.
Yeah, exactly. There's an environment variable you can set, have it, put it in somewhere else.
Now, one of the things that made me never, ever adopt Conda is if you would go and create a Conda environment for a data science project, it puts it into some hidden folder, centralized hidden folder inside of your profile instead of inside your project.
So I would go to a project and I'm like, did I, you know, a couple of months later and be like, did I ever make a virtual environment for this? Maybe.
But then you got to say,
Conda activate and name the virtual environment.
I'm like, what did I call it?
You know what I mean?
They're like, oh, drives me crazy.
And with it being inside the project folder,
you can look, go, yep, there's a virtual environment there.
I'm good to go.
Same reason that I don't like calling mine.vnv.
I just leave it without the dot
because I can quickly see in the finder
or a regular LS or whatever that,
hey, look, it does have a virtual environment.
All right.
I'm too lazy to switch from Py, Env, and Pip.
It seems like a U problem.
There's lazy, like, I'm not going to walk two miles to the store.
And then there's, I can't be bothered to put the word uv space pip instead of pip in my command.
Well, and like, I'm lazy.
That's why I am using uv because it speeds up everything and I can get on with my day faster.
Yeah.
Matthew Rocklin of Dask and Coiled had a really interesting comment once on Talk Python that basically like,
So much in programming happens because we're leveraging the natural inclination for programmers to be lazy.
Set it up so they can do this, so they have to do less work, and we'll do it.
All right.
I'll keep going quicker now.
Trust issues.
What if they do a bait and switch, right?
It's VC-backed.
What if they go, oh, all of a sudden?
Two comments there.
One, it's open source, and I'm sure a lot of people have forked it.
Two, although there are still some potential issues,
somebody's got to run the Python Build standalone for some of the features, but there's that.
And they've already said that they won't, right?
Charlie Marsh said, like, our business model does not hinge upon charging for uv.
It's kind of an open core model.
Okay, but Google used to say, don't be evil.
So, yeah.
Yeah, but Brian, I totally hear you.
But did you look, when they said it, like, around their back, they had their fingers crossed.
Look, I'm just telling you, you got to double check these things.
No, I'm just kidding.
I know they did.
Actually, yeah, when VCs get involved and it's all well and good when there's lots of money and things get tight, then it could potentially.
Well, and also we'll
switch to something else then.
We'll switch to uv fairly quickly if it becomes bad.
We'll switch.
Yeah, we'll switch to VU.
So I have a reason,
but when you run out of good reasons.
All right.
Another one, masochism.
I haven't switched yet because I'm masochistic.
Another one.
Many times I've tried similar tools and always come back to pip and pip-tools, aka pip compile.
Those, they just work.
I don't want something cool.
I know, but adding the word uv in front of each of these commands, like uv pip compile,
UV pip install, it's not a huge risk to roll that back.
Yeah, and we've tried the other ones also, and they were not as fun.
Exactly.
I tried this week and was expecting uv install requests instead of uv add.
And I brought this one up.
I switched back to pip envy.
I thought that was interesting because there's sort of two workflows with uv.
One says, treat it like poetry or hatch and let it manage your project.
And that's the uv add style, right?
It manages the lock file and so on.
They were expecting uv install requests.
If they typed uv pip install requests, they would have been carrying on with the regular workflow.
And I do think it's worth shouting out that there's like two unrelated workflows for projects.
And one is sort of the project manager poetry hatch style.
And one is the more low level pip style.
Yeah.
Okay.
But the uv is like you can kind of flow between the styles and it all just works.
Whereas in the other one, like you kind of had to buy into it or not.
Yeah.
It's all or nothing.
Yeah.
Another one really quick.
We partially use it.
We will transition when Pindabot support is available.
See previous comment.
If you say uv pip install and uv pip compile and use a requirements.txt file compiled by UV, you've got Dependabot support.
For me, Dependabot support is a net negative.
I hate Dependabot so much.
I've tried to turn it off on some of my projects and I can't get it turned off without turning off all the security features at GitHub.
So I've just had to set up mail rules that say delete anything from Dependabot that says bump.
Bump this thing.
Because I would wake up on Monday and I'd have probably 25, 30 separate messages from Dependabot saying,
hey, guess what?
You've got an update for this.
You've got an update for that.
I'm like,
oh, Dependabot, please stop doing this.
And if they would just go, your project has 17 updates.
Okay.
That would be kind of helpful.
17 times your project has an update is not helpful.
That said, if you use uv space pip compile and require it's not TXC, you have Dependabot support.
All right.
Last thought, I'll leave it with this one from Jared Sheel.
seeing a whole lot of Stockholm syndrome in the replies to this question.
Okay.
Interesting.
A lot
of people were sort of, you know,
they were tied to the things that were not working well or they were tied to the things.
Well, this is how we do it.
And I know it sucks.
It's not better, but this is how we do it.
You know what I mean?
Yeah.
The one thing that I would like to, okay, there's a reason that you really get a lot of the benefit of UV
if you globally install it.
You do the curl install or something, right?
That is, and also using, letting it install Python for you.
With all the other Python dependencies, you can use your own custom, like a custom PyPI, like your own in-house PyPI.
With that part, the curl install and the installing the binaries, Python binaries, I don't know if you can do that.
So I think that that still might be a decent reason is because you're using a firewall in a company and that part isn't working right.
But you can still pip install uv and I have done time tests and it's still faster to use the use uv even if you pip install it.
So you
just don't get all the benefits.
Yeah, absolutely.
Awesome.
Yeah.
Anyway, you got to already have a project.
You can't start.
You got to have Python.
You got to have a V and V and then then you go from there.
Yeah.
Anyway.
Which is fine because mostly that's what you're doing with life.
You're not like constantly creating a project.
I love our audience.
Henry Schreiner.
Hey, Henry.
Just shouted out, Dependabot just added support last week for UVLock.
How about that?
Do you know how out of date that Twitter thread is?
So last week.
Well, and also a lot of the knowledgeable people probably didn't respond because it's on X.
Yeah, that's true.
Well, I mean, there's a surprising amount of interaction over there for what it is.
Okay.
Over to you.
Okay.
Let's talk about uv a little bit.
Okay.
We haven't done
that yet.
So I want to talk about this cool project from Tim Hopper.
I love Tim.
I kind of miss seeing him.
He's one of the fellows that I used to run into at conferences all the time and haven't been to conferences lately.
So hi, Tim.
Anyway, he put out the Python developer tooling handbook.
And it's an in-progress thing, but he's been working on it for a while.
Yeah, Tim Hopper, great guy.
Anyway, the Python developer tooling handbook.
And it's walking through a lot of the, basically, the new models for doing things.
There's, I don't know, it says it, I guess he does comment on a lot of these things.
UV, Poetry, Flit, Subtools, Hatch.
But I was noticing right away he's doing tutorials and how-tos and explanations
and kind of a cool, and then some references
and kind of a cool way to set up some documentation.
But like, let's say publish your first Python package
or let's do a create your first Python project.
And instead of doing a lot of the history,
he's just popping to you to the right answer.
It's UVANet.
And I mean, actually, a lot of the other init, like initializing projects, I haven't liked
before.
Even like the FLIT init, I didn't like.
But UVANet is pretty darn good.
They're doing a good job.
And anyway, so using and then adding dependencies.
And I love this, like, let's skip all the, well, you could do it nine different ways.
Just tell me the way to do it.
Or at least a way.
It's opinionated, but it's a good opinion.
And publishing your first package, talking about setting it up.
Anyway, a cool resource.
I hope to see it grow a lot.
So anyway, I like it.
It encourages people to test.
It encourages people to use TestPyPI first before they go somewhere else.
Although be careful because there's a lot of projects that don't use TestPyPI,
and they clean that one out every once in a while.
So even if a package is available
on the test PyPI, it might not be available on the big PyPI.
Yeah, yeah.
So you're like, oh, it uploaded, so that means there's no name conflict.
Like, no, no, no.
Search PyPI.
Yeah.
But one of the things I wanted to bring up also is, let's see, right at the top.
It says, this is not a book about programming Python.
Instead, the goal of this book is to help you understand the ecosystem of tools used to make Python development easier and more productive.
So it's going to grow.
I commented about some of the testing already, and he said he's going to add some stuff about testing as well.
He said the handbook is structured according to the DIA taxes framework, which, okay, didn't know anything about this.
Tutorial, how to, explanation, and reference.
So I'm not going to link to it, but there's a link here on his project about it.
And I'm going to have to read more about this.
This is interesting.
I've never heard about this.
I had not heard of it either, but it does look interesting.
Anyway, and some great information about setting up Ruff to check your code and things like that.
So I've been so excited about UVV and V and UVPIP and stuff like that that I kind of forget that I'm using Ruff all the time also.
And it's kind of bundled into there.
So
I'm
curious, while we're talking, like kind of transition to rough for a second, I was listening to that interview you did recently where you were talking about, I think you interviewed Charlie recently.
And I, there's, I like, I like how detailed rough can be.
But this is one of the things that I think I'm, I'm, rough can you can go in the PyProjectTML or there's roughTML also now.
and I kind of like, I think I might transition to using the ruff.toml or try to
because I end up having like a decent amount of tweaking the rules a little bit
and I'm not really tweaking the project.
I'm just
tweaking the linting rules.
So are you using, do you use rough and where do you put your rules?
I love rough and I'm all about the rough.toml.
Yeah, it definitely takes more than a page of small font on my screen.
Okay.
I don't want to, you know, you could reasonably have a PyProject.toml that's smaller than the ruff.toml.
So, you know, I don't want to put those together.
Yeah, and I loved Charlie's comment about the rules of even he doesn't turn them all on.
That would be silly.
So I tried it.
I tried turning all the rules on.
And there's some rules that are inconsistent.
There's like two or three rules that are conflict with other rules.
So you have to decide, you know, if you turn them all on, there's actually a built-in conflict.
because a couple of the rules are conflict.
But it gives you really great detailed information about how
to fix it.
Yeah, another benefit from using a rough TOML over pyproject.toml
is if you're using Docker or basically any continuous integration style thing
where it looks at, well, if any of the source files change,
I need to rebuild or redeploy, restart your web apps, your APIs or whatever.
you can make changes to your ruff.toml and having if you exclude that with like a docker ignore for
example okay then you rebuild it it'll say yep there's no changes right unless those changes
are like real code changes so i know it's not a huge deal but that's like a plus one in the column
of separating those things
yeah
so if you're just doing a handful of rules it might be fine in your
pyproject.toml but if you're experimenting with turning on more and more um uh rules um then uh
yeah, putting it separate.
I do, it's both surprising and cool that by default not all of them are on,
because a lot of linters in the past, they defaulted to all on,
and you'd try to use the tool and it would just like blow up with errors.
But rough does not.
It's got some good standard ones and then you have to go
turn them on.
So
anyway.
Yep.
One more piece I saw in the tool book here that it was being added with a uv ad.
I put rough into my system using uv tool install rough because just globally and then have a ruff.toml for each project to configure it.
So that way you don't have to have updates to your project or make sure you remember and install.
It's just like a globally available tool.
Yeah.
I should do that.
I don't know why I don't.
Anyway.
Well, should we talk about the wonderful people at Posit that are helping us today?
Absolutely.
Okay. This episode of Python Bytes is brought to you by the folks at Posit. Posit has made a huge
investment in the Python community lately. Known originally for RStudio, they have been building
out a suite of tools and services for Team Python. Today, I want to focus on hosting your Python-based
data science workloads. This includes dashboards, reports, plots, interactive web apps, all the way
to custom Flask and Django apps.
Their service is Posit Connect.
Posit Connect makes it easy for data scientists
to share work built with Python code.
If you have a streamlit app, dashboard,
Plotly interactive plots, a FastAPI service,
or even a Quarto report, just give Posit Connect
the code it needs to maintain the asset
and Connect automatically does the rest.
Connect will manage your APIs and serve your interactive apps.
And if desired, update your ports and dashboards
a scheduled basis. That's right. No more need to explain to the stakeholders why the dashboard or
plot stopped updating last week. You get to focus on your data science and leverage your skill set
while Connect makes you look good, keeping your code running in private. With Connect, you get a
private URL on your Connect server, ensuring that your asset is continuously available to your
shareholders. You can also control which users have access to the asset. Let Posit Connect handle
the delivery and DevOps
including you're involved
in sharing your work.
You focus on what you do best.
So if you work on a data science team,
you owe it to you and your org
to check out Posit Connect.
Visit pythonbytes.fm/connect today
and get a three-month free trial
to see if it's a good fit.
That's pythonbytes.fm/connect.
The link is in your podcast player's show notes.
Thank you to Posit for supporting Python Bytes.
Absolutely.
Thank you, Posit. That's sort of a data science theme, right, Brian? Let's go and talk about something from Adam Chains. And I know we talked about rough, but what about black? So black is still a super important, super influential thing. I imagine with black, without black, maybe rough doesn't exist.
So I want to come up, I want to point out a tool called Blacken Docs.
So if you have documentation, and in that documentation, maybe you've got some code blocks, some Python code blocks, and you would like to format them.
I don't know how well your Markdown Editor formats code, but I'll tell you what, I love my Markdown Editor, which is TypeHora.
It does not have a reformat according to rough style feature whenever I say tick, tick, tick, Python, hype and stuff, right?
This does.
And so you can run this against all sorts of different things.
So it says documentation.
But if you look at it, what it will do is it works on restructured text or it works on markdown files.
Okay.
For example, I'm working on that Python in production book from Talk Python, which is like 250 pages of markdown.
There's a crap ton of tick, tick, tick Python, something or other in there.
Oh, yeah.
I could run it against that.
It doesn't have to be documentation.
Anything that's restructured text or markdown that has Python code, you know, full size code block sections, you can just hit it with that.
Oh, cool.
That's cool, right?
Yeah.
You can also install a pre-commit hook.
It comes with one.
And then when anybody commits, it'll automatically format that.
And I think, does it do doc strings as well?
Let's see.
I believe, yeah, you can run it on Python files to reformat doc strings.
Yeah.
So doc strings and basically markdown and restructure text.
That's pretty awesome, right?
Yeah.
So
there
you go.
You can even turn it off with some comments like, no, please don't do it here.
And so on.
So just to
be clear, I mean, it's probably obvious, but it's not, it's not, it's, it's
formatting the code blocks within your Markdown files to black style.
There aren't black styles for Markdown.
Yes, exactly.
Okay.
Although that's an interesting idea as well.
I actually wouldn't mind a, something like black for Markdown because it drives me,
I, I do headings with the pound and pound, pound and, and, but Markdown allows the underscore,
the dashed line line underneath it.
And
I hate that.
Trust me.
I do too.
It's like somebody came from a structured text
and stuck it in there.
So let's make it easier to convert our restructured text.
No.
No, please don't do that.
We're here because we don't like structured text.
Don't you understand what's happening?
All right.
Well, anyway, thanks, Adam, for that.
That's a cool looking project.
Yeah.
I'm going to stick with some data science themes
a little bit longer.
so uh i want to talk about reinventing notebooks as reusable python programs have you heard of this
uh marimo marimo thing
marimo yes i just had the founder of marimo on talk python okay
and
yeah
yeah it's it's not out yet but it's been you know been recorded and available on youtube
okay
um
if this is sort of interesting i'm like oh okay somebody else is reinventing
notebooks or something. But this is pretty cool. So this is, what are we looking at here? What
we're looking at is, I'm going to pop down to some code examples, is that a notebook doesn't have to
look like a notebook anymore in like JSON form or something. It can look like Python, or at least
with the Marimo environment. And I'm not quite sure, you probably know more than I do then.
Can you just open these up into notebooks,
or do you have to do something special to get them open?
So it's a different
execution environment
than, say, in Jupyter Space Lab or Jupyter Space Notebook.
It's a different runtime.
Okay.
But they're real similar.
Okay, got it.
But I really like that it's just Python.
Well, it's not just Python code.
It's extra stuff also.
It looks like they add some decorators to make their environment understand what it is.
Like there's app.sell and at app.sell and at app.function and probably other stuff too.
But some of the benefits of this are like incredible.
So some of the benefits are that you can version with Git easier.
Well, you can do that with JSON too, but the diffs don't really make a lot of sense often.
The diffs are all over the place.
You can test with pytest.
And that one, I'm like, really?
That's been one of the problems.
Because in the past, testing is kind of an issue.
Or at least it has been a long time ago when I tried it.
Maybe they've solved it other ways.
But testing even with Doctest and some of the other stuff in there.
Embedding SQL and Markdown.
Like all the sort of stuff that you can normally do with Python, you can now still do with these.
And that's just kind of cool.
I wanted to check this out and try it out.
This is available for everybody to run, right?
Yeah, it's available for people to run.
You can download it, run it locally.
They also have some cloud options.
And it's really neat.
There's super nice ways to host it.
You just say run it as a service.
One of the things that's pretty interesting here,
let me steal the stage for a moment,
is this all runs inside of,
in your browser, client-side.
So that's one of the big differences with, say, Jupyter versus this,
is it's powered by WebAssembly and PyOxide.
Okay.
PyOdyed, rather, sorry.
And so, for example, this one that I pulled up, I'll put it in the show notes,
is the F1 Driver Career Explorer.
And look how nice this looks, Brian.
Like in terms of relative, compare that to Jupyter, for example,
I think it's got like a really beautiful style.
You know, you can check out, well, this is old.
We've got to put Ferrari in here for Hamilton.
You only got Mercedes and McLaren.
But it was powered by, say, DuckDB WebAssembly, for example, and F1 data.
And, yeah, it's got little Explorer sort of things.
And it just feels really polished.
It also has a collaborative edit sort of thing, like Jupyter Notebooks.
Sorry, like Google Docs, rather.
So you can, like, pair up on them.
There's a lot of neat stuff about this.
Okay, but this is, okay.
It's still cool, but I misunderstood.
I thought maybe it was just a new way to run Jupyter.
notebooks. Yes,
but with a decent amount of new features,
I mean, yeah. Well, I guess the
thing I'm
missing then or not understanding is, is there a relation between this
and Jupyter notebooks? Can you use any of the rest
of the Jupyter environment? I believe so. I'm
trying
to
remember now how much integration there is between those, but yeah, I think so.
Okay, cool. I'll investigate more.
Anyway,
I'm still pretty excited about it.
It looks pretty neat.
I'll have to play with it a bit.
Yep, absolutely.
It's also another thing that it really tries to solve
is they are trying to solve the...
Oh, you know what?
I said it had a Google Docs integration.
Not exactly.
But what they're trying to solve
is the real challenges of integrating notebooks with Git.
So, for example, with notebooks,
they're really JSON files,
and then they've got the input blocks and the output blocks.
So if you've run some code
and it's dependent on anything that might change.
You'll get like huge, instead of getting a nice merge,
you'll get two conflicts of giant embedded blobs and so on.
Yeah.
The other thing that this really addresses around notebooks
is notebooks allow you to run them in any order,
which is kind of insane, right?
Like I could run cell one, cell two, cell three, cell four,
change cell two, run cell four again to see what the output is.
But maybe the changes would have made cell two be different
or cell three be different.
You can skip over.
You'll have little numbers on the side of which order it was running.
It'll be like 1, 7, 8, 19, 14 or something.
As you go down, you're like, oh, this.
So this is reactive in the sense that every variable you create is wrapped.
It's not technically wrapped in a reactive behavior thing.
They parse the DOM every time you run anything.
And they create relationships between cells.
They'll say like, okay, cell 10 uses something from cell 1 and cell 3.
So if you run cell 3, it knows that cell 10 is out of date
or potentially will just rerun it for you.
So it keeps track of the relationships even depending on the order
so that you don't end up with like stale data
and then run another cell that pulls in that stale data and so on.
So it's trying to really address that as well.
That's cool.
Yeah.
That's one of the things that threw me off when I first started using Notebooks.
Yeah.
That's a little weird.
Like, why is it allowed to just run this piece?
And from an exploratory perspective, that makes sense.
Like, well, those were all expensive,
and now I just want to ask questions down here and over here.
But from a reproducibility perspective and debugging, it's bad.
Yeah, yeah.
So anyway, neat, something fun new to play with.
Indeed, yeah, it's pretty cool.
So that's our items.
Do you have any extras for us?
I do have some extras.
Let's see a couple real quick.
PyCon Taiwan, PyCon Taiwan 2025, is doing a call for proposals.
It's going to be in the fall.
And so you've got until April 5th anywhere in the world.
So if you want to go to Taiwan and present stuff there,
they have a decent number of English tracks and talks and stuff,
and they're looking for more.
So check that out.
Also, a follow-up on the Hacker News thing.
Remember, Brian, I was reading the Hacker News thing saying, who's looking for a job?
Who's hiring?
Well, Shinjitsu sent us a message and said, I'm sure some other Hacker News readers have
already told you this.
No, they haven't.
So thank you, Shinjitsu.
But if you haven't, you kind of got this exactly wrong.
Like, oh, sorry.
It says, Ask Hacker News Who Is Hiring is a monthly post that asks employers to post what
jobs they're posting, not people asking which one.
And who wants to be hired is a monthly topic that has people who are looking for jobs about themselves.
So did we have that backwards?
It was actually bad news?
Yeah, I think that's what it's saying.
Let me see here.
Yes, I think I said who wants to be hired was asked by the employers.
And who is hiring was asked by the people looking for a job.
But it sounds like it's the other way around.
So that would make it less rosy.
So sorry about that, folks, if that was a little bit backwards.
Oh, okay.
See?
Errata.
Yes, we have
to have an errata.
How about you?
I got a couple of things.
First off, PyCon US announced that there's a refund policy for international attendees
if you qualify for certain things.
And actually, I'm just embarrassed as American that we have to do stuff like this.
But international travel in the United States has become more complex for many of our community.
PyCon US welcomes all community members to Pittsburgh.
But if for some reason you can't come because of various problems, read the post for details.
But they're a fairly – I think a fairly cool refund policy details.
So anyway, if you can't come for some reason, check this out and maybe you can get a refund.
I've been thinking
a lot about this.
There's been a lot of badness.
And I'm not happy about it, Brian.
I'm not happy that our country is treating people that way.
It's one thing if you catch somebody trying to sneak over the border and, I mean, it's a political debate on how lenient or aggressive you want to enforce that.
But when people, especially from fellow ally countries, just try to come over and they get put in jail because they didn't have the right kind of visa or something, that is some bad stuff.
That's embarrassing.
Well, you would just never think that that was the way the U.S. would treat people.
I know they've been a little bit tough on immigration, but, you know, Australia has, Canada has.
I was detained at the Canadian border for a long time and finally was let into Canada.
And it's, okay, it's a hassle.
But this is another level of jerkery.
Yeah.
I am glad to see that PyCon is doing this.
I apologize to the world.
I guarantee you Brian and I are not supporters of this policy.
We're supporters of the refund policy.
Yes, not the
cause of the refund
policy.
Yeah.
Right.
Okay.
Oh, on a slightly more positive note, I finally finished up restructuring the complete pytest course series.
So originally it was – so this is over at pythontest.com.
This originally was – I had a remaking the pytest book I wrote as a course, and it was one course.
But really the book was into three parts and intended to be read at different times during your development process.
When you're first starting out at pytest, then when you're trying to apply it to projects.
And then when you're like really good at it and you really want to like take off and get great at it, there's another section.
And I had it in one course and it doesn't write quite – I don't think it really quite fit how people use pytest and learn pytest.
So now it's split up.
So you can still get the complete bundle and it gets the three parts.
but the three parts learning the basics of pi test is a separate course now you can just buy it
separate and then um and then you can grab uh part two um and then part three but also part two is
working with projects part three the booster rockets like building really uh building
plugins is why you'd probably grab this um and advanced parameterization techniques
however
even
if you didn't buy the other ones i like having them separate now because if somebody's like i
really want to build my own plugin, you can just go check out this one course instead of taking all
three of them. So that's my big news there. The other, the other reason why the other structuring,
restructuring that I did is I, all the chapters are now a single video per chapter for the most
part. Chapters two and three are a bit long, so I split them up. So they're about 20 minutes each.
But the thing that I really like about this now is that in each video you can pop in and you can
change the speed so you can watch like the whole like i'm i'm usually a 1.25 or 1.5 speed kind of
person um and it was bugging me that you had to reset that setting every three minutes like for a
three or five minute video now now it's only like you only set it once for a 20 minute video so
anyway works better for me hopefully it works better for everybody else too so
that's
my that's
my big extra so yeah awesome congrats on getting that all already done that's great
yeah
so um
How about a joke?
Shall we boldly go?
No one has gone before.
Yeah.
So last week's joke was around, was a Star Trek Klingon theme.
And we had, who was it?
We had somebody from Holgi on Mastodon said, again, you probably already know this,
but there's this thing called Klingon programmers.
So this is over at Cornell.edu.
Top 12 things likely to be heard if you are a Klingon programmer.
And I kind of love this, so we should probably zoom in a little bit.
Okay, we're not going to read all 12, but number 12 is actually pretty good.
Specifications are for the weak and timid.
Do you want to read any of these?
Let's see.
This machine is a piece of God.
I need a dual Pentium processor if I am to do battle with this code.
Yeah, number four, a true Klingon warrior does not comment his code.
Debugging.
Klingons do not debug.
Our software does not coddle the weak.
Klingon functions do not have parameters.
They have arguments, and they always win them.
I love it.
All right, let's round out the
tie back to last week,
which was we will test in production.
Okay, yeah.
So this is, what, number one?
Number one, do it.
Our users will know fear and cower before our software.
Ship it, ship it, and let them flee like the dogs they are.
Exactly.
This is good.
This is a reminder also to everybody that if you think we probably have already heard it,
there's a decent chance we haven't, so send it to us anyway.
We don't mind repeats.
So if you find something funny or something.
People give us a lot of credit,
Brian.
Maybe too much, more than we deserve sometimes.
Yeah.
Anyway.
Well, thanks again for jumping on the call with us and enjoy doing another episode.
And thank you, everybody that listens and everybody that shares this with other people.
We like to grow our community.
Yeah, very much appreciate it, everyone.
See you all later.
Bye, Brian.
Bye.