Python Bytes - #399 C will watch you in silence

Episode Date: September 3, 2024

Topics covered in this episode: Why I Still Use Python Virtual Environments in Docker Python Developer Survey Results Anaconda Code add-in for Microsoft Excel Disabling Scheduled Dependency Updates Extras Joke See the full show notes for this episode on the website at pythonbytes.fm/399

Hello, everybody. Hello, Michael. Hey there. We really should have kicked off the shift to Monday next week instead of this week, because this week's a holiday. We're on Tuesday. It was a leap Monday. Yeah. Or the reverse of that or something. Yes. Okay. So next week will be on Monday.

But it's good to be here. Should we kick it off? Let's kick it off. All right. Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds. This is episode 399, recorded September 3rd, 2024. And I am Brian Ocken. And I am Michael Kennedy. I always have to check the date because I write down in the notes what the date is,

but sometimes I start the notes a day early and I get the date wrong. But yeah, it is September 3rd. Anyway, thanks everybody for joining. Thank you everybody that has supported our work. This episode is sponsored by us, so please check out our courses and also thank you to Patreon supporters for helping out. If you'd like to connect with us you can always connect on mastodon the links are in the show notes um

and we also you can join us live if you check out pythonbytes.fm live you can see when we are next. It's usually upcoming, going to be on Mondays at 10 a.m. And finally, if you'd like to join the Friends of the Show list, or what that is is the email list so that you get mostly, you'll get the show notes with all the links to everything we talk about in your inbox, which is a good thing. So send that out. But let's get on with the show. Michael, what would you like to start with?

Michael Matzkoff, I would like to talk about virtual environments. Cool. About that. Yeah, actually, this is a really fun topic. This comes from Henik. He wrote yesterday in article, I feel like this is one of the things you write where you're just like, all right, I'll write it down. You keep asking me, I'll write it down.

So we can just have it there to point at. And that article isn't titled why I still use Python virtual environments in Docker. I was checking out this thing that Henrik wrote about using UV and it's project management features inside of Docker containers. And there's a bunch of funkiness. If you look at his article, he links over to a GitHub post, a GitHub issue, I guess.

And there it's, you know, we've got Henik jumping in. You've got Sebastian from FastAPI jumping in. You know, there's like a bunch of pretty significant folks going uh almost a little more help for us docker people so as i've talked about before python bytes and all the doc python things and other infrastructures running in docker these days it's glorious we've got one big server with eight cpus and 17 different multi-tier apps running on it's fantastic and i happen to use this as well and i just thought it was really interesting to

hear hennick's recommendations and mostly on on the wise okay because with Docker, the Python in the Docker container is really only going to be used for the particular app that's being shipped. Like you usually put just one thing into a Docker container, one app. And if you need two apps, you often run two Docker containers. So why not just blast on the built-in Python or something along those lines, right? Yeah, you're not trying to isolate from anything. So, yeah. Exactly. Well, I can just hear Henek now going, yes, but.

Let me write this down. So let's flip over to Omnivore app because that's what you should be using. If you do long-form reading and note-taking, Omnivore is that.'s what you should be using. If you do long form reading and note taking omnivores at, and this is great for her notes, this is why I still use this, right? Like what's going on here. It says as an overarching theme, my goal and X is not mindlessly follow some best practices that add complexity for questionable payoffs because a big tech developer advocates so at a conference but

to spend a lot of time thinking about what secondary effects things that you do and it's not so much about how many keys you got to press but how hard is it to reason about what's going to happen as a consequence of a particular setup you know. So that's, that's fair. And basically I says, look, people understand virtual environments really, really well. It's the whole goal of virtual environments is to hold a single application. If I tell you in documentation or a meeting or a walk or a course or whatever, Hey, what we're deploying as a virtual environment, you're like, ah, I know what that is. That's pretty straightforward. And this is next words words it's the closest thing that we have to an enclosed standardized and well understood application build artifact in python the

stretch he says but he thinks of virtual environments as the result of linking a dynamic binary and compiled languages, which is pretty interesting. Yeah, I can see the analogy. Yeah, I do too, totally. So you've got your Python source code, you've got your list of dependencies, that's kind of like your statically linked libraries in your compiler. And then what you get out is the actual library,

