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 we'll 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 earbuds.
This is episode 399, recorded September 3rd, 2024. And I am Brian Okken. And I'm 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. 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. But let's get on with the show. Michael, what would you like to start with? I would like to talk about virtual environments. Cool. How about that? Yeah. Actually, this is a really fun topic. This comes from Hynek. He wrote yesterday an article. I feel like this is one of the things you write where it's 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 is entitled, Why I Still Use Python Virtual Environments in Docker. I was checking out this thing that Hynek wrote about using UV and its 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, GitHub issue, I guess. And there it's, you know, we've got Hynek jumping in. You've got Sebastian from FastAPI jumping in.
You know, there's like a bunch of pretty significant folks going, almost a little more help for us Docker people. So as I've talked about before, Python bytes and all the talk 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 happened to use this as well.
And I just thought it was really interesting to hear Hynek's recommendations and mostly on, on the whys. 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 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, why not just blast on the, 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 Hynek now going, yes, but let me write this down. So I, let's flip over to omnivore app because that's what you should be using. If you do long form reading and note-taking omnivores app. And this is great for notes. This is why I still use this, right? Like what's going on here?
Says as an overarching theme, my goal, Hynek's, 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? Okay. Yeah. So that's, that's fair.
And basically, this is, 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 is a virtual environment. You're like, ah, I know what that is. That's pretty straightforward. And this is Hynek's 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 in compiled languages, which is pretty interesting. Hmm. Kind of. Yeah, I can see the analogy. Yeah, exactly. 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, in your compiler. And then what you get out is the actual libraries, not a list of names and your code, potentially QIC files, pre-compiled, et cetera, 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 and in 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 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 --user version or whatever. Right.
That's kind of nice. And then finally, as a bonus says, I'll have no fury like how I feel about pip install --user. So, you know, anyway, it's, 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 Hennig did. So I really like this, 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 312 in a Docker container. How about that? That's 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, but don't tell me that I'm wrong. Yeah, sure. Okay. I think it's the vibes there. Anyway. Well, then 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, it's funny. Developer S is on the next line. That's funny. Anyway. Anyway. 2023. It's 2024. What's going on? Well, 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. Hey, Brian, before we go on, I have not seen this at all. I didn't even know they were out. Oh, really? Whatever I say is first reactions. I'm loving it. I'm getting new experience at this time.
Cool. And, well, did you submit the survey? 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. I can't. 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. Russ. 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 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 it's just more people are using Python. And Paul Everett notes that the drop in HTML and JavaScript might be, might show that 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 other, 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, it's no surprises. JavaScript, HTML, SQL, Bash, C++, down at the bottom. Let's see. Skip down a little bit.
How long, this is interesting, 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 25% less than a year. But if you combine the less than a year and one to two years, 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 is 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. Exactly. Yeah. Yeah. 37% 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. Let's see. Oh, look at this. Favorite Python-related resources. I think this is new this year.
I've got YouTube channels, podcasts, blogs. Of the podcasts, we've got Talk Python To Me. Congrats. It's not ordered. It's just the top, I guess. But I think it might be ordered. Talk Python To Me. Lex Friedman. It's a good one. Real Python people. Django Chat. I love those guys. Core.py. Python Bytes. And then Python Test. I was not expecting to have that show up. That's awesome. It 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 testing code. Just right-click on the page, Brian, and say edit, just inspect, and then edit HTML, and it'll be fine. Yeah. 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 Python Test, and you can click on testing code at that point. So let's just, I guess I'll leave it at that. 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. The use of programming, you see these problems at home, 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, no, what you use Python for, they've added some categories.
So 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 ML Ops added, and they're probably all- And data visualization, yeah. Yeah. So, and, oh yeah, design data visualization. Those are all, it's like tons of, that's what people are using Python.
So we could rename the podcast, the language that uses, that people use data analysis for, podcast or something, I don't know. Anyway. Where's testing? I think testing's in. Oh, testing has gone down to 23%. It's probably all. 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 it. Yeah, yeah. Well, when you're exploring data, you don't need to write tests. It's not, you're not going to keep it.
Throw it away anyway. Yeah. Your data doesn't have to actually be right. It could, it could be wrong. You're just like making decisions for the country based on it, but you know, whatever. Okay. Anyway, Okay. 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 two people around.
There's 6% of the people using Python two, which is, I don't know why, but anyway, two will not die. The, and I think that's pretty much, it's got, we went down 1% over last year. So that, I guess we're making progress. That long tail will take a while. of the other versions of the Python three looks like three 10, three 11, three 12 are the tops, which is what you'd expect, I guess. So it's good. 75, almost 75% use the last, last three versions. So this is great. And Python.org.
So most, most, most used way to install. So next year, we'll see about UV Python install. That's another one. that's because they had. Oh, that's true. And some others, right? Yeah. I might have the up to add that. I think that we'll probably see that with, there was like virtual environment stuff somewhere. Lost. Can we look at web frameworks real quick? I know you just scroll by them. Web frameworks, Flask, Django requests, 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. 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, yeah, Firefox or Flask. It's like, huh? Interesting. Anyway, well, it's like requests, uh, requests as well. Yeah. Yeah. I think it's wet in a web category, but if they feel, uh, convoluted, but nonetheless, Flask, Django and FastAPI. 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 realized if the FastAPI. So that's interesting. Well, David Lord's been doing a bunch of cool work on it and other people of, uh, cleaning it up and, uh, getting rid of some of the old stuff.
So I had him on talk Python to talk about, uh, the state of Flask and palettes in 2024. Maybe that's where I got my information from. I just listened to that. Like last week. Did you? Oh, nice. Good episode. Uh, test frameworks, pytest at the top, 52%. Yay. Um, built in default still carries a lot of weight there though. Unit test. Yeah. 25%. 2% for nose. That must be well, those Python two people using nose still. Maybe. I don't know. Same, same with this, like hypothesis. That's, and mock.
Those can be used with any of these things. but yeah. Um, yeah, exactly. And I, I would like to see the numbers from last year. I can't remember. I'll look those up. Um, I'm hoping that okay is in the list. We haven't talked about that, but we'll try to get okay at 2% by in a couple of years. Um, yeah. More, more fun stuff for data analysis, whatever date, lots of data science, half of its data science, but anyway, a fun survey. It's good to check out.
And, uh, especially look at, look around November. Then, uh, we'll, we'll bug you in a couple months to go take the survey for next time. So, yep. I always really look forward to this. It's, it's insightful. Yeah. All right. All right. Well, previously, Brian, remember you talked, 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 and cells, or I don't know, one of them times of things. And 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, well, like NumPy and pandas. That might make sense. And if it's not there, then say lovey. 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. I 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. And I imagine it must be based on the Pyodide, not the micro Python 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. 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 anytime any Python cells change. It can also run them independently. So cells containing Python are only rerun if the cells, cells modify. That's kind of interesting. Um, 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. And that, 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, you know, 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 can do really advanced things. That's pretty cool. Yeah. Yeah. So that's really cool. You can write your own little packages too. Exactly. Like your little, 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 supports better data types for working with NumPy. And yeah, I think that's, 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, install your own libraries 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, I'm the, the things that I know that 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. Oh, okay. So I'm imagining if you've got the X, the add-in installed and it sees the, 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.
Yeah. But I also don't know what happens if you share one of these with two people. Yeah. Yeah. Yeah. Yeah. Cool. Awesome. We were talking about David Lord and Flask already, but 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, with, with Python bites. Cause you, you have a, like what depend upon turned on and stuff.
I thought I turned it off. but it won't go off. I thought I turned it off, It's driving me nuts. So, um, 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, you're not really, you think you, you don't have to update the dependencies for applications with our requirements. That text file. You totally do. You have to keep those up, but for projects, um, for like libraries, we usually keep those open. We don't pin dependencies, but we do pin development environment and, uh, CI environment and all that stuff. And that's a lot of what he's talking about.
So the, the environments, or what he calls ecosystems are like the requirements file for develop 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 with, within CI workflows. So there's, there's things like checkout and, and the other, there's lots of, 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, uh, time, any bot times 20 applications, um, going on because of these, these, uh, dependent bots and things. And that's, um, and that's, and that's, uh, it, it could be more if you didn't pop, 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, uh, having to deal with that.
So, um, for a lot of these projects, what he's done is he's went down to doing it locally. The idea is then, um, you've got, you use talks or something. Yeah. He's using talks with, uh, with some labels to do some stuff. So locally he will run pip compile, um, to, to, to, to do a new development environment. And then, um, also GitHub actions. And there wasn't a local version available.
So he wrote GHA update, which, um, which is a new, uh, little act GitHub action updater, uh, that you can go out and look to see if there's any, any updates to your GitHub actions. So very cool. Thanks for that. Um, and then also pre-compute, um, doing an auto update for everything. So yes, this is a, 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, 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 of, or you look at the PRs and I'll say 500, 500 closed PRs, but there's only one real PR.
Yeah. But then there's also like, it's mind shift to the, the shifting, you're 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 when, 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 the, 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 don't, 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, for, 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 depend about stuff. Cause it's so, so wordy. There's a issue somewhere on GitHub. I can't remember on where are you going? 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 to 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, it's not, you know, missions or not, not flight control software for a spaceship. It's like, 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, if, if some of these things update, if I got six updates, I'll update them all. If all the tests pass, I'll look at it. Um, uh, it's fine.
Uh, 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. Yeah. Breaking for several reasons. Exceedingly rare that a change in a dependency will cause, cause a break. Cause you're only using a little bit of the app.
You're 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, you know, micro is here or something. And then processing multi multiple requests in a Reddit scenario. So even doing like web test stuff on it, it didn't surface those errors, you know? So it's just like, well, you know what?
We're going to roll that one back and wait till they fix it. Then I'll roll it back, you know, two, two, one step back, two steps forward and we'll be fine. And the way I were, I really usually get hit with, with deprecations. So I'll run, I'll run the test with, with all warrant, like deprecation warnings turned all, all the way up. so that, so I can see those. And then you can have the decision of, should I, 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. Well, 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. Uh, since I already got my screen up testing code, I already have it. Uh, 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, two part episode, two episode series. I don't know why. I just dropped the ball and didn't do part two. So, uh, 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 answer. 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, uh, this merged PR for Unidep. So Unidep manages dependencies across conda. uh, and pip managed environments. It's super cool. We talked about it in episode 366. Okay. We also talked about, uh, just path, which added a badge. See that? Python bytes, three, seven, seven. Oh, cool. Pretty cool.
Right. Remember we talked about that. Yeah. Well, this PR adds the badge. So if you go over to Unidep, you can see it's got IPI version, pytest passing, code coverage number stars, and Python bytes, 366. So we have a, 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, where again, do people get the code for the badge?
They can just, uh, 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, and then put in the link to 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 it on the Unidep 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 C called raindrop.io. I talked about omnivore. Have we talked about before, 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 it, 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, 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 and stuff like that. Anyway, people can 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. You know, 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. 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 will there was 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 was a followup 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, I don't know.
This is, I feel like this should be something people are aware of, that this kind of stuff is going on. Uh, but I don't know enough about it to take a side or have a strong opinion, but it seems important. Hmm. So, well, okay. Uh, just to, to make sure that we were aware that the, the post that they're talking about here did get put back. Okay. So it got put on, the post got put on timeout. Interesting. Okay. All right. Anyway, people can check it out. It's linked there.
Um, nearly final call for the coding in a castle in Italy. We put up a $500 last minute special. So, so got, uh, some seats left and I'd love to see you there and talk Python for six days and enjoy Italy together. So, uh, hopefully people can make that. I'll put that in a length as well. And that's all I got, Brian. Okay. Well, I want to show you that. So the, uh, the, this is the, it was a rake choice voting thing. And, and Guido said something, um, 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. 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 is pretty funny, right? Yeah. So this, I believe this is a, was a sidebar from a rust, a rust book. And, yeah, and the title is C will watch in silence. C is a watching you. And I can't unsee this image. 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 has been freed leading to undefined behavior. It'll watch in silence as you walk off the edge of a cliff. It will watch you. Do you feel, when has C watched you? Have you, has it watched you? C is watched. You do a lot of C. Yeah. Yeah, I write, I write a lot of C. Well, do you feel like it watches you? No. I don't know. That's the joke I got. Yeah, it's an entire tool belt and you can shoot yourself in the foot with it if you want.
But yeah, no, I mean, it's a fair point the book is making, but it's, yeah, we'll watch you in silence as you walk off the edge. Okay. I got another funny thing that, that sort of a comment from Marco says, if, if I recall correctly in 2022, none was the most second, most popular testing framework. Cry emoji. Well, I expanded the list and none is still 36%. It is still the, the second most popular. I love that they hit it. It was like, we're just going to put under the show more tab.
Yeah. 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 pytest combined. Yeah. Well, it's because mocking 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. Exactly. It will watch you walk off the edge of a cliff silently.
Yeah. So anyway, fun day today talking with you about Python. And 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.