#425 If You Were a Klingon Programmer
37:55 Share

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 Ockin. 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 slash 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 talk 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? 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. 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 that will take forever. So someone said, I get it replaces pip and 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. 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, I think those are worth touching on. So what are the awesome things about using UV V and V instead of Python V 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 312 or 311 or whatever version you want or a specific minor version, right? Or,

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 with,

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. With PyENV, 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.

It's a thing of beauty. Well, I just ran into the build, a problem with the build recently because 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. Yeah.

or try to recompile some stuff. And then you have to make sure that you have the right 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 see previous comment. - But I mean, it is installing it, using UV to install. 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. And 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 to 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. Yeah. A 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, well, what did I call it? You know what I mean? They're like, Oh, it drives me crazy. And with it being inside the project folder, you can look up. Yep. There's a virtual environment there. I'm good to go. Same reason that I don't like it. Call in mind dot 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 pi, env, and pip. I mean... It seems like a you 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 not going to walk two miles to the store.

I'm lazy. That's why I am using UV because it's, it speeds up everything and I can get on with my day faster. Yeah. Matthew Rocklin of, of Dask and Coiled has,

Had a really interesting comment once on TalkBython that basically like so much in programming happens because we're leveraging the natural inclination for programmers to be lazy. Let's set it up so they can do this so they have to do less work and 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...

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, but

And I brought this one up, switch back to pipenv. 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. 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, you kind of had to buy into it or not. Yeah.

Yeah. It's all or nothing. Yeah. Another one really quick. We partially use it. We will transition when dependabot 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. Uh,

without turning off all the security features at GitHub. So I 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 got an update for this. You got an update for that. Oh.

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 TXT, you have Dependabot support.

All right. Last thought, I'll leave it with this one from Jared Sheel. Seen 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 like, well, this is how we do it. And I know it sucks. It's not better, but this is how we do it. I mean. Yeah. Yeah.

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 the company.

and that part isn't working right um but you can still pip install uv and i have done time tests and it's still faster to use the use uh uv even if you pip install it so you just don't get all the benefits yeah absolutely awesome yeah anyway you gotta already have a project you can't start you gotta have python you gotta have a vnv and then then you go from there yeah anyway we're

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 shout it out. Dependabot just added support last week for UV Lock. How about that? So do you know how out of date that Twitter thread is? So last week. So last week. Well, and also a lot of the knowledgeable people probably didn't respond because it's on X. Yeah.

Yeah, that's true. Well, I mean, there's, it's a surprisingly amount of, uh, surprising amount of interaction over there for, for what it is. Okay. Over to you. Okay. Uh, let's talk about UV a little bit.

We haven't even done that yet. So I want to talk about this cool project from Tim Hopper. Love Tim. 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 that, 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 you to the right answer. It's UVinit. And...

I mean, actually a lot of the other init, like initializing projects I haven't liked before, even like the flit in it. I didn't like, but UV in it is pretty darn good. There's, they're doing a good job. And anyway, so using, and then adding dependencies. And I love this, like, let's skip the, 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 yeah,

Publishing your first package, talking about setting it up. Anyway, 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 TestPipe.ai first before they go somewhere else. Although, be careful because there's a lot of projects that don't use TestPipe.ai, and they clean that one out every once in a while. So even if a package is available on the TestPipe.ai, it might not be available on the big Pipe.ai. Yeah, yeah. So you're like, oh, it uploaded, so that means there's no name conflict. Like, no, no, no.

Yeah. 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 Daya Taxis 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 Daya.

setting up rough to check your code and things like that. So I've been so excited about UVV and V and UV pip and stuff like that, that I kind of forget that I'm using UV rough all the time or using rough 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 up for a second, I was listening to that interview you did recently. Were you talking about, I think you interviewed Charlie recently.

And I, there's, I like, I like how detailed rough can be, but I,

But this is one of the things that I think I'm... Rough can go in the PyProject TOML, or there's Rough TOML also now. And I kind of like... I think I might transition to using the Rough TOML or try to, because I end up having 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's, it definitely takes more than a page of small font on my screen. And I don't want to, you know, you could reasonably have a pipe project at toml that's smaller than the rough toml. So, you know, I don't want to put those together. Yeah. And I loved his, the, the Charlie's comment about the rules of the,

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 conflict, but it gives you a really great detailed information about how, anyway, how to fix it. But,

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 rough TOML in having, if you exclude that with a Docker ignore, for example, then you rebuild it. It'll say, yep, there's no changes. Right?

unless those changes are resulting, 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 rules, then...

I do look, it's, it's both surprising and cool that, that by default, not all of them are on. Cause a lot of linters in the past, they defaulted to all on and you, you try to use the tool and it would just like blow up with errors. And, but rough does not. It's, it's, it's got some good standard ones and then you have to go turn them on. So anyway. Yeah.

One more piece I saw in the tool book here that it was being added with a UV add. I put rough into my system using UV tool install rough because just globally and then have a rough 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 to install. It's just like a globally available tool. Yeah. Yeah. I should do that. I don't know why I don't. Well,