it's not a list of names, and your code potentially UIC files, pre-compiled, and so on so I think that makes a ton of sense it certainly seems that way to me and it's good to use the same tools and primitives that you have in development in a production so they're not vastly different and in development you typically use virtual environments so why not in production, right? Yeah.

Moreover, import complexity debugging says, did you know this? You maybe know this. I didn't know this, actually. If you pass dash capital I to Python, then it limits where the imports come from, and it will only import from either the standard library or the virtual environment and nothing else. As opposed to, say, falling back to,

well, it's not in the virtual environment, so it's in the Python path, or so it's in the dash dash user version or whatever, right? That's kind of nice. And then finally, as a bonus, it says, I'll have no fury like how I feel about pip install dash dash user. So, you know. Anyway, it's an interesting thing.

You can check this out. And I follow the same philosophy, but I didn't, in my mind, have it as crystallized as what Henning did. So I really like this take on it. And people who get this podcast, visit the website, or even just get the MP3, all that is happening through a virtual environment

running Python 3.12 in a Docker container. How about that? That's pretty cool. It is pretty cool. It is pretty cool. It is, it is. But I'm not trying to convince you to do anything. Kind of is.

But don't tell me that I'm wrong. Yeah, sure. Okay. I think it's the vibes there. Anyway, well done. People can check that out. Nice. I want to talk about the developer survey. This is done by the PSF and JetBrains.

And this is still not on the screen. There we go. There you go. The developer survey with the... It's funny. Developer S is on the next line. That's funny. Anyway, uh, 2023, it's 2024. What's going on? Well, um, they, they do this kind of at the end.

It's from November of 2023 to February of 2024 is when they're collecting it. So, and then they analyze it and come up with this cool thing. And so that's why we get it a few months later, which now we're ready. So anyway, let's look at some of the cool results. So this is pretty neat. They've got the contents broken out into all sorts of stuff. Python versions, data science. There's a lot of data

science stuff in here now. But there's a bunch of stuff I thought was interesting. We've got 85% of the survey respondents use Python as their main language versus secondary um hey brian before we go on i've not seen this at all i didn't even know they were out so really whatever i say is first reactions i'm loving it i'm getting new experience at this time cool um and uh well did you did you submit the survey yeah Yeah, I filled it out a long time ago.

I believe those numbers, the 85% main, 15% secondary, is identical to last year. I can't remember for sure, but it's very, very close. It's interesting. A lot of the results, they show what the last year's results were, but some of them they don't. They're just highlighted. So maybe you can probably get the data or something.

Anyway, the Python usage with other languages, I thought it was interesting that the JavaScript and HTML is down a little bit, just a little bit. It was 37%. JavaScript's 37% in 2022, and this time it's 35. HTML was 36, now 32. So it's gone down a little bit. Super interesting. You wonder if, is that an actual decrease in use of HTML and JavaScript? Are there more people coming into Python, like on the data science side,

that don't care about HTML and CSS and JavaScript? Maybe it's being diluted but not lessened, or maybe it is less. care about HTML and CSS and JavaScript. You know, maybe they just, maybe it's being diluted, but not lessened, or maybe it is less, I don't know. Yeah, I don't think it's lessened, I think just more people are using Python. And Paul Everett notes that the drop in HTML and JavaScript might show that data science

is increasing its share of Python. And I think that's true. The machine learning and data science is increasing its share of Python. And I think that's true. The machine learning and data science is taking, there's more people coming into that than web development, I guess. So I think that's there. The Rust was interesting because we talk about Python and Rust a lot and still it's increased, but it's still 7% of the respondents are using Rust also. But those 7% are doing some cool stuff. So go Rust. Anyway, usage with other languages, primary versus secondary.

Yeah, no surprises. JavaScript, HTML, SQL, bash, C++ down at the bottom. Let's see. Skip down a little bit. How long this is interesting when when especially when for people like you and me that train other people and teach other people stuff is to remember that a lot of people have only been using Python for a little while. There's, there's 25% less than a year. But if you combine the less than a year and one to two years, it's like, you know, it's like 40% have been using it less than two years. So you really can't assume that people know a lot of the Python history and stuff like that.

