Hey there, thanks for listening. Before we jump into this episode, I just want to remind you that this episode is brought to you by us over at Talk Python Training and Brian through his pytest book. So if you want to get hands-on and learn something with Python, be sure to consider our courses over at Talk Python Training. Visit them via pythonbytes.fm/courses. And if you're looking to do testing and get better with pytest, check out Brian's book at pythonbytes.fm slash
pytest. Enjoy the episode. Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds. It's episode 255, recorded October 20th, 2021. I'm Brian Okken. I'm Michael Kennedy. And I'm Will McGuggan. Welcome Will. Thank you. Good to be here. I'm sure people know who you are through all you do with Textual and Rich. Could you do a quick intro? Sure, yeah. I'm software developer from Edinburgh, Scotland. Last couple of years, been working quite heavily in
open source. I built Rich and started work on Textual, which is an application framework using Rich. And I'm currently working exclusively on that. So I've taken a year off, probably more than that, to work on open source projects. I'm very excited about that. We're excited about it too. Yeah, that's fantastic, Will. I think we've talked about this offline as well, the success you're having with Rich and Textual and this opportunity you have to really just double down on this project
you created. And I know there must be thousands of maintainers of projects out there. If I could just put all my energy into this, and you're currently lucky enough to be in that situation, right? That's fantastic. Yeah, I'm very fortunate, actually. I mean, I put some money aside. I planned for this year. But things are really looking up. And I've been blown away by the level of interest from it. I mean, it gradually ramped up with Rich. People like that. I think there was a missing niche or
something which did that. But then with the Textual, people were excited about it. I mean, I put a disclaimer on the ReadMe that said it's not quite ready for prime time yet. It might break and it's in active development, but it doesn't seem to discourage anyone. They're very busy building things with it. So I'm excited. I want to take it to the next level. And to be honest, if I was doing it part-time like I was doing Rich,
it would just take too long. If it was evening and weekends, it would be two years before it was like 1.0. Yeah, and we're ready to use it now. So yeah, most people want to use it yesterday. Congrats again on that. That's cool. It's great stuff. You know, we've talked about over on Talk Python and people want to dive in. We've certainly covered it many times over here as well. So we're happy to spread the word on it. Yeah, Michael, let's kick off the topics.
I do want to kick it off. All right. How about we start with some awesome Python topic like C++? I like both of them. This is right in your wheelhouse, Brian. A lot of C++. So I want to talk about this tutorial article series, however you want to think about it, of wrapping C++ code with Cython. So the interoperability story with C and Python being CPython as the runtime is pretty straightforward, right? But C++ is a
little more interesting with classes and this pointers and all those kinds of things. So the basic idea is Cython is this thing that allows us to write very nearly Python code and sometimes actually just Python code, sometimes like in a little extended language of Python that then compiles down to C. And if that's the case, well, it's probably pretty easy to get that Cython code to work with C code. And then Cython naturally is exposed as Python objects and variables and whatnot. So that should
be a good bridge between C++ and Python, right? And it turns out it is. So this person, Anton Zedan Pushkin wrote an article or is working on a series of articles called wrapping C++ with Cython. And so there's this library called Yarkerl, yet another audio recognition library. And it's kind of like Shazam. It'll, you give it a small fragment of audio and it'll say, oh, that's Pearl Jam black,
you know, black by Pearl Jam or something like that. Right. Pretty cool. And if you look at it, it's got some neat C++ features, you know, Brian, feel free to jump in on this, but see that right there? Namespace. So cool. I love how they're writing like well-structured C++ code here. But basically, there's a couple of structures like a WAV file and an MP3 file and then classes, which have like a fingerprint and public methods and storage and so on. And so the idea is how could we take this and
potentially make this a Python library, right? Basically create a Python wrapper with Cython for it. So you're going to come down here and says, all right, well, what we're going to do is we're going to write some Cython code and Cython doesn't immediately know how to take a C++ header file, which is where stuff is defined in C++ and turn that into things that Python understands. So you've got to write basically a little file, a PXD file that declares what the interface looks like. So you write
code like this. Have you done this stuff before, Brian? No, but this looks pretty straightforward. Yeah, it's pretty straightforward. How about you, Will? I've never wrapped a library, but I've used Cython quite successfully. So it's a really good system. Yeah, yeah, I agree. I've done it, but not to wrap C++ code. No. So basically you do things like CDEF extern from this header, create a namespace, and then you have CDEF, a keyword CPP class. And then you get, what's interesting about this is
you get to give it two names. And you get to say, here's the name, I want to talk about it in Python. So CPP wave file. And then here's its name in C, which is YAR control colon colon wave file. And the value of this is they want to have a thing called wave file in Python, but not the C++ one, a friendly Python one, but it needs to use the wave file from the C library. So if you directly import it, then there's like this name clash, which I suppose you could fix with namespaces and all.
But I think it's cool that you can give it this name, this kind of this internal name and off it goes. Right. So then you def out its methods, basically like just here are the functions of the class. Same thing for the fingerprint and the storage and off it goes. And so all of this stuff is pretty neat. And yeah, this thing I'm talking about is called aliasing, which is pretty awesome.
Like it lets you reserve the name wave file and storage and fingerprint and stuff like that for your Python library without, even though that's what the C names are as well. So yeah, pretty straightforward. What was the next thing I really want to highlight? There's kind of this long article here. So the next thing they talk about is using this thing called extension types. So an extension is just a C structure or C++ library, and you create some class that is kind of a proxy to it.
So here we say C def Python class called storage, and then internal it has in Python language, you have to say C def. It has a C++ class called this. And then from then on, you just go and write standard Python code. And anytime you need to talk to the C library, you just work with this like inner pointer thing that you've created, which is pretty awesome. You just new one up in the constructor and the C++ thing. And then like it goes off to Python's memory management.
So you don't have to worry about deleting it, stuff like that. I guess you do have to sort of deallocate here, but that's, you know, once you write that code, then Python will just take it from there. Right. So pretty neat, a way to do this. And the library goes on to talk about how you use it and so on. So there's a couple of interesting things about like dereferencing the pointer, like basically modeling reference types in Python.
But if you've got a C++ library that you want to integrate here, I think this is a pretty cool hands-on way to do a Cython. Yeah, I think this looks fun. I'd like to give it a try. Yeah, definitely. Another one is Pybind 11. That might also be another option to look at. So I saw Henry out into the live stream there. So here's another way to operate seamlessly between C++ 11 and Python. So another option in this realm. Maybe I'll throw that link into the show notes as well.
But yeah, a lot of cool stuff for taking these libraries written in C++ and turning them into Python-friendly, feeling Python-native libraries. Well, you know, that's really how a lot of Python's taken off, right, is because we've been able to take these super powerful C++ libraries and wrap a Python interface into it and have them stay up to date. When you make updates to the C++ code, you can get updates to the Python. So you sometimes hear Python described as a glue language.
I think many years ago, that's probably what it was. I think Python's growing. It's more than just a glue language, but it's very good at connecting other languages together. It's still good as a glue language, though. Yeah, it's not just a glue language. It's a language of its own, I guess. Yeah. I was talking to somebody over on Talk Python, and I'm super sorry. I forgot which conversation this was, but they described Python as a glue language for web development.
I thought, okay, that's kind of a weird way to think of it. But R.I. said, well, no, no, look, here's what you do with your web framework. You glue things together. You glue your database over to your network response. You glue an API call into that. I'm like, actually, that kind of is what a website is. It talks to databases. It talks to external APIs. It talks to the network in terms of HTML responses. And that's the entire web framework.
But yeah, you can kind of even think of those things in those terms there. It's like a party where no one's talking to each other. And you need someone to start conversations. It's what Python does. Yeah, yeah. And I think also that that's why Python is so fast for web frameworks. Even though computationally, it's not super fast. Like it's mostly spending a little time in its own code. But a lot of time, it's like, oh, I'm waiting on the database. I'm waiting on the network.
I'm waiting on an API. And that's where web apps spend their time anyway. So it doesn't matter. All right. Brian, you want to grab the next one? Yeah, sure. Bump it on to topic two. Bump it on. So I've got, I just have a few packages that I support on PyPI. And then a whole bunch of internal packages that I work on. And one of the things that is a checklist that I've got is what do I do when I bump the version? And I know that there have been some automated tools before.
But they've kind of, I don't know, they make too many assumptions, I think, about how you structure your code. So I was really happy to see T-Bump come by. This was suggested by Cephi Berry. But so T-Bump is an open source package that was developed. Looks like it was developed in-house by somebody. But then their employer said, hey, go for it. Open source it. So that's cool. And the idea really is you just, it's just to bump versions. And that's it. But it does a whole bunch of cool stuff.
It does. So let's say I've got to initialize it. So you initialize it as a little TML file that stores the information in the configuration. But if you don't want yet another TML file or another configuration, it can also append that to the PyProject.com. That was a nice addition. You can combine them or keep it separate up to you. And so, for instance, I tried it on one of my projects. And I kept it separate because I didn't want to muck up my PyProject.tML file.
But once you initialize it, all you have to do when you want to add and bump a new version is just say T-Bump and then give it the new version. It doesn't automatically count up. I mean, you could probably write a wrapper that counts up. But looking at your own version and deciding what the new one is reasonable. That's a reasonable way to do it. And then it goes out and it patches any versions you've got. And then in your code, in your code base or your files or config files or wherever.
And then it commits those changes. It adds a version tag, pushes your code, pushes the version tag. And then also you could have these optional run things, places where, like, before you commit, you can run some stuff. Like, for instance, check to make sure that you've added that version to your changelog or your, if you want to check your documentation. So that's pretty cool. And then also you can have post actions. If you wanted to, I was thinking a post action would be cool.
You could just automatically tweet out, hey, a new version is here. Somehow hook that up. That'd be fun. Yeah. Grab the first line out of the release notes and just tweet that. Yeah. And then the hard part, really, is how does it know where to change the version? And that's where part of the configuration, I think, is really pretty cool. It just has this file configuration setting, if I can find it on here, that you list the source. And then you can also list, like, the configuration of it.
Let me grab one. So, like, the source and then how to look for it. So, like, it's a search string or something of what line to look for and then where to replace the version. And that's pretty straight. I mean, you kind of have to do some hand tweaking to get this to work. But, for instance, it's just a couple lines. It makes it pretty nice. At first, I thought, well, it's not that much work anyway. But it's way less work now. And then, frankly, I usually forget.
I'll remember to push the version. But I'll forget to make sure that the version's in the changelog. I'll forget to push the tags to GitHub because I don't really use the tags, the version tags in GitHub. But I know other people do. Yeah, that's nice. You know, Will, what do you think as someone who ships libraries frequently that matter? I think it's useful. I think for my libraries, I've got the version in two places, two files. So, for me, it's like edit two files and I'm done.
Probably wouldn't be like massive time saver. But I like the other things you can do with it, the actions you can attach to it. Like creating a tag in GitHub. So, I do often, quite often forget that. Especially for like minor releases. I sometimes forget that. So, that's quite useful. Yeah, it's the extra stuff. It's not just changing the files. But like Brian described, like creating a branch, creating a tag, pushing all that stuff over, making sure they're in sync. That's pretty cool.
Yeah. Yeah, good find. This does more than I expected when I saw the title. What do we go next? Will. Yeah, okay. It goes off on your first one. This is Close Ember, which is, what's the purpose? Portmanteau is when you put two words together. November and close. The idea is to help open source maintainers close issues and close PRs. So, is this like to recover from the hangover of Hacktober? Hacktober. I think so. I didn't do Hacktober this year.
I didn't either, no. No. Last year, I mean, I got a lot of PRs coming in. Some of them are of dubious quality. Some of them just, some of them are very good, actually. I did actually benefit a lot, but it does actually generate extra work. If you manage it, it's really great. But this is, it generates more work for you, even though it's in your benefit. But Close Ember is purely to take work away from you, work away from maintainers. You know, there's lots of issues.
I mean, I've been very busy lately and not kept an eye on the rich issues, and they've just piled up. Some of them can be closed with a little bit of effort. So, I think that's what this project is more of a movement than a project designed to do. It's designed to take away some of that burden from maintainers. And it's a very nice website here. There's a leaderboard on different issues. And it describes what you should do to close issues and PRs. The author, his name is Matthias Boussounier.
I've probably mispronounced that. He started this, and I think it's going to turn into a movement. Possibly it's too soon to really get big this year. But I'm hoping that next year, it'll be a big thing. It'll be after Hacktober, you can relax a bit because someone, you know, get lots of people coming in to, like, fix your issues and clear some PRs and things like that. I mean, sometimes it's maintenance.
It's just tidying up, closing PRs, which have been merged, and closing issues, which have been fixed, that kind of thing. So, I think it's a great thing. I guess I don't quite get what it is. Is it a call out to people to help maintainers? Yeah. Yeah. It's like a month-long thing, and it's almost like a competition that they've given. Yeah, they've got a leaderboard, right?
Yeah. Yeah. Yeah. Matthias is a core developer of Jupyter and IPython, so he's definitely working on some of the main projects there. Yeah. He probably understands the burden of open source maintainer. Even if you love something, it can be hard work. Too much of a good thing, right? But no T-shirt for this, at least not this year. I don't think they offer T-shirts. No, maybe next year. I wonder if you can add your project to this. I think you can tag your project with Closeember.
I think that's how it works. And then other people can search for it and decide which one they want to help with. All right. That's pretty cool. So another Brian, Brian Skin, sent over. Thank you, Brian. He's been sitting in a ton of stuff our way lately, and we really appreciate it. Yeah. Keep it coming. So this one is, the announcement is that scikit-learn goes 1.0. And if you look at the version history, it's been zero for, zero-ver for a long time with being, you know, 0.20, 0.21, 0.22.
So this release is really a realization that the library has been super stable for a long time. But here's a signal to everyone consuming scikit-learn that, in fact, we intended, they intended to be stable, right? So there's certain groups and organizations that just perceive zero-ver stuff as not finished, especially in the enterprise space, in the places that are not typically working in open source as much, but are bringing these libraries in.
You can see managers, like, we can't use scikit-learn. It's not even done. 0.24. Come on. All right. So this sort of closes that gap as well, signals that the API is pretty stable. Will, Textual is not quite ready for this, is it yet? No, it's still on zero because I'm kind of advertising that I might change a signature next version and break your code. Never do that lightly, but it's always a possibility.
So if you use a zero-point version bit of anything, you should probably pin that and just make sure that if there's an update that you check your code. Right. As a consumer of Rich or a consumer of Blask or a consumer of whatever, if you're using a zero-ver, you're recommending you pin that in your application or library that uses it, right? Yeah, exactly. I mean, you might want to pin anyway just to, you know, lots of bits of software working together.
There could be problems with one update here that breaks this bit of software here. But when you've got 1.0, that's the library developer is telling you, I'm not going to break anything backwards compatibility without bumping that major version number. If they're using Semver, but because there's lots of other versioning schemes that have the pros and cons. Yeah, like calendar-based versioning and stuff like that, right?
Yeah. Yeah. I think that makes more sense in an application than it does in a library. Calendar versioning. I think it might do, actually. How much calendar versioning makes sense for libraries? Maybe it does. I don't know. I think some projects that have shifted to Calver have recognized that they really are almost never changing backwards compatibility. So they're never going to go to a higher number. Yeah. It's strange that there's no one perfect system.
I quite like Semver, but by and large, it does what I need of it. But there is no perfect system, really. Yeah, I like it as well. Just the whole zero verb being for like something is on zero version, zero dot something for 15 years. Like that doesn't make sense. Yeah. All right. So as we're talking about the 1.0 release of scikit-learn, let me give a quick shout out to some of the new features or some of the features they're highlighting.
So it exposes many functions and methods which take lots of parameters like hist gradient boosting regressor. Use that all the time. No, not really. But it takes, I don't know, was that 15 parameters? Like 20, zero, 255, none, none, false. What? Like what are these, right? And so a lot of these are moving to require you to explicitly say min sample leaf is 20. L2 regularization is zero. Max bins is 255. Like keyword arguments to make it more readable and clear.
I like to make virtually all my arguments keyword only. I might have one or two positional arguments, but the rest, keyword only. I think it makes code more descriptive. You can look at that code and then you know at a glance what this argument does. Yeah, absolutely. Yeah, it drives me nuts when there's like, I want all the defaults except for like something special at the last one. And so I've got to like fill in all of them just to hit that.
And also I would love to throw out that this is way better than star star kwa args. Way better, right? If you've got 10 optional parameters that have maybe defaults or don't need to have a specified value, make them keyword arguments. It means that the tooling like PyCharm and VS Code will show you autocomplete for these. I mean, if it's truly open-ended and you don't know what could be passed, star star kwa args.
But if you do know what could be passed, something like this is way better as well. Very much more exclusive. Yeah, you have to type more. If you've got like a signature which takes the same parameter or something else, you just have to type it all over again. It can be a bit tedious. But it's very beneficial, I think, for the tooling, like you said. Indeed. Also for typing, right? You can say that this keyword argument thing is an integer and that one's a string, right?
And if it's star star kwa args, you're just any, any. Great. Okay. Or string any. Okay. So we also have new spline transformers. So you can create spline bezier curves, which is cool. Quintile regressor is updated. Feature name support. So when you're doing an estimator pass to a pandas data frame during a fit, it will, estimator will set up feature names in attribute containing the feature names. Right? So that's pretty cool. Different examples of that. A more flexible plotting API.
Online one class SVM for all sorts of cool graphs. Histogram based gradient boosting models are stable and new documentation. And of course you can launch it in a binder and play with it, which is pretty sweet. Congrats to the scikit learn folks. That's very nice. And also kind of interesting to get your take on API changes and versioning and stuff, Will. Oh, before we move on, Brian, I saw a quick question that maybe makes sense to throw over to Will from Anu. Don't go.
Everybody keeps asking this. So I've ordered a Windows laptop. For everyone listening, the question is when will there be Windows support for Textual? Yeah. I've ordered a Windows laptop. I've been working on a VM, but it's a pain to work on a VM. I've ordered a Windows laptop and that's going to arrive at the end of this month. And I don't know exactly when, but that'll definitely need that to get started. And in Siri, it should only be a week or two of work. So how about I say this year?
This year. After the month of configuring your laptop. That's true. That's true. I haven't used Windows in I don't know how long apart from a VM. I need to test it with a new Windows terminal, which is actually really, really good. Yeah. The Windows terminal is good. Yeah. I think it can be like a first class, like textual platform. The Mac works great. Linux works great. Windows has always been like a bit of a black sheep.
But the new Windows terminal is a godsend because the old terminal was frankly terrible. It hadn't been updated in decades. Yeah. The old school one is no good. But the new Windows terminal is really good. Also, just a quick shout out for some support here. Nice comment to Shar. Windows support will be provided when you click the pink button on Will's GitHub profile, aka the sponsor button. It's not a ransom, I promise. I do intend to do it. All right. How about some server stuff?
We talked, I can't remember, I think several times talked about how to use, how to develop packages while you're offline. Let's say you're on an airplane or at the beach or something with no Wi-Fi. I mean, maybe there's Wi-Fi at the beach, but not at the beaches I go to. That's because you live in Oregon and some of the most rural parts are the beach. If this was California, you'd have 5G. Yeah. Well, I mean, I could tether my phone to it or something.
But anyway, so Jason Coombs sent over an article using DevPy as an offline PyPI cache. And I got to tell you, to be honest, I don't know if it's just the documentation for DevPy or the other tutorials. It just threw out a few commands and they're like, you're good. That'll work. And I just never got it. I've tried and it just didn't work for me. But this did. So this tutorial is just a straightforward, okay, we're just going to walk you through exactly everything you do.
It's really not that much. For instance, he suggests using PipX to install DevPy server, which is nice. The T-Bump package as well suggested installing itself with PipX. PipX is gaining a lot of momentum. Well, especially things like, well, like, yeah, T-Bump or, well, or DevPy. I don't know if I'd do it with T-Bump because I want other package maintainers to be able to use it too. But anyway, this is definitely something you're just using on your own machine. So why not let it sit there?
And then, so you install it, you init it, and it creates some stuff. I don't know what it does when you init it. But then you, hidden in here is you run DevPy server also then. So it really is just a few commands and you get a server running. But there's nothing in it. There's no cache in it yet. So then you have to, you have to go somewhere else and then prime it. So you've got a local host and you, that it, it, it reports.
So you can export that as your pip index and then just create a virtual environment and start installing stuff. That's all you got to do. And now, now it's all primed. And then what you do is you turn off when, next time when you're, when you don't have any wifi, you turn off, you can run the DevPy server as, where is it? DevPy offline mode. And then there you have it. You've got a cache of everything you need.
So I tried this out, just on like, like, you know, installing pytest for my plugins and then, set it in offline mode and then, try it in the, all the installing the normal stuff that I just did worked fine into a new, new virtual environment. But then when I tried to do something like, install requests that I didn't have yet or something else, it just said, Oh, that's not, it's not a, I can't find it or something. It's a happy failure. So anyway, this, this instruction worked great.
I know DevPy can be, do a whole bunch of other stuff, but I don't need it to do a whole bunch of stuff myself. I just need it to be a IPI cache. Yeah, this is really neat. The init looks like it creates the database schema as well as allows you to set up, set up a user. Okay. I guess you could, you set up with some authentication that no one can mess with it and stuff like that. Apparently this works just fine for teams.
So you can set up, set up a server on like a, on just like a computer that in your network that, just runs as a cache. And then you can point, everybody can point to the same one. So, I mean, that, that, that would work as a really quick and dirty and not too dirty, just a fairly quick way for a local team to, to have a caching server.
Um, I'd probably even think about doing this for testing, even on one machine so that you can have multiple, like, you know, completely clean out your environments and still run, run a test machine and not hit the network so much. If you're pulling a lot of, a lot of different stuff. Henry Schreiner out in the live stream says, can we also mention that Jason, the article we're just talking about also maintains 148 libraries, including setup tools on PyPI. Oh, that's awesome.
So may know something about interacting with PyPI. That's phenomenal. I don't know how he finds the time to be honest. 148 packages. Um, he needs closed, closed Ember. Yeah. He needs a lot of closed Ember. Awesome. All right, well, what's this, last one you got for us here? Sure. So I, I found this, project on Reddit. Um, it's called PyPI command line. And I noticed it in particular because it used rich, but it is a pretty cool project. Um, it's notable because the, the author is 14 years old.
Like that's blown me away. Um, it's going to be that young and he's, he's done a very good job of it. Um, so it's, interface to PyPI from the command line. Um, you can do things like, get the top, top 10 packages. Um, you can search for packages. Um, you can say here's, I think that's a search, PyPI search rich. And that's, given all the packages that have got rich in the name, it's got a description, everything and the date. And here you can, PyPI info Django.
That gives you some nice information about the Django package, which it pulls from PyPI. Like the GitHub stars, the download traffic, what it depends upon, meta information like it's licensed and who owns it. This is really cool. Yeah. It's, it's, it's really nice. Um, here we have the description and that's rendered in, that renders the mark down right in the terminal. Um, I wonder how it does that. Um, I couldn't hazard a guess. It's got to use rich, right? I think it might. Yeah. And, yeah.
So it's, it makes good use of rich. That's how I, how I noticed it, but it is a very cool project in its own right. It also uses, questionnaire. Uh, so that's like a, terminal thing for, for selecting stuff from, for the menu. Um, so it does a bit dynamically and also has like a command line. Uh, to do it more from the, the, all the terminal. Yeah. I think it's well worth, checking out.
I think I want to check it out just for an example of using, using this sort of a workflow, not necessarily with PYPI, but with just sort of copying the codes. Yeah. Yeah. It's a really nice looking terminal user interface type thing. I think it could be really interesting for you to me, Brian, to just do like info on the various things we're talking about. Right. That'll, that might be fun to pull up as well.
Yeah. And there's, there's actually tons of times where I don't, I don't really want to pull up a web browser just to put up, but I do want more information just to help. I love the web, but sometimes you have to do a context, which if you're in the terminal, you're, you're writing commands and then you've got to like, switch windows and find the title, the bar and type everything in. Um, it's just a little bit of effort, but it can kind of like interrupt your, your flow when you are working.
Yeah. I mean, especially when you got like the whole, I've got like a big monitor and I've got them all, everything in place exactly where I want it. And there's no web browser. So if I want to look something up, I got to like, you know, interrupt that. Yeah. Or the browser he wants there, but it's behind a dozen other windows, dozen other web browsers typically. Exactly. Yeah. That's a good find. And, well done to this, this guy who wrote it at such a young age. Very cool.
I was just going to ask you if you have an extras, thing. So, yep. Do I have any extras? Ta-da! Here's my little banner extras. I, I do have some actually, Brian, a quick shout out. Um, Madison sent over a notice to let us know that high cascades 2022, their call for proposals is out. So if people want to sign up for that, it closes October 24th. So, you know, make haste, you've got four days, but yeah, still, closes in four days.
Yeah. So if you're thinking of preparing something, you got three days. Talks are 25 minutes long. It was a lot of fun. You know, we both attended this conference a few times it in the before times it was in Portland, Seattle and Vancouver. Uh, this, I'm not sure what the story is with this one. If it's going to be in person. I think it's remote, right? Yeah. I think so. At least I hope I'm not wrong. Yeah. I think you're right. Then, have you got your Mac book, your, M1 max?
Have you ordered that yet? I want one, but no. The $3,000. I would love one, but I have no idea what I'd do with it. You know, I'll, I just work in the terminal most of the time. Um, Hey, you know, it has that new pro, was it pro res? Something display where it has 120 adaptive, display Hertz display. So, you know, maybe. I think my monitor only does 60. So I don't know if I could use it, but, I have actually got textual running at 120 frames per second. Um, which is pretty crazy.
Yeah. That's pretty crazy. I did end up ordering one and, on my Apple account, I have this really cool message. It says your order will be available soon. MacBook pro available ship available to ship null. So, we'll see where that goes. See where that goes. But I think, I should have think how many people's orders I would be getting. I would get just like a stack of boxes outside. Did that Amazon or something? Yeah. Uh, and then I think also, I want to give a quick shout out to this thing.
This, code weavers crossover, which allows you to run windows apps natively on macOS without a virtual machine. It's like a, it's like an intermediate layer. So I think that that kind of stuff is going to get real popular, especially since the new M ones have like a super crappy story for windows as a virtual machine. Cause windows has a crappy arm story and you can only do our VMs over there. So I think that, things like this are going to become really popular. There's a bunch of cool stuff.
If people haven't checked out this crossover stuff, I haven't really done much. in it, but it looks super promising. I've like been on the verge of like, I almost need this, but I just run into VM. That's that. Anyway, those are my extras. Okay. Well, I've got a couple. Um, we've, we've brought up starship. Once I just, I broke down and I'm using starship. Now it looks working nice. And one of the things that installed when I, when I grew installed starship, it also installed I end.
I'm not sure why. So I started using my, I have also it was still in pain works great. I like it on my Mac, but I still don't think it belongs in Python tutorials. Anyway, burning still out on me whether or not it's any better than just downloading off of org. You're going to get tweets, Brian. You're going to get tweets. But I, I agree with you. I support you on this. And so, one of the things that was announced today is, VS Code.dev is a thing.
Um, so I thought it was already there, but apparently this is new. Um, if you go to VS Code.dev, it is, just VS Code in the browser. Oh, interesting. I think it was already there. Where does it execute? And where, where, where's your file system and stuff like that? Well, I think it's the same as like the, the, the GitHub code spaces. You press dot. Yeah. Okay. Got it. Um, so. It can use the local file system though, which I think is a difference.
Um, GitHub had this thing where you hit dot and it, it brought up, a VS Code, which worked with the files in your repo. But I think with this, it can actually use your local, file system. Wow. Yeah. Which makes it more interesting. I mean, it's great if you work on another computer and you just pop it open, you've got all your settings there. Yeah, exactly. And boom, you're ready to go. Yeah. Oh, that actually is quite a bit different then. That's pretty cool.
Yeah. Two use cases for me that, that I think I would use this, that seem really nice. One is I'm working like, say on my daughter's computer. She's like, dad, help me with this file. You know, there's help me with, something and I've got to open some file in a way that has some form of structure. And I, you know, she doesn't have VS Code set up on her computer. She's in middle school. She doesn't care. Uh, but I could just fire this up and, you know, look at some file in a non-terrible way.
Right. That would be great. The other is on my iPad. Oh yeah. Right. Like there's not a good, super good story for that. But this kind of like VS Code in the browser, other things in the browser, they seem really nice. Or if I was on a Chromebook or something like that, right? If I was trying to help somebody with code on a Chromebook, that'd be good. How about you, Will? Do you have any extras for us? Here we go. Python multi-threading, without the GIL. GIL stands for, global interpreter lock.
And it's something which prevents, Python threads from truly running in parallel. Um, it's, people have been talking about this for years and I've got a bit kind of, you know, a dismissive because every time it comes up, it never seems to happen because, there's quite a lot of trade-offs generally. Um, if you get rid of the GIL, you hurt single-threaded, performance and most things are single-threaded.
Uh, but this, looks like, the author, Sam Gross has come up with, a way of removing the GIL without hurting, single-threaded performance. I think they've got, it's to do with reference counting. They've got two references, reference counts, one for, the thread which owns the object and one for all the other threads. And apparently it's, it works quite well. And the great thing about this is...
Yeah, that's super creative to basically think of like, well, let's treat, the ref count as a thread local storage. And probably when that hits zero, you're like, okay, well, let's go look at the other threads and see if they're also zero. Right? Yeah. Yeah. And if this goes ahead and it's got, quite a lot of support, I think in the core dev community, I don't keep a, really strong eye on that, but, from what I from what I hear is, is, got a lot of support.
And if, if that lands, then we can get a fantastic performance out of multi-threaded code. You know, if you've got 20 threads, you get almost 20 times, performance. So that, that could be huge. Um, I've no doubt there'll be a lot of technical hurdles, from, C libraries and things. Um, but I'm really excited about that. I think, you know, performance improvements, the single thedded, they come in little fits and starts, you know, we get 5% here, 10% here, and it's all very welcome.
Um, but if this lands, then we can get like 20 times for certain types of computing tasks. Um, so I'm, I'm really excited. I hope this one, this one lands. I mean, you're talking about this. Oh, here, let's, let's get this multi-thread stuff. You know, you were just saying, what are we going to do with these new M1 pros and M1 max? I mean, 10 core machines, 30, 32 core GPUs.
There's a lot of, a lot of stuff that's significantly difficult to take advantage of with Python, unless something like this comes into existence, right? Exactly. If you have 10 cores, chances are you'd just use one of them. Um, I'm wondering if, if this goes in, whether it'll change, we'll need some other ways of taking advantage of that. Because, I think at the moment for most tasks, you'd have to explicitly create and launch threads.
Um, I wonder if there'll be advances where, Python could just launch threads and things which could be easily parallelized. Um, maybe I'm, I'm hoping for, for too much, but I've, I've no doubt there'll be some kind of like software solution to help you just, launch threads and like use all those cores and your shiny new, new max. There's a lot of interesting stuff that you can do with async and await. And there's also some cool thread scheduler type things.
But I think the, you know, much like Python three, when type annotations came along, there was a whole bunch of stuff that blossomed that took advantage of it, like Pydantic and fast API and stuff. I feel like that, that blossoming hasn't happened because you're really limited by the gill of the CP level. Then you go multi-processing and you have like a data exchange and compatibility issues.
But if this were to go through all of a sudden people were like, all right, now how do we create these libraries that we've wanted all along? Yeah. Yeah. I think that's it. I think, once you've got over that technical hurdle, all the, all the library authors, um, will be like looking for like a creative ways of using this, for speeding code up and for just doing more with your Python.
Yeah. I mean, with it, with every programming language, the jump from single threaded to multi-process is a huge overhead. So you don't do it lightly, but you could do it lightly with multi-threads. You don't have such a huge, overhead burden. It's very exciting. I was also super excited about this. So I'm glad you gave it a shout out. We'll probably come back and spend some more time on it at some point. Yeah. And, where is it?
Uh, somebody said, one of the exciting things about it is we didn't say no immediately. That's a very good sign. Yeah. Which has not been the case with some of these other ones because they were willing to sacrifice single threaded performance to get better multi-course performance. Like, you know, this is not a common enough use case that we're willing to do that.
I think actually, the, the solution the author came up with, it did reduce single, um, threaded performance, but he also added some unrelated, optimizations, which speeded it back up again. Exactly. I'm sorry. I fixed it. Yeah. Yeah. Yeah. Interesting. One more thought on this really quick. Uh, David pushing out in the live stream says the Gilectomy is like nuclear fusion. It's always 10 years away. Yeah. I hope hopefully it's not 10.
It's possible, but I think this is the biggest possibility since then to do interesting things, maybe already taking account that, you know, looked at it and didn't say no immediately to, this is a project from, this is a project Sam's working on, but it's supported by Facebook where he works. So there's like a lot of time and energy. It's not just a side project.
Third, Larry Hastings Hastings, the guy who was doing the Gilectomy commented on this thread saying, you've made way more progress than I did. Well done, Sam. So these are all good signs. That's fantastic. Yeah. Yeah. All right. Well, Ryan, are we ready for our joke? Yeah. Laugh. Definitely. See, this is optimistic because they're not always that funny, but I'm going to give it a try.
This one is for the web developers out there for those folks that work on APIs and probably have been working for a long time on them. So, the first one I got for us, I just found another one I'm going to throw in from, uh, inspired by the live stream, but this one is entitled the torture never stops. All right. Okay. So it's a, every one of these, it's four different pictures in this cartoon.
There's a, there's a different developers up at the board describing some new way to talk to web servers from your app. So way back in 2000, it says soap, simple object, object access protocol. Soap makes programming easier. And the developer in the audience like WTF is soap. Oh, come on. What is this? Crazy namespaces in XML. Skip ahead 10 years. Now there's a developer up here saying rest representational state transfer. Rest is better than soap. The developer now as WTF was wrong with soap.
2015 graph QL graph QL is more versatile than rest. WTF. I was just getting the hang of rest. 2018 GRPC. GRPC is faster than graph QL. WTF. I thought you knew by now that torture never stops. Like the guy next to the other developer that's been complaining for 20 years. I think that that hits a bit too close to home. But if you're a JavaScript developer, that gets compressed into like the last six months, I think. That's right. You've lived it really hard, really intensely.
Nick says, let's just start over with soap. Yeah, pretty good. Pretty good. All right. And then we were talking about VS Code.dev and how you just press dot in your browser and GitHub or how you go to that URL and so on. How cool was. And somebody said, oh, it doesn't work in Safari. So I want to come back to this joke that used to be applied to IE. But now I think it should be applied to Safari. Like genuinely, I think it should be. Is it's the browser wars as a cartoon.
So there's Chrome and Firefox. It's a little dated because Firefox is not as popular as it used to be, sadly. But it's like Chrome and Firefox are fiercely fighting. And like IE is in the corner eating glue. I just feel like that needs a little Safari icon and we'd be good. Yeah. We'd be all up to date in 2021. How do you know it's IE? It has a little E on it in a window symbol. Oh, okay. Well, the E, of course, is backwards because the shirt's probably on backwards or something.
Also, it's eating glue. Yeah, true. Funny. So thanks, Will, for joining us today. This was a really fun show. Thanks, everybody in the chat for all the great comments. Thanks, Brian. Thanks, Will. See you all later. Thanks. Thanks, guys. Bye-bye. Thanks for listening to Python Bytes. Follow the show on Twitter via at Python Bytes. That's Python Bytes as in B-Y-T-E-S. Get the full show notes over at pythonbytes.fm.
If you have a news item we should cover, just visit pythonbytes.fm and click submit in the nav bar. We're always on the lookout for sharing something cool. If you want to join us for the live recording, just visit the website and click live stream to get notified of when our next episode goes live. That's usually happening at noon Pacific on Wednesdays over at YouTube. On behalf of myself and Brian Okken, this is Michael Kennedy.
Thank you for listening and sharing this podcast with your friends and colleagues.