Anyway. Well, should we talk about the wonderful people at Posit that are helping us today? Absolutely. Okay. Let's do it. This episode of Python Bytes is brought to you by the folks at Posit. Posit as in...

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 PositConnect. PositConnect makes it easy for data scientists to share work built with Python code. If you have a Streamlit app, Dashboard, Plotly Interactive Plots, a fast API service, or even a Quarto report, just give PositConnect

The code it needs to maintain the asset and Kinect automatically does the rest. Kinect will manage your APIs and serve your interactive apps. And if desired, update your ports and dashboards on 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 Kinect 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 PositConnect handle the delivery and DevOps 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 PositConnect. Visit pythonbytes.fm slash connect today and get a...

three month free trial to see if it's a good fit. That's pythonbytes.fm slash connect. The link is in your podcast players 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 Blackened 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 TypeHorror. It does not have a reformat according to rough style feature whenever I say tick, tick, tick, Python types and stuff, right? But this does. And so you can...

you can run this against all sorts of different things. So it says documentation and, 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, uh,

I'm working on that Python in production book from TalkPython, 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. 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 docstrings. Yeah. So docstrings 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 formatting the code blocks within your Markdown files to black style. There aren't black styles for Markdown. Yes, exactly. Okay. 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 do headings with the pound and pound, pound and, and, but Markdown allows the underscore the, like the, the dashed line line underneath it. And I, I hate that. It drives me crazy. 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. Okay.

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 for a little bit longer.

So I want to talk about reinventing notebooks as reusable Python programs. Have you heard of this? Merimo thing? Merimo, yes. I just had the founder of Merimo on TalkPython. Okay. Yeah. It's not out yet, but it's been recorded and available on YouTube. Okay.

This is sort of interesting. I'm like, 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 JSON form or something. It can look like Python, or at least with the Merrimo 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...

it's a different execution environment than saying Jupiter space lab or Jupiter space notebook. It's a different runtime. Okay. But they're, they're real similar. Okay. Got it. But I really like that. It's just, it's just, well, it's not just Python code. It's extra stuff. Also looks like they add some decorators to make it their, their environment, understand what it is. Like there's app dot cell and, and,

and at app.zel and at app.function. And, uh,

pause probably other stuff too, but some of the benefits of this are like incredible. So the, some of the benefits are that you can version with get easier. Well, you can do that with Jason too, but the diffs don't really make a lot of sense. Often the diffs are all over the place. You can test with pie test and that one, I'm like, really good. That that's what, that's been one of the problems because in the past that it,

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 doc test and some of the other stuff in there, embedding SQL and Markdown, like all the sort of stuff that you could normally do with Python, you can now still do with these. And it'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 PyOctane.

oxide. Okay. Pyridide 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 Jupiter, for example. I think it's got like a really beautiful style. You know, you can check out, well, this is old. I got to put Ferrari in here for Hamilton. And we 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 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. I was, but I, I'm misunderstood. I thought maybe it was just a new way to run Jupyter notebooks, but. Yes. But with a decent amount of new features, I mean, yeah. Yeah. 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. Okay. I'm trying to remember now how much integration there is between those, but yeah, I think so. Okay, cool. I'll investigate more. So anyway, I'm still pretty excited about it. It looks pretty neat. I'll have to play with it a bit. Yeah. Yeah.

Yep, absolutely. And 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 huge. Instead of getting a nice merge, you'll get two conflicts of giant embedded blobs and so on. Yeah. 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 know, and you can like skip over, you'll have like, you know, have little numbers on the side of which order it was running and be like one, seven, eight,

eight, 19, 14 or something, you know, as you go down and you're like, Oh, this, so this is reactive in the sense that every variable you create is like wrapped. It's not technically wrapped in a reactive, um, behavior thing. It's they use, um, they parse the Dom every time you run anything and they create relationships between cells. Say like, okay, cell 10 uses something from cell one and cell three. Um,

So if you run cell three, 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 or a little bit. Yeah.

Yeah, it'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, something fun, new to play with. Indeed, yeah, it's pretty cool. Yeah.

That's our items. Do you have any extras for us? I do have some extras. Let's see a couple real quick. PaiKon Taiwan, PaiKon 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 proposals.

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, OK. See, errata.

errata yes we have to have an errata how about you uh i got a couple things uh first off um uh pycon us announced that there's a refund policy for international attendees if uh if you qualify for um certain things that actually i'm just i'm just embarrassed as american that we have to do stuff like this but um

International travel to 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 very fairly cool refund policy details. So anyway, yeah.

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.

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...

That's 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 and...

Yeah. I, 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. Of the refund. 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, um, uh, I finally finished up, um,

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 really good at it and you really want to take off and get great at it, there's another section. And

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 PyTest is a separate course now you can just buy it separate and then you can grab part two and

and then part three but also part two is working with projects part three the booster rockets like 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 reason why the other restructuring that I did is 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 the whole... 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 can 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, 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? We boldly go and no one has gone before. Yeah. So, uh, last week's joke was around, uh, was a Star Trek Klingon theme. Um, and we had, who was it? Um, we had somebody from Holgi on Mastodon said, you, again, you probably already know this, but, um, uh, there's this thing called, uh,

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 week of, for the week 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. I think the perfect. Oh, no, we could. 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.

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, something funny. 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 everyone. See y'all later. Bye, Brian. Bye.