So the other thing that was interesting is absolutely new to coding, even if it's not Python, that's similar. It's like 50% of the population's under two years, or at least of the survey respondents. But I would have expected the survey respondents to be more edged towards experienced folks, myself. But it's interesting. Exactly. Yeah. 37% of Python developers reported contributing to open source. That's awesome. In the last year, that's actually higher than I would have expected. But that might be, again, the population of survey respondents. But yeah, interesting.

Most contributions are in code, 77%. 38% documentation. Only 33% tests. That's a bummer. We got to bring the tests up a bit. I don't know what this is. 34% of Python developers report practicing collaborative development that like pair programming and stuff like that maybe i don't know uh let's see oh look

at this uh favorite python related resources i think this is new this year um i've got youtube channels podcasts blogs um of the podcast we've got talk python to podcasts, blogs. Of the podcasts, we've got TalkPythonToMe. Congrats. It's not ordered. It's just the top, I guess. But I think it might be ordered. TalkPythonToMe. Lex Friedman is a good one.

Real Python People. Django Chat. I love those guys. Core.py. PythonBytes. And then PythonTest. I was not expecting to have that show up. That's awesome.

That is awesome. We've got three podcasts in that list. That's incredible. But I probably, I changed just this last weekend, I changed Python test back to test and code. Just right click on the page, Brian, and say edit, inspect, and then edit HTML, and it'll be fine uh yeah well i don't

know how to save it after that but it'll look fine for a little while well yeah so if you click on it it goes to uh python test and you can click on testing code at that point so um let's just i guess i'll leave it at that uh i'm not changing it again. It's sticking to testing code for a while. Anyway, okay. Do you use it for work or fun? 51% use it for both work and personal. So that's fun. Only 21% for just for work, which is cool

because Python is so fun, you should do it at home also, I guess. Once you learn programming, you see the problems at home, and you're like, that has to be fixed. There will be some code written that will fix this problem, whatever it is. Yeah. They added what you use Python for. They've added some categories.

It's hard to compare the numbers year over year because there's new categories. So some of the, it's hard to compare the numbers year over year because there's new categories. Like for instance, data analysis is still at the top at 44%, but it was 51 last year. But there's also data engineering and academic research and MLOps added and they're probably visualization. Yeah. Yeah. So, and, oh yeah. design data visualization those are all it's it's like tons of people that's what people are using python for so we could rename the uh podcast the the the language that uses that people use data analysis for podcast or something i don't know anyway um uh where's testing uh i think testing's in oh testing has gone down to 23 it's probably we have so many users now we don't need to test as much they can do it i think it's the data analysis people i don't think they test yeah

as much as they should well when you're data, you don't need to write tests. You're not going to keep it. You're going to throw it away anyway. Yeah, your data doesn't have to actually be right. It could be wrong. You're just making decisions for the country based on it, but whatever. Okay, anyway, a whole bunch of fun stuff through here. Oh, there's a whole bunch of stuff around doc data analysis stuff that I didn't really dig into,

but I did think that the Python version was interesting. There's still Python 2 people around. There's 6% of the people using Python 2, which is, I don't know why. But anyway, 2 will not die. And I think that's pretty much we went down 1% over last year so I guess we're making progress that long tail will take a while

of the other versions of the Python 3 looks like 3.10, 3.11, 3.12 are the tops which is what you'd expect I guess so it's good 312 are the tops, which is what you'd expect, I guess. So it's good. Almost 75% use the last three versions. So this is great. And python.org is the most used way to install.

Next year we'll see about uv-python-install. That's another one. That's because they had uv and some others, some others right yeah i might have to add that i think that we'll probably see that with um uh there was like virtual environment stuff somewhere i lost can we look at web frameworks real quick i know you just scroll by them web frameworks flask dests, FastAPI. Still don't know how these fit together. It's like, what language do you use? C++ or CSS? Like, uh...

Yeah. I don't know the question. So I'm going to say that because we have Flask and Django. We also have HTTPX, which is a client. It's like, do you use Firefox or Flask? It's like, huh. Interesting. Anyway.

Well, it's like Requests. And Requests as well. I think it's in the web category well it's like requests uh requests as well yeah i think it's web in a web category but if they feel uh convoluted but nonetheless flask django and fast api i think it is super interesting i think flask is gaining a lot of momentum for a second wind or fifth wind or however many winds it's had plus one It seems like it's getting a lot of momentum these days because I feel like it had fallen a little bit, certainly relative to FastAPI. So that's interesting.

