Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.
This is episode 427, recorded April 7th, 2025.
And I am Brian Okken.
And I'm Michael Kennedy.
And this episode is brought to you by Posit Package Manager.
Check their spot out later in the show.
Also connect with us if you'd like to on Mastodon or Blue Sky.
Links are in the show notes.
And then also, if you'd listen to us through a podcast player or something, occasionally it's fun to stop by and watch us live or at least see past live episodes.
You can go to pythonbytes.fm/live.
We usually do it Mondays at 10, but sometimes it changes.
Anyway, it's fun to have you here.
And some people hop in and ask questions and it's good.
Anyway, also after the show, when we have everything all the dust settles, We send out links through our newsletter.
So please go to pythonbytes.fm and add your name to the email newsletter, and you'll get the links and some extra content delivered right to your inbox.
It's pretty good.
Absolutely.
Michael, what
do you got for us to start with?
Let's go on a trip, Brian.
Let's go on a trip.
Okay.
I want to go to take a little trip to GitTown.
GitTown 18.3.
Let's do it.
So Git Town is an interesting project.
I believe it's written in Python.
I'll double check that in a second, although it's not totally germane.
It's a tool that you can use.
And the idea is with the Git CLI, or honestly, most of the Git GUIs, I'm a big fan of primarily doing Git through GUI operations using SourceTree, PyCharm, VS Code, whatever I happen to be in, right?
I
don't think I'm like,
well, pretend my editor doesn't know what any of the source control is and go to the terminal and do it and then come back.
Like I just preferred that way, especially, you know, that's why I called out that Git branch explorer, that, that TUI based one that we talked about last week
in
Rust.
So one of the things you'll find with most of these tools, especially the CLI, but often all of them is they're great at the atomic operations of Git and source control, but they don't have workflows built into them.
So by that, I mean, I want to create a feature branch off of this branch.
And as I'm working on the feature branch, I would like to be able to type a single command and have that branch make sure that it's up to date with it without breaking the work that I'm currently doing. Maybe in the middle of a feature branch I'm working on, I need to create a bug fix branch and do that, come back, sync them. There's like these higher level things that you would like to do. Okay. So Git Town is a CLI, I think it's a plugin. I think Git has like plugin type things because the commands are still Git space command, subcommands of Git, right? So it's not a totally separate thing. Anyway, it operates all, it sort of brings all those together. And so if you're, if what I'm about to describe sounds interesting to you, you should really, really watch this seven minute video at git-town.com and it says, please check it out. Right. So just watch this and it talks through the different scenarios, shows you how it works, and so on. However, if you jump over to the Git town GitHub repo, it gives you a much better understanding of all the pieces there. And by written in Python, I mean written in Go. Okay. So it has a couple of different commands. It says I could type git, like in a git repo, I could type git space hack. And that will create a new feature branch that I can explore that will not affect any of the main work. And if I need to throw it away or whatever, it's fine. It's kind of like the exploratory, like hack in a positive sense, not hack is in the, I got a hoodie and it's shady in my room sort of thing. Or sync. If I'm on top, if I'm on some kind of feature branch, I can update that branch from the main. Cause one of the things you want to do as you're, if you have a long running feature branch is keep periodically pulling from the main branch in there so you are less distant from it, right?
If for some reason, like when you want to go back, you want that to be just your changes, not your changes plus all of the conflicts that you've been potentially messing with and you've got another round basically.
So this, you would just type git space sync.
That's cool.
You could type git switch to change branches via UI or once you're happy with your feature branch, you could say git propose and that'll create a merge.
It'll create a pull or merge request for a feature branch back on GitHub, things like that.
So there's a bunch of cool things like that.
I thought it was going to ask it to a dance.
Exactly.
You know, I mean, I know we haven't talked much, and I know this is seventh grade, and we're all really shy, but do you go to the dance with me?
My dad can drive us.
Another one is you can do things like git ship, which will merge a completed feature branch and then remove it once it's successfully shipped over and so on.
So there's like these cool things on top of it.
But certainly I recommend watching that video, that seven-minute video, to see if this is something that's interesting to you.
I think I like it.
I think it's pretty cool.
There's some cool ones that I always forget about, like Get Town Rename.
I mean, renaming is not difficult, but it's nice to have a little minor.
Absolutely.
And if you watch the video, you'll see that there's a lot of – really this thing is mostly built around like, yeah, you could – You're like, well, why can't I just do, you know, Git merge from this branch and this and that?
Sure, you can do these things.
But it
has a bunch of little steps to kind of catch the edge cases.
Like it'll use stashing for certain operations when it's sure that you don't want any of your changes changed and other things.
Like each one of these commands usually results in five or six or seven Git commands.
It's worth checking out, especially if you like Git via the CLI.
Or you work in
a team that wants really structured ways of doing these things.
I'm definitely going to check it out.
And actually, I used the, I can't remember what we called it last week, the SAG or something like that.
But I used it this weekend to look at a Git log from a project that I hadn't been familiar with to see what was going
on.
Awesome.
Have you tried it on your Windows?
Like, I want a Windows terminal follow-up.
What was I using it on?
Remember, you were wondering if it would work on Windows.
Yeah.
Did you do this on your Mac?
I was using it on my Mac laptop.
Okay.
Well,
the follow-up is still pending then.
Okay.
And we'll check out GitTown
on Windows as well.
We'll take a little trip to GitTown.
I'm sure it's
probably fine.
Yeah, this just automates Git, which works everywhere.
Okay.
Last week we did – going back to last week, I guess.
We did talk about a couple peps, and today I'd like to talk about another pep.
This one comes to us from Brett Cannon.
Well, I saw him posted on Blue Sky.
Pep 751 has been accepted.
So what is this Pep about?
It's about lock files.
So Brett says this means Python now has a lock file standard that can act as an export target for tools and create some sort of lock file.
And for some tools, the format can act as a primary lock file format as well as instead of some proprietary format.
So we already had lock files.
A couple, lots of different tools had lock files, but they weren't the same lock file.
They were like uv had a lock and I think Poetry had a lock and there's a couple others.
So now we have a standardized one and it's actually, I was looking through the standard.
It looks pretty great.
One of the things that you would expect, you could do environments and versions and packages and stuff.
One of the things I thought was kind of cool, scrolling down to the bottom, was that there's a tool section that is pretty much open-ended.
And this allows arbitrary tool configuration.
So if other tools like Poetry or whatever want to try to use this instead or migrate to it, but it doesn't kind of cover some of their own configuration, they can override this and put some extra things in here, which I think is pretty cool.
There's also packages tool.
I'm not sure which, I don't know, when you would use one or the other, but I'll leave it up to some tutorial writer to figure that one out.
So this isn't to a, if you wanted to try this out now, let's look at an example first.
The examples is in the video if you want to check out the live version if you're listening, but we're going to link to it as well.
It's in the PEP.
There's an example.
Mostly this is fairly readable and I'm pretty on board with how this is set up.
It looks pretty good.
It's Toml syntax.
You've even got things like, of course, hashes and stuff.
If you want to leave the hashes in for making sure it's the right thing.
So this is all great.
The other bit scrolling down is, well, how can I use this right now?
There is, there's some stuff, information about how to teach it, of course.
some discussion around rejected ideas.
Oh, I forgot to mention the name.
The name of it is pylock.toml, or pylocksomething.toml.
That's just what they came up with.
It doesn't conflict with any other tools right now, and it's reasonable, so that's good.
If you want to try this right now, I thought we had an implementation.
There was, okay, I can't find it right now, but there was an implementation already that is just an example that it's in Brett's tool, Mousebender.
So Mousebender allows you to play with it if you want to play with it right now.
So I imagine that some of the other tools will kind of take this up also.
And I would expect that, like, for instance, uv or something might, I don't know.
I'm not involved with UV, but I would expect some of these tools to pick them up pretty quick.
But we'll see.
Yeah, well, first of all, congratulations, Brett Cannon.
I know you've been working on this for a long time.
Here we are.
Super exciting.
So I'm sure some conversations at PyCon will be had about this.
Yeah.
Super neat.
So one thing that I like is the format.
I saw like the hash is on the same line as the actual requirement pinned version there.
So I'm trying to do hashes in my requirements.txt files.
And the hashes so overwhelm the version of the thing that you actually have in the diff that it's just like, well, it's a bunch of hash variations when I look at the diff and I got to hunt for the actual new version.
Like, well, what one of these changed because the version changed and what is the new version and so on.
So the way this looks, it looks like it's going to be, well, it might differ also on the end for the hashes, but the first thing that appears on the line is the actual version number wheel and so on.
So I think that's going to be really nice to look at.
So
I might put the hashes back in.
Yeah, I think it's kind of cool that there's an upload time.
So if you don't want to deal with hashes, but you do want to grab the upload time as a way to check for things.
That's cool.
Yeah, you just kind of know how old is that as well.
Yeah.
Right.
I mean, for things that are not using Calver or they're abusing Calver, you know,
is it five minutes old
or is it five months old?
That might matter to you.
Yeah.
Very cool.
So awesome.
I'm here for it.
And do you know what else is awesome?
What is that, Brian?
I think Posit's pretty awesome.
Oh, they are awesome.
Very much.
So I'd like to take a moment to thank our sponsor.
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've been building out a suite of tools and services for Team Python.
Over the past few years, we've learned some pretty scary terms like type squatting, supply chain attack, obfuscated code, and more.
These all orbit around the idea that you install Python packages.
When you install Python packages, you're effectively running arbitrary code off the internet, on your dev machine, and usually even your production servers.
That thought alone makes me shudder.
This doesn't even touch on the reproducibility issues surrounding external packages, but there are tools to help.
Posit Package Manager can solve both problems for you.
Think of Posit Package Manager as your personal package concierge.
You use it to build your own package repository within your firewall that keep your project safe.
You can upload your own internal packages to share or import packages directly from PyPI.
Your team members can install from these repos in the normal ways using tools like pip, Poetry, and uv.
Posit Package Manager will help you manage updates, ensuring you're using the latest, most secure version of your packages.
But Posit Package Manager also takes point-in-time snapshots of your repos, which you can use to rerun your code reproducibility in the future.
Posit Package Manager reports on packages with known CVEs and other vulnerabilities so you can keep ahead of threats.
And if you need the highest level of security, you can even run Posit Package Manager in an error-gapped environment.
If you work on a data science team where security matters, you owe it to you and your org to check out Posit Package Manager.
Visit pythonbytes.fm/ppm today and get a three-month free trial and see if it's a good fit.
That's pythonbytes.fm/ppm.
The link is in your podcast player's show notes.
Thank you, Posit, for supporting Python Bytes.
Indeed. Thanks, Posit.
It's a cool project.
Having a little bit more control over your
packages is
always a good thing.
Well, Brian, I want to carry on with the theme of Git and talk about three more Git project, Git topics, I believe at least.
Who?
So we know where, like this, this is sort of the thing they teach you in like early writing classes, all the W's, right?
Who, what, where, when, why, how are we covering these things?
We've gone from where to who, and now we're talking about Git dash who.
So I've always enjoyed the get blame or basically more broadly like source control blame.
Like, all right, who did this?
Do you see that line of code?
Who do I talk to about this?
Either they are not very good or we need to talk to them or there's something way more complicated going on here and I need to understand it better.
But who do I talk to about this line of code?
You know what I mean?
And the way that works is you can run that on a file and it shows you line by line who made the last change to that particular line, right?
Editors support that.
Super easy these days.
Like in PyCharm, it'll actually put an overlay of who wrote the function or whatever.
If you click on that, it'll sort of slide out the get blame.
But that's a line by line type of thing.
What if instead I wanted to know as an entire project?
Like if I go to the repo and I type get who dash L, it will say who has made how many commits, how many changes, how many lines, when did they last do that as a summary of the project instead of a summary of the line.
Cool, right?
So that's super easy to do.
And you can go into subdirectories and sort of explore those and go who's created changes on this particular subdirectorie or whatever.
So I think this is really neat.
It's sort of a natural extension of get blame.
Okay, so you can give it a particular file even and just say who modified this file?
Yeah, I would think it would say how many contributions there are to that particular file.
I don't know if you can give it a file, but there was a single file in a directory.
That's pretty cool.
Probably you can give it a file as well.
Yeah, it
just sort of shows you who has been active in this repo or this subdirectory of a repo lately and how much have they
contributed.
Yeah, the blame part is one of the reasons why I'm careful if I try to do like a, just a prettying up of code.
Do you want to break
it?
Well, no, I don't want to be blamed for
it.
So if you're just like lining up something to make it look nicer, be careful because you're now the owner of that line of code.
Yeah, that's an interesting angle.
I wonder if you should almost create like a formatter account
and
just let the formatter do the formatting.
Well,
actually, that's one of the lovely things about putting, putting like, separating, separating formatting stuff.
So I was like, that's one of the things I try to teach people is to, if cleaning up is great, but do it in a separate commit.
Don't do it in the same commit as a bunch of actual code
changes.
Sure, sure.
But it doesn't fix the blame part.
No, it doesn't really fix the blame part.
But another thing that the, that GitTown thing does is it'll, it uses squashing pretty aggressively.
So when you do all your feature branches and you make 20 changes, you can squash that into a single commit
as
part of the publication PR flow.
And so then at least when people go look at the blame, it's like all part of one commit that has to do with this feature rather than Ruff formatting,
adjusted space,
you know, like random.
Like if you get it too small, your comments are like really, really not historically relevant.
You know, like this is the formatting statement, like great.
And why did, when were we doing this?
You know what I mean?
Yeah.
Actually, I kind of forget that not everybody does that.
So I always do a squash workflow.
I see you're a natural
squasher.
Okay.
I'm a natural squasher, yeah.
That's of course.
Well,
mostly because it's way easier to roll back stuff.
So if there's something that really causes a downstream problem, you kind of want
to roll back all of that work together.
Yeah, that's
a good point.
So next up is whatcha, whatcha.
Okay.
Watch, G-H-A, but there's no capitalization.
So whatcha, Tom.
And this comes to us from Ned Batchelder, as in not he sent it to us, but he created it.
And this is just another Git thing real quick.
I think people find it relevant.
So what you can do is you can install this, and then it will allow you to watch in real time the status of your GitHub actions.
So imagine there's a bunch of changes that have come in.
You're running talks for different versions of Python on your thing.
There's some pending other requests that are queued up, and you're waiting for them to run, and you just want to know, like, well, when are these done?
How long are they taking?
So you can just point this at a GitHub repo that has a GitHub action.
This is awesome.
It's pretty cool, right?
Yeah.
Yes, I often have, like, a git tab open
to watch this stuff,
but having it right in the command line, nice.
Yeah, and it's like a live updating, very TUI feel, right?
It's a very
advanced
sort of UI.
It's not just a stream of text, but it's the UI is updating and changing with progress bars for each action and so on.
Yeah.
Cool.
So, yeah.
Well done on that, Ned.
That's super cool.
All right.
That's it for my main items.
Over to you, Brian.
Okay.
So are we on?
No, for your last one, you got one more, don't you?
Oh, I got one more.
Yeah, I do.
I think you do.
Yeah.
So next up is I'd
like to talk about uv a little bit.
Yes.
So this is Dave J.
So Dave Johnson article.
It's called Share Python Scripts Like a Pro, uv and PEP 723 for Easy Deployment.
And we've talked about a lot of these pieces in different episodes.
But I really like this write-up.
It's a sort of kind of, if you want to write Python scripts with dependencies, that was an issue before and now it's not, but all the different parts of how to do this.
So it starts out with talking about what uv is and PEP 723.
And that's the PEP that allowed you to put like some stuff at the top of a file to include your dependencies and stuff.
So to set the stage, we don't have to dig into what this is, but he gives a command line script called Word Lookup that has some things like argparse that's built in, but it also uses HTTPX.
So that's an extra dependency that's outside of the script.
And this is if you're doing a web scraping script, you're going to often have like some extra dependency or something.
So then that's the script.
It teaches you how to install UV, but you probably already have it installed.
And then how do I add that thing?
You don't have to memorize the format of how to put that up at the top because if you say uv add script and then you give it your script name and then what your dependency is, it automatically fills that out for you.
So it sticks that script block at the top of your code, which is awesome.
And I think I knew that but forgot about it.
So I'm glad it's in there to just add that little script tag.
And then talks about how this is different and similar to the PyProject.toml and the relation to that, which I kind of like that extra teaching.
It isn't necessary that you know that for scripts, but it's good for people to have that knowledge about the whole ecosystem.
Talks about running it with UVRun.
And then jumps down and saying things like you can do uv run, but you can also just add that uv run as a shebang for Linux and Mac users.
You can add that to the top and it gives the
specific environment SUV run script that you have to stick to the top of that.
That is
super
interesting, actually.
And then you don't have to say Python or uv run.
You can just save the script name if it's an executable and it'll just work, which is awesome.
And I didn't get into trying this with Windows, but apparently you can kind of do some of this around how to get this invocable on Windows as well.
I haven't tried this, but you can use Pi and other things.
So there's
some help.
I think the Pi launcher respects
shebangs on Windows, which is something it adds.
Okay, cool.
And then he recommends creating like an extra script with a CMD script to launch your script with.
So how to do this, how to complete the loop with Windows.
So really great write-up for people writing utility scripts in Python.
That's actually really nice.
Yeah, well done.
Yeah,
so that's
all for our main topics.
We both have extras.
Do you want to jump into your extras first or do you want me to do
ours?
I'll do mine real quick, sure.
I
got a few. I'm going to try to go quick through them. One, I talked about PySQL Scribe, which if you're writing raw SQL for your code, but you don't, you want to have some kind of tooling support to help you in Python.
This PySQL scribe lets you express through code the structure of your tables and their relationships.
And then you can ask it like, hey, what would the query of this be?
And then it'll generate it based on like what database scheme or dialect like SQLite versus Microsoft SQL Server query syntax you wanted to generate and so on.
And I proposed when we talked about it that, hey, would it be cool if there was an ability to just point it at a bunch of create scripts that defines your hundred tables and it just knows that?
Well, Daniel, who runs a project, said that is a good idea and just released a version that you can just point it out a directory of create scripts and it'll use them to understand your entire data structure.
Good job, Daniel.
So a little bonus there.
We talked about, this is a long running one.
We talked about formatting Markdown with MD format, which I've started to adopt.
I will talk about that next.
But Hugo points out, like, hey, I use Prettier, which has been around for a long time.
It now has a Markdown format.
So that's really cool from 2017.
People can check that out.
And I'll link
to that in the show notes if you want to use that.
I, however, am continuing on with MD format.
And I ran it against the entire markdown structure of my upcoming Talk Python and production book.
And it's, like I said, all markdown.
One of the things I discovered, I don't know if you knew it, Brian, but I definitely did not.
It's a really interesting linting philosophy.
Would you run it against markdown?
it will render the markdown to html then pretty it then you know clean it up and then it'll run it through the markdown parser again and if the html differs it will roll back that
change oh that's cool yeah
so one of my chapters apparent i put a whole bunch of plugins and goes one of the plugins is like not great because it changed the format and i'm like oh which one is it but i like them all i don't know maybe i need to debug it right now i'm just not formatting one chapter and you know what chapters 13 obviously
obviously it's
13 anyway um what i found the command that i think is really really good is to use i wrote it down it's in the show notes where i must find it it is to get say md format --number so it renumbers those things which is great and then this one i thought i would like it to wrap it but all of my editors actually preserve the wrapping format so that it can kind of help you see the structure a little better, even though Markdown Render doesn't.
And so that looked really crappy.
So if you say --wrap, no, it'll actually explicitly unwrap if you've accidentally got some in there.
So I like number and wrap, no, not just not change it, but actually unravel the wrapping, which I thought was really cool.
And as part of that, we did talk about UV, sorry, we talked about PIPX Inject.
And
last time you pointed out correctly that uv tool install --width is the equivalent.
But I wanted to point out that when you, and I put it in the show notes, if you want to use width and uv tool install like inject, you have to say width as many times as there are extras.
So uv tool install, MD format width, MD format, GFM, --width, MD format front matter, --width, and so on.
So if you want to get that inject feel, you've got to like width separately every single parameter, every single extra or whatever.
so
anyway that's a thing another one you can see right now that I if you're watching the live stream or see the pictures that I'm using the Zen browser which I really come to love it's built on top of Firefox which is great and I really want this like nice clean format we just have the tabs as icons on the side and everything's just at the top and gives you more space right Well, Firefox, if you are a Firefox purist, has now come up with this tabs on the left side of things, which is a brand new feature that they just released last week, I think it was.
But if you grab that little width of the tab and you slide it over to their icon size, it looks exactly like what I have on the screen right now, right?
Where it has just icons on the left for the tabs and a dress bar across the top.
The new Firefox is pretty good.
There's still stuff missing that Zen brings.
That's really cool.
But anyway, I wanted to point people that that's an option now.
Nice.
Yeah.
Finally, last thing on my end is a follow-up on uv from James Falcon.
Sorry, James Falcon.
Thanks for sending us in.
He says, hey, I'm also a uv enthusiast.
And I was holding out to using uv because there's one case it hasn't solved.
However, you guys convinced me to work through it and get it figured out.
So he maintains a library supported across multiple Python versions and needs to deal with bugs and specific ones.
So like it doesn't work this way in 3.8, but it works fine in 3.10.
So the idea was to have, originally I was using PyE and V because you can create virtual environments with those different ones and then activate them by name.
But the way uv worked originally, it didn't.
So what he said, hey, look, I'm creating just a location for virtual environments on my profile, maybe a sub folder for the project.
And then I use now use uv to create version specific virtual environments, you know, 3.11, 3.12, 3.13 and so on for that project.
And then he includes a batch file that you can just say work on this virtual environment project name and it'll automatically find it and activate for you and so on.
So kind of gives us an example of like how you might sort of pyvee and be your way around different versions using uv.
That's pretty cool.
Yeah,
so there's a little bash script that people can check out if they want to use it.
Nice.
Okay.
In the show notes.
Yep.
That's it for my extras.
Well, so for my extras today, so it's April, right?
And one of the things we do on April 1st, sometimes there's April Fool's pranks that happen.
And one of the things, so there's good April Fool's pranks and then there's bad April Fool's pranks.
So I'm going to cover both.
So first off, I think a good one, which was a video put out by, well, it was forwarded by the PSF, but it says CultRepo.
I'm not sure.
I looked and I'm like, that is a really weird thing to kind of do an official joke from the PSF.
That CultRepo group, they make a bunch of documentaries about, like highly produced documentaries about programming languages and their origins or
programming
frameworks.
Like they have some on Vue.js and they have some on Angular.
That's
where it's from.
Okay.
So
the video is breaking Guido Van Rossum returns
as Python's BDFL.
And it's a two-minute video or almost two minutes.
Hilarious.
I loved it.
It shows him like typing of the saying that everybody, what is the standards people?
Oh, the boards.
Steering counsel.
Steering counsel is no longer necessary.
A couple of things I wanted to point out that I loved about this video.
Brett Cannon, he's in it and he's listed as famous Python quotationist is his title.
And then Guido goes ahead and says one of the things that he said, Guido says, as I always say, come for the language, stay for the community.
And that's not a Guido quote.
That's a Brett quote.
So the famous Python quotation is gets crossed out after Guido says that, which is pretty funny.
And then a little later, who was this?
Barry Warsaw walks in and says, Guido, are we ready to release Python 2.8?
Which is never going to happen, right?
So that's pretty good.
Guido says indentation is enlightenment.
And Barry gives him credit for saying that being Pythonic means becoming one with white space, which is good.
Anyway, and then it kind of wraps it up with Guido announcing that he's going to implement a new keyword, maybe.
It's kind of like if, but way more Pythonic.
So maybe something.
And it gives an example of maybe print Python, the documentary, coming this summer.
And I kind of hope that one is real.
I hope we get a documentary coming.
Well, it's already this summer, or it's almost this summer.
If we get a
documentary.
Well, we're going to get it soon, then that'll be great.
And if this
cult repo company makes it, I think it'll be pretty good, yeah.
When I first saw this, I was like, I saw a tweet come out.
I'm like, hey, whatever.
Funny little joke.
And I just thought it was a tweet.
And Nick Wallace sent it over and like, wait, you should check this out.
It's funny.
And I'm like, watch.
I'm like, oh, there's way more here than I realized.
This is
well done.
This is good.
Okay, so that's
a good way to do an April Fool's prank.
I've never done one.
I've never done like a tech prank.
So I decided to try my hand at that this year.
It did not go that well.
So I'm – and you know how – have you ever heard like if you have to explain a joke, then it's not funny?
This is me explaining a joke, so it's not funny.
So there's pytest Repeat.
So I've been doing, on testing code, I've been doing this series on pytest plugins.
And pytest Repeat is one that I use all the time.
And I noticed that it hadn't been being tested on, it only was tested on 312.
It's not tested on 313 yet or 314.
And, okay, so 314 is 3.14.
pi starts with 3.14, but pi is an irrational number, and it doesn't repeat.
So the joke I was trying to make was I put out an episode on testing code.
On April 1st, Python 3.4 won't repeat with pytestRepeat.
And I guess it was – and I even, like, tried to make it, I thought, obvious to say, unfortunately, it doesn't seem to work on 3.14, even though there's no rational, like no irrational.
Yeah, that was nice.
I listened to that episode.
It was well done.
Anyway, I got some feedback of people confused and wondering why I was testing 3.14 anyway, since it was an alpha.
And anyway, I had to explain like to five different people that it's actually fine.
So the TLDR is pytest Repeat works fine with Python 3.14.
So don't worry about it.
Anyway, how not to do an April Fool's break.
So I guess that's all of our extra items, right?
It sure is.
We'll see
how much I got to explain this joke, huh?
No, I think this one is fine.
This one is good.
So this comes to us from the Programming Humor Twitter feed.
And it says, what's the best thing you found in code?
And they are almost always about comments in this thread.
So here's a, this is actually Python.
So this is a comment that somebody found in the code and they posted it.
But if you look through and you look at the comments below, there's a glorious set of 132 comments of similar.
They're not all great.
But so here's what it says at the top of this thread.
It says, as a comment, you may think that this function is obsolete and it doesn't seem to do anything.
And you would be correct.
But when we remove this function, for some reason, the whole program crashes and we can't figure out why.
So here it will stay.
So
I entitled the joke, so here it will stay.
And let me see
if I can find a few.
This is my favorite one, though.
This probably should have been the top line one, but this came to us as a response from the original.
Somebody named Jeppe pointed out and said, not mine, but I find this kind of funny.
And this is a C-based type of language because it's slash slash for the comment.
Dear programmer, when I wrote this code, only God and I knew how it worked.
Now only God knows it.
Therefore, if you're trying to optimize this routine and it fails, most surely it will.
Please increase the counter as a warning to the next person.
And then there's a variable below that says, total hours wasted here, 254.
So good.
That's good.
And on and on it goes.
If you don't want the rest of your, if you want to lose maybe a half hour, you can go right down here and there's a bunch of good stuff in there.
So there it is.
That's good.
Yeah, I think that's a good one.
Yeah.
I've only a couple times have, actually, at least I have at least one memory of some code that didn't look like it did anything, except
for obviously
it was getting run and the timing, I'm sure it was just timing.
Like if you took it out, it changed the timing of the rest of the program and then it didn't work.
So yeah, I've actually
run into it.
You would uncover some kind of concurrency bug that it was defensive against.
Yeah, yeah.
C codes
are like that.
It's hard to see there.
that's true. Hard to see the errors.
That's... That
was good, wasn't
it?
No. No, it wasn't. We better quit.
We better just call it an episode.
Okay. Alright.
Thanks
a lot. Bye. Bye.