Well, David Lord's been doing a bunch of cool work on it and other people of cleaning it up and getting rid of some of the old stuff. I had him on TalkPython to talk about the state of flask and palettes in 2024. Maybe that's where I got my information from. I just listened to that last week. Did you?

Oh, nice. Good episode. Test frameworks. PyTest is at the top, 52%. Yay. Built-in default still carries a lot of weight there, though. Unit test, yeah, 25%. 2% for Nose.

That must be all those Python 2 people using nose still maybe same with this like hypothesis that's and mock those can be used with any of these things but yeah yeah exactly and I would like to see the

numbers from last year I can't remember look those up I'm hoping that okay is in the list we haven't't talked about that, but we'll try to get okay at 2% in a couple of years. Yeah. More fun stuff for data analysis, whatever. Lots of data science, half of it's data science. But anyway, fun survey. It's good to check out. And especially look around November then. We'll bug you in a couple months to go take the survey for next time. Yep. I always really look forward to this.

It's insightful. Yeah. All right. All right. Well, previously, Brian, remember you talk, you had an article that you covered that was like, I done for Excel was not what I wanted it to be or something like that, right? Like, yeah, I wanted a replacement for VBA.

And what I got was advanced functions in cells, or I don't know, one of them times of things. One of the limitations, several of the limitations were somewhat annoying. One limitation was, well, you can pip install or you can import third party things from this shorthand list of a couple of them that are common, like NumPy and pandas. That might make sense. And if it's not there, then c'est la vie. So it goes.

The other one was that in order to run your code, you do your Excel things. Your Excel had to go and upload and actually execute your data and code in Microsoft Azure somewhere in a container somehow. There may be privacy concerns, but even just from a, I'm on an airplane, or I'm in a place that has crappy internet, or I'm at a coffee shop and don't have good internet,

but I still would like to do some work. All right, just any disconnected scenario whatsoever was not ideal. So the Anaconda folks who were providing some of the foundation for that through Anaconda, the distributable Python environment for that, they came out with this thing called the Anaconda code add-in for Excel,

which solves some of these problems. It's pretty cool. So what's, I guess for some people, the main takeaway might be that you can run it locally, which is pretty awesome. But I think what's more interesting is that this is based on PyScript. Remember PyScript, the WASM version of Python

on the front end? Yeah. Yeah. Yeah. And I imagine it must be based on the Pyodide, not the MicroPython version, which would make it pretty robust in terms of what it can do. But what's really cool about that is you can run it locally without any setup or install,

so you don't even have to have Python locally because it just grabs a WASM thing off the internet or ships with it, probably ships with it. And that's pretty cool. It also says it will run cells independently. So in addition to running Python cells in row major order, which is kind of tricky, meaning any cells with Python code will rerun

any time any Python cell has a change. It can also run them independently. So cells containing Python are only rerun if the cell is modified. That's kind of interesting. But this is the most interesting, a customizable environment. It allows you to basically pick any package from PyPI that can

execute on Wasm. So there's, you know, certain limitations there, right? Like if it's based on binaries that are not available or something that can't work, but that's a much bigger thing than the four or five packages that came with Microsoft Python for Excel or whatever the official name of that is, right? So this is really, really cool. On top of that, there's a init.py that fires up whenever you opened up the Microsoft Excel Python variant. With this one, that thing's static. It's just whatever it is, it is. But with this one, you can edit it. So for example, if you have functions that you often call and you want to be able just to quick have them and not retype them into every Excel sheet or whatever, you can

write little utility functions and other helper things and import libraries, you know, import whatever library as alias. And then you just have those automatically available. So it kind of sets up your spreadsheet for easy use. So you could do really advanced things. That's pretty cool. Yeah, yeah, so that's really cool. You could write your own little packages too.

Exactly, like you could create little helper functions and other types of things and not have to do them in the little editor window of Excel. Also, it supports better data types for working with NumPy. And yeah, I think that's about it. But if you were thinking this was pretty close, but it's not quite, you know, this might actually push it a little bit farther. Runs locally, based on PyScript. pretty close, but it's not quite, you know, this might actually push it a little bit farther. Runs locally based on PyScript. Install your own libraries as long as they run on PyScript. And honestly, this might even push PyScript to be better, right? Getting some people to adapt libraries where they're like, why would I do that before? Like, oh, now it works in Excel.

Okay, I'll do that. Now that seems like a big enough reason to work on compatibility with Wasm. Yeah, with both of these solutions though, the things that, I know you probably don't have the answer, but when sharing a spreadsheet with somebody else, do you have to have like a save or share requirements file or something like that?

Sort of. So, it does say this here. It does say once an environment is created, this list of IPI WASM libraries, like a requirements file, it will be pinned. So when users share notebooks, the spreadsheet will retain the exact environment

for all of the users. So I'm imagining if you've got this add-in installed and it sees the workbook or whatever it's called, it's probably got a list of some sort of startup code like based on this version of PyScript and Python and then here's the list of dependencies and it

probably just grabs it from the internet like a browser would and then goes. But I also don't know what happens if you share one of these with two people yeah yeah yeah cool awesome we were talking about david lord and flask already but um now i want to talk about a blog post he has so david lord depends he he keeps up a lot of stuff and he released a article called disabling scheduled dependency updates and I yes please I kind of see that with uh with uh with Python bytes because you you have a like what dependent bot turned on and stuff I thought I turned it off but it won't go off it's driving me nuts so um the what and the, what, and David's even had, so he's looked into, he's got,

um, like 20 active projects that he is, even though they're low activity projects, there's 20 projects that he's, um, keeping an eye on. And, um, and there's within those, a lot of them are like libraries. So you're not really, you think you don't have to update the dependencies. For applications with a requirements.txt file, you totally do. You have to keep those up. But for projects, for like libraries, we usually keep those open. We don't pin dependencies. But we do pin development environment and CI environment and all that stuff.

And that's a lot of what he's talking about. So the environments or what he calls ecosystems are like the requirements file for development environment. He keeps those up with pip compile. And then you've got pre-commit hooks because you're testing a lot of stuff and those hooks might update. So you have different hook versions. And then you also have GitHub actions within CI workflows.

So there's things like checkout and the other, there's lots of things you can do with GitHub actions. Those may have been updated. How do you keep track of those? So he potentially has three commits, any but times 20 applications um going on because of these these uh dependent bots and things and that's um and that's uh it it could be more if you didn't uh pull this down but he set everything up to only notify him once a month for these things. But still, even only once a month, that's like 60

emails at once a month and having to deal with that. So for a lot of these projects, what he's done is he's went down to doing it locally. The idea is then you've got, you use talks or something. Yeah. He's using talks with, with some labels to do some stuff. So locally, he will run pip compile to do a new development environment. And then also GitHub Actions. And there wasn't a local version available, so he wrote GHA update, which is a new little GitHub Action updater

that you can go out and look to see if there's any any updates to your GitHub GitHub actions. So very cool. Thanks for that. And then also pre commit doing an auto update for everything. So yes, this is like you might be a risk to like just update everything on a project. But the when should you do this? This is for development environment. So instead of having this this is for development environment so instead of having and this is the idea around it also if you've got a project that isn't doing a lot of development it'll look like there's a lot of development going on with the github history and it's just these dependency updates instead or you look at the prs and it'll say 500 closed PRs, but there's only one real PR.

Yeah. But then there's also like, it's mind shift too. The shifting how things work and remembering, you know, what your test situation is and everything for these projects is jumping around. So instead, it's like on a day when he's looking at something, he'll go, oh, these haven't been updated for a while. I'll go I'll go update while I'm working on it. I'll update all of these things. And then he can do that as one of the one of the commits on a day that he's working on it anyway.

So they so the activity looks is closer to when he's actually working on something. And I, you know, of course, like we're talking about, this is more important if you're... It's less important for development environment fixes because that users aren't affected by it. For libraries, if you have runtime dependencies, you really should be checking that more than once a month. But for development environment stuff, I think this is cool.

So I'm going to take a look at this as well i love it i'm going to make another effort to disable more dependa bot stuff because it's so so wordy there's an issue somewhere on github i can't remember on where you go and complain about nevada offer feedback and learnings. I believe there was one about, could we please have a digest instead of a separate email and a separate PR they're like, no, why would you want that? Because I like, I'm not quite as bad off as David.

Cause a lot of my projects and repos, I'm like, no, I'm not turning depend about on at all, but it's the important ones I did and I woke up this morning and probably 40, 40 PRs. You know what? Just tell me I could get some updates for this thing. I'm not going to do them one at a time. I'm not going to say, oh, you know what? Let me reschedule this week and we're going to go through one at a time. And we're going to see how they work, right?

It's not flight control software for a spaceship. It's a website. If it doesn't work, I'll roll it back. And I know what I'm using this stuff for. Like if some of these things update, if I six updates i'll update them all if all the tests pass i'll look at it and it's fine if if all if i've got good coverage and i'm really testing the heck out of something it should be fine if it breaks then i might you know take go roll look at that more closely but it's only usually going to be one dependency

that's mucking me up. It's not going to be breaking for several reasons. It's exceedingly rare that a change in a dependency will cause a break. Because you're only using a little bit of the app. You're just like, the last time that I got one was Mongo Engine updated and it wasn't dealing with multi-threading correctly.

And even their testing didn't catch it because it only appeared when you're doing like production web servers, like grain in or micro is here or something. And then processing multi multiple requests in a Reddit scenario. So even doing like web tests stuff on it, it didn't surface those errors, you know? So it's just like, well, you know what? We're gonna roll that one back and wait till they fix it.

Then I'll roll it back, you know, one step back, two steps forward and we'll be fine. And the way I really usually get hit with deprecations. So I'll run the test with all deprecation warnings turned all the way up so I can see those. And then you can have the decision of, should I deal with that deprecation right now, or should I, I can schedule it then,

turn that off and schedule the deprecation notice. It's not that it's broken. It's just, it's not going to run like this forever. I might want to use the new interface or something like that. Yeah. David, I feel your pain and thanks for writing the article. Yeah. All right.

Now we're done with our main topics. Yes. Now indeed we are. And I don't have any extra other than the note that I have decided to switch. So, okay, I'll just go ahead and do this right now. Since I already got my screen up. Testing code. I already have it.

Testing code.com. I had it up. There we go. Okay. Episode 221 was in June. And it was a two-parter. It's part one of a two-part episode, two-episode series. I don't know why I just dropped the ball and didn't do part two. So this week I'm planning on releasing part two so that people can, if they want to catch up, but it's now a testing code. Anyway, that's my close that loop. Excellent. Nice. All right. Well, I got a couple some highs and lows, if you will, Brian, and all in between. Okay, check. This is exciting. Check this, this, this merged PR for uni depth. So you need that manages dependencies across conda and pip managed environments. It's super cool. We talked about it in episode 366. Okay. We also talked about just path, which added a badge.

See that Python bytes 377. Oh, cool. Pretty cool. Right? Remember we talked about that? Yeah. Well, this PR adds the badge. So if you already, you need that. You can see it's got IPI version, PyTest passing, code coverage number, stars, and Python Bytes 366.

So we have another badge signing. I would point this out mostly to just say, hey, people, if we talk about your stuff and you want to link back to the episode, this badge is a cool way to do it. Okay, and where again do people get the code for the badge? They can just, well, actually you can look at that PR and it'll show you if you go to files changed. It's just this link, this image shields, badge, Python bytes, the number, the color. Yeah.

And then put in the length of where it goes to. Cool. Even, even links to the time when their topic was discussed. So that's pretty cool. Neat. So I would, I would say based on the unique depth and PR and just grab it from there or just grab the code from the read me. Cool. Cool. All right. Uh, we'll do this one next. Started using a scene called raindrop.io. I talked about omnivore. We talked about before, but it's like reminded people like you should

be using omnivore. It's awesome. I don but it's like reminded people like you should be using omnivore. It's awesome. I don't use it, but yeah, you should, you should be using a Brian. You should. But if you, if you had something like delicious, you remember delicious. Yeah. Or those things, things where you would save links and I don't, I mean, I don't hardly ever use my bookmarks in my browser because they're so, they're so

poorly poor to get to and stuff. Uh, the only reason I make a bookmark is maybe so auto complete for my browser address bar might pull something from there you know but i started using this thing called raindrop which gives you a whole bunch more options and it's kind of like a more modern delicious and from what i can tell it's got pretty strong privacy. For example, I think when you install it as a browser plugin, which you don't have to even, but if you did, it doesn't ask for access to the page content unless you enable certain features. Like it will completely download the page and save a history for you in case the page changes or goes away, the website

goes away, your bookmark will still have the content, stuff like that. Anyway, people want to check that out. It's pretty cool. I'll have to check it out. What I really want is a bookmark manager that like automatically deletes junk I haven't visited in like a year. Yeah, exactly. You don't seem interested in this anymore.

I, I, before I imported all my bookmarks into it, I had to do, I deleted like half of my bookmarks because they were, they were bad, I deleted like half of my bookmarks because they were, they were bad. They were old and duplicates and weird. All right. How about a little bit of drama? I don't want to talk too much about this, but I think it's worth putting out there. You can look into it and make from what it, uh, what, what for me, well will there's an incident where uh one of the core developers was suspended given a three-month uh suspension or something like that and i'm sure a lot of people have heard about this but then there's a follow-up or gita van rossum posted something referring to that person not even by name and their post was removed for violating the guidelines.

We're mentioning that. And I don't know. I feel like this should be something people are aware of, that this kind of stuff is going on. But I don't know enough about it to take a side or have a strong opinion, but it seems important. Well, okay. Just to make sure that

we're aware that the post that they're talking about here did get put back. Okay. Interesting. The post got put on timeout. Interesting. Okay. Anyway, people can check it out. It's linked there.

Nearly final call for the Codina Castle in Italy. We put up a $500 last minute special. So we still got some seats left and I'd love to see you there and talk Python for six days and enjoy Italy together. So hopefully people can make that. I'll put that in a link as well. And that's all I got, Brian. Okay. Well, I want to show you that.

So the, this is the, it was the rake choice voting thing. And Guido said something and he referred to the band person. And for some reason, that got hidden for a while and people were like,

why would you hide that? But it's not hidden anymore hidden anymore so yeah i'll just read the whole post i don't know much about voting systems but i know someone who does unfortunately he's currently banned maybe we can wait until his three-month ban expires and ask him for advice it doesn't seem that controversial to me no but anyway yeah anyway you know it's not funny though is it it's not very funny it's not well we need something funny exactly exactly well do you know i know you do some c programming c's pretty funny right yeah yeah so this i believe this is a was side from a rust, a rust book. And the title is, See, We'll Watch in Silence. See is a watching you.

And I can't unsee this image and so on. Side note, other programming languages. Hold on, you might say, other programming languages don't require me to think about lifetimes. Why does rust make it so complicated? The C programming language will happily let you access memory that has been freed, leading to undefined behavior. It'll watch in silence as you walk off the edge of a cliff. C will watch you. Do you feel, when has C watched you?

Has it watched you? C has watched me. You do a lot of C. Yeah, I write a lot of C. But do you feel like it watches you? You do a lot of sea. Yeah, I read a lot of sea. Do you feel like it watches you? No. That's the joke I got. Yeah, it's an entire tool belt.

You can shoot yourself in the foot with it if you want. Yeah. I mean, it's a fair point the book is making. It will watch you in silence as you walk off the edge. Okay. is making but it's yeah we'll watch you in silence as you walk off the edge okay i got another funny thing um that that sort of a comment from marco says um if if i recall correctly in 2022 none was the most second most popular testing framework uh cry emoji well i expanded the list and none is still 36%. It is still the

second most popular testing framework. It was like, we're just going to put under the show more tab 36% of the answer. None. Yikes. In fact, it's nearly beating

all other true test frameworks i think it is maybe all of the true test frameworks other than pi tests combined yeah well it's because mock and and doc tests or hypothesis and stuff don't yeah don't combine in that way, I guess. Yeah, none, 36%. Maybe that's the joke. Maybe that's the joke. The joke is the software you write without tests. Exactly. It will watch you walk off the edge of a cliff silently.

Yeah. So anyway, fun day today talking with you about Python. As always. As a reminder, next week, it will be Monday for everybody. We hope hopefully that's normal. Hopefully, hopefully. We'll see what the holidays do to us. See you later. Bye.