Python Bytes - #322 Python Packages, Let Me Count The Ways

Episode Date: February 7, 2023

Topics covered in this episode: Packaging Python Projects untangle xml Thoughts on the Python packaging ecosystem Top PyPI Packages Extras Joke See the full show notes for this episode on the website at pythonbytes.fm/322

Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds. This is episode 322, recorded February 7th, 2023. I'm Michael Kennedy. And I'm Brian Ocken. I'm Calvin Hendricks-Parker. Welcome, Calvin. Awesome to have you here. I'm excited to be back. I love it. It's kind of my annual retreat. That's right. That's right. Your annual drop-in to share all your ideas with us.

You've got some good ones to talk about, I know. Also want to say thank you to Microsoft for Startups Founders Hub for sponsoring this episode. If you want to connect with any of us, me, Brian, Calvin, or even just the show, you can find us over on Fastedon. We're all over there, actually, on Mastodon. So you can find the links and show notes. And if you're listening but not watching, just go to pythonbystuffm.com slash stream slash live, where we will be streaming live every Tuesday, usually, but you can definitely subscribe to get notified there. Calvin, I know you've been here before, multiple times. You always come to put us to shame with your fancy camera that you got going. We love it. Tell people who maybe haven't

heard about you or met you before who you are. Sure. So I'm Calvin O'Neill-Sparker. I'm co-founder and CTO of Six Feet Up. We are a software development company that helps digital leaders transform their impact. We do a lot of interesting work now around impactful projects.

So it's like climate change, making the world a better place. In addition, I've started a couple of communities. So the IndiePi community here, local in Indianapolis. And then we kind of branched out from that climate change, making the world a better place. In addition, I've started a couple of communities. So the IndiePi community here, local in Indianapolis. And then we kind of branched out from that into some little local conferences into now Python Web Conference. So that's probably the big thing you'll hear from me

at least this month and next month. Yeah, we'll talk about that at the end of the show. But that's an amazing conference. I would say potentially more talks or on par as many talks as US PyCon. It's really a lot going on there. Last year, there were almost too many. Like, it was so good.

I just kept saying yes to everybody. This year, we pulled back a little bit. We had more submissions. We'll talk about this later. But it was really hard to choose. Yeah, it's tough to say no to deserving people. But at some point, you got to. no to deserving people but it's so much talent so many great people indeed all right brian kick us off um i just wanted to talk about packaging

today a little bit i've got i'm splitting it up into two segments but i really want to focus on right now on the pypa has a packaging python projects tutorial page um it's linked in the show notes of course but i think this is a good, it's really pretty good, well written. And so I want to point people in this direction. If you want to share your Python code with somebody else, packaging it is the right way to go, I think. And this tutorial walks through, it's not necessarily trivial to do it so and it i wish it was easier but it it's not bad so uh it walks through what you you know walks through setting up your directory structure um it's and then you have to have some package files with it you've got to have a license

file and a pyproject.toml now and a readme and then it talks about your source directory and your test directory um so you've got the directory set up and then what i about your source directory and your test directory. So you've got the directory set up. I know you're a fan of the source directory for packages. It looks like... Yeah, IPA as well. Exactly, your philosophy is winning out here as the official recommendation. Yeah, and I mostly, I used to have good reasons behind it.

Now I just like having the top level stuff just be packaging and having the actual source code be somewhere else in the source directory it just in it it's a while you're developing it's it's nicer if you have a single that there is like caveats though if you have a single file that you're just sharing that might seem like overkill and i i'm fine with of course i have packages as well that are single file that i don't do this with so you don't have to but most things most projects are going to have more than one file um if you're sharing it so um there's this so and then what do you put in it so it talks about what you put in the different things uh in the pipe project automo and a little bit

into the readme and some of the metadata um the The one of the things we're going to jump into a little bit later in the show is that there are lots of options for what build backend you use. This project itself or this document talks about hatchling, setup tools, flit and PDM. And neither of them look that different. And they kind of do the same thing but you can have different metadata that goes with it so um that's i think both a good thing that we have options and a bad thing that some people don't know how to choose so um is it really tough to like know why should you do it maybe setup tools probably shouldn't be the choice i

feel like that you know i of moving a little bit away from that. But yeah. The history here is so deep. I feel like there's a whole college course you could give on why these things are the way they are now. Yeah. Yeah.

So the project, the tutorial goes down into even distributing, so all the way down to recommending that you use Twine to upload to the test repository, test PyPI. And you have to get a token and it's not trivial and all this sort of stuff. So it's still a little daunting, but this will walk you through all the steps.

I have a personal opinion, of course, and my opinion is read this and then check out Flit. Because for simple projects, Flit is, I think, still the easiest. It replaces the build step with Flit build, and it replaces the creation of some of these files with Flit init, and it replaces the Twine upload with just Flit publish. And I use it on a few projects and I haven't had reason to switch yet. It's not perfect, but it's pretty easy for small projects. So I would say read both of these

if you want to share some Python code. Excellent. Yeah, very good recommendation. And I think people need guidance here because there are so many choices. There's going to be a lot of conversation in the python is based around this actually for sure yep all right let's move on though for right now real time follow-up here as of about 30 minutes ago ofek the creator of hatch and i are going to have a conversation march 1st on talk python so people

want to hear more about hatch that's coming up in about three weeks or so. But what do I want to talk about? Something fun. Last time we had the Unreple. This time we have the Untangle. So Untangle by ST Chris on GitHub converts XML to dynamic Python objects. So thankfully, we've largely moved past XML. And really, thankfully, we've largely moved past XML namespaces, because that just is a complication that never needed to exist. But there's still plenty of XML stuff out there that people have to work with. So here's a cool little library that people can use. So we already have XML support in Python through the element tree API, which is, it's pretty nice. It works well.

You give it a XML document, but then you do, you sort of navigate it through like child parent or dot attribute. There's like some, it's not the totally the cleanest, most straightforward API. So with this untangle thing,

you can treat it like a Python object that just dynamically adopts the nodes as fields of those objects as a hierarchy, right? So super simple. You just get it to parse either a URL, a file, or from a string, just an XML string. There's an example that it's just real simple. It has a root and it from a string, just an XML string. There's an example that is just real simple. It has a root, and it has a child node.

And on the child node, it has an attribute where it says name equals child one. Okay, so if you were to load that up with this untangle thing, you just, whatever you get back, you say dot root, because that's the first element. You want to say, for example, that name attribute. Say dot root, because that's the name of the root, is whatever the first element. Then the next element you wanted to say for example that name attribute say dot root because that's the name of the root is whatever the first element then the next element is dot child and then to get the attribute you just treat it like a dictionary and say bracket name and outcomes outcomes that value so that seems really really clean and nice it does look clean other than the

fact you're still dealing with xml yeah well i was just dealing with xml this morning yuck yeah absolutely so i suppose there's an api for enumerating things we have multiple ones right you could have child child child child with name one child with name two right as a a list of things in this xml um so it's there's probably you know maybe that's multiple ones i don't know maybe it's a list or something i have to look actually realize i didn't totally look into that. But it's a pretty cool library if people are doing things like that. They can definitely check it out. Here we go.

Maybe. I think I will try this out because I have used elementary. And it does the job. But I always thought maybe it could be easier. What's the speed like? Do you know anything on if it's fast, slow? Honestly, I would imagine what it's doing is it's probably using Element Tree. Yeah.

And just like a thin wrapper over top of it. But I don't know. Let's see. Oh, it's using defused XML. Sacks. Okay. I don't know anything about Sacks XML, but yeah. Okay.

Pretty interesting. No, I don't know anything. It doesn't, unfortunately, the readme doesn't have a lot of information about, you know, like its performance and other things. But yeah, they also have a blog post you can check out about why they built it, which is kind of neat. So also short and sweet. But check it out if that sounds like something

that would benefit you. That's very cool. Indeed. All right, over to you, Calvin. Something else that could benefit you is going to be MyPy is official 1.0 released. I think this was as of about a week and a half ago. So it's pretty new news, a ton of stuff here.

So for those who don't know, MyPy is the static type checker for Python, basically a Python linter on steroids. So if you are using type hints, this is going to be a great way for you to make sure your code is basically ready to go before it even runs. Something a lot of developers coming to Python from other statically or strongly typed languages really appreciate. And I think it's something that a lot of Python developers are moving to, especially with the surge in popular languages like TypeScript, because the IDEs are really supporting this so well. So you get a significant improvement in your quality of life if you move to a tool like MyPy and start using Python and Python hints. So type hints in Python.

There's some things to watch out for. So as this new release rolls out, they are changing their numbering scheme. It used to be like 0.999. They kept kind of extending this 0.9 beta release window. But it's actually now 1.0. It is not SimVer. So do not count on minor releases not having back-writing compatibilities, although they should be very minimal,

is what they claim. But some of you may want to be aware of if you are upgrading to this. And when you go in and pin your MyPy version, you want to be really explicit about it because they're going to make sure they announce those significant back-writing compatibilities in any kind of blog posts in the release

before that feature releases. So the idea is- You say it has like a gut feel-ver? Yeah, yeah, right. Like what's the official term? Yeah, it feels like a big release. Let's go ahead and change this part of the version. But on that same note,

they do have feature flags for this. So if there is a new big feature coming that is going to be a backward and compatible feature, the previous release notes will note it. The release will have it. There'll be a flag to turn it on so you can try it out easily in your workflow, see what breaks without having to downgrade,

re-upgrade, downgrade, re-upgrade. So you can actually turn it on and off and make sure it works inside your workflow and your process. Lots of performance improvements. So 1.0 is 40% faster than 0.991. There's about 20 optimizations in this list. And this is, you can see by my scroll bar, there's a ton of stuff that happened when they went to release 1.0. But some more things in here

that are nice features, for example, warning about variables before definition kind of goes along with this possibly undefined variables. So for example, B is never true, X never happens. You'll never be able to print X. MyPy will tell you about that before you ever run your code. So it's kind of like just a lot of those belts and suspenders, nice safety checks, keep your code nice and clean, combine this with, you know, tools like black and things like that to just have super tight code

that is easy to read for everybody. Some new features that are supported as of Python 3.11, the new self type is supported. So if you are having a method that returns an instance of the class, you can use the self type so that if you have a subclass, you get the correct subclass return instead of having to explicitly redefine that for every subclass you are doing. So more convenience methods for those who are diving deep into the typing system here.

The self-type is so good. It really cleans up a lot of problems. It was really janky. If you're inside the class, you put in quotes the name of the class. How's it supposed to find that one? Or if it's going to create a circular dependency, you've got to do weird things so yeah that's really really nice i i do wish that

python had like a two-stage parser aspect where it would say go through here's all the stuff that's defined in the class oh here's some type things and other reference we might not know what that is let's go all through and then go back again and see if we can figure out what that is you know but the way it works now is when you're in the middle of a class it that class doesn't exist yet because it's not done defining until you're at the end but if you got to say i'm going to compare this against another one of me well how do you say that in types self right that's what we got and i can see this like being rolled in to proper python it seems like at at some point. I just feel like types went on from being this pie-in-the-sky

idea to bolted-on type feature to it's really getting ironed out and really well supported by the community and really well supported by all the editors. There's some new params to bex stuff in here that I don't know too much about params to bex. We're not heavy into types yet. We're doing a lot with Django and doing some type hints there to start making some APIs.

But that's where we're still diving in. A bunch of new miscellaneous features. So if you are looking for features galore, that has happened in mypy1.0. There's a bunch of fixes to crashes. So this seems like it's a really robust release. Another important one here is going to be the Python 3.10 match statement support.

So it can compile those as well. So they're staying on top of all the recent language features, which is obviously what's needed to get momentum behind a project like this. I think anybody who's using type hints better using the MyPy stuff. For those who don't know, it's also supported by Dropbox. So when I said 40% faster,

that was actually running against the Dropbox main code base. So that's the benchmark against Dropbox itself. Interesting. Yeah. Yeah, MyPyC is pretty an interesting thing that opens up once you start to adopt types. For me, the main reason i use types in my world and i realize that i i live in a different world than a lot of folks but for me

it's really about making the editor tell me what it it should know already and not do i need to go look in that method does this actually take when it says user id is that a a string or is that a a bson from mongodb i can't remember what kind of thing this stores for this. It says, you know, and then, oh, okay, that's obvious, right? Just so you don't have to keep bouncing around. You just stay in the way you're trying to focus. And I love it. Yeah, it's extra smart.

So, I mean, if you're using a PyCharm or VS Code and you thought it was smart before, once you introduce these types in there, it gets even smarter. Absolutely. All right, awesome. Awesome one. Now now two pieces of real-time feedback one i found out with the untangle that if you have multiple want multiple nodes of the same thing like you would in an rss feed you have multiple posts or a blog post same thing for the post um the you just still say root dot you know main thing dot child or whatever the name of that node is,

that becomes a list instead of a single thing if there's more than one. Okay, so that's pretty interesting. And then the other one here is over to you, Brian. Jeff asked, can an old project be converted to work with Flit? And yes, probably, maybe. It really depends on the project some of it can be re you there's not that much to it right there's a pyproject.toml and a few

other things and it's probably not that much work to migrate it i guess yeah but i mean an old i'm assuming by old project it's a setup to an old setup.py setup tools project. And you could do anything in that. So if you were going crazy, you can't go crazy anymore. But if it was a fairly simple, straightforward, then yeah, probably. If you were going crazy, you get what you deserve. How about that? So, all right, before we move on to our next topic, let me tell you about our sponsor for this week, Microsoft for Startups Founders Hub.

Really great program. If you have a startup and you want to get tons of support, not just technical support, but also networking with people who have founded their own startups, then you should check out Microsoft for Startup Founders Hub. As Brian mentioned last time, we heard back from one of our listeners who signed up and had done several startups and said, I was a little skeptical, but this is a really great program. It's fantastic for us. And I just wanted to let you know how well it's working out.

So definitely a good program. People should check it out. So what it is, is Microsoft created this program to help people become successful starting a business. By some estimates, 90% of startups go out of business within the first year. That's not what you want for your startup. You want it to succeed. So with Microsoft for Startup Founders Hub, you get access to free resources. So this includes platform technologies like Azure, GitHub, a partner with OpenAI. I've heard ChatGTP is

catching on, so that's kind of cool. So you get access to some of the resources from them, which is fantastic, but you also get access to the mentorship network, which I think maybe is even the most important part. You get access to a pool of hundreds of mentors across ranges of disciplines, across areas like idea validation, fundraising, management and coaching, sales and marketing, and others. So you can go and book one-on-one meetings with these folks. And many of them are former founders themselves. So you can make your idea a reality today with the critical support you get from Microsoft

for Startups Founders Hub. Just visit pythonbytes.fm slash foundershub2022 to go apply. The link's in your show notes. You don't have to be VC-backed. You don't have to be third-party validated. You just apply. If they like what you want, it's free, and they'll take you under the program,

and you can get started. So thank you to Microsoft for supporting our show. And with that, Brian, over to you. Yeah. So go back to the same article for a second. Just scroll a little further down the same page. I got it. So within the same packaging Python projects thing,

there was, I have a reason to bring this up. But anyway, it lists a whole bunch of tools you can use for your build a backend. It's got pdm flit setup tools and hatchling there's another page on the same in pipey or pipey that is the packaging flow and this one talks about it as a more of a high level it's not a tutorial talks about the high level thing and there it lists all of those flit hatch, PDM poetry, sub tools, and then also trampoline and way, which I've not heard of.

So this, this can cause confusion. And that's really what we're talking about is I have, and I'm bringing this up because just independent of my involvement with Python bytes, I've, I've been involved with people having trouble figuring out how to package their Python code independently.

I've got a web developer doing it, a tools backend person, and then somebody that's just trying, he's a C sharp person that just was trying to package a front end to his tool, a Python front end. And he was like, I don't, I don't know how to do all this. And it, it is confusing. And it even is confusing for seasoned uh python developers and here we've got oh i didn't i didn't link it right now but there's um there was a uh doug hellman from uh module of the week posted that he was uh he's published lots of packages and he went to do it again and was a little lost and wanted some advice. So new people or people that are outside of the scope are confused. And I think it's fair to recognize that. And so there's a lot of

discussion around it. And Pradyon put together a blog post, was talking about it on Disqus. And he put together an article called Thoughts on the Python Packaging Ecosystem. And I think it's a kind of a fair discussion around it. And one of the points is that a lot of Python users are not software engineers, but we also have to recognize that a lot are. So it's a diverse ecosystem, and I think it's going to be a and I think it's gonna be a mess.

It's gonna be a mess for a while. And I think it's gonna be, I think it's good that it's a mess in some cases. It's good that we don't just have setup tools now. We have a lot of ways that are working on different pieces of the problem of how to make it easier around PyProject.tomlin. You can have a different build backend.

But he breaks down the points. It's a big article, but one of the things is it kind of unintentionally, the packaging ecosystem unintentionally became a competitive space that it is today. And maybe we need to make, the community needs to make an explicit decision if we should continue operating under that model that led to what we have now. We could pick from in different tools to do in different things. That's a good model, according to this, or in approximately the same choices to get a really bad user experience.

Bad for some people, good for others. And then also maybe we should pick a default because picking a default doesn't make the other approaches illegal. They just aren't the default. And I'm kind of leaning towards that. I think it would be good to have something, but I'm not sure what.

Longer down the line, pardon me, the scroll is pip. One of the ideas is maybe we should have pip. Well, okay, I'll back up a little bit. Some of these tools like Poetry and PDM are workflow tools. And other tools like Flit are more build flits more like i want to build just build a wheel it also does publish but mostly the the workload is around building the wheel um whereas pdm and poetry are like this whole workflow thing control your virtual environment um do a whole bunch of stuff and i know a lot of people from other languages like j and other, maybe Go, I don't know, are used to these high-end workflow things that do everything for you. But we're already used to a multi-tool model now, so I'm not sure how to get from here to there.

Interesting, it would be interesting to have PIP do it. I mean, we already all use PIP, so could PIP expand to do both the focus thing it's doing now installing a package um and and then also do some workflow stuff and i i guess i'd be kind of open to explore that idea but i was curious what you guys thought i'd be open to explore it i not to disparage anything but i personally dislike the things that try to put their workflow onto you i'd much rather have something simpler and someone who teaches python this is a huge problem for people getting into the language. They feel like it's a big challenge. Why is it so hard? Why do I have to learn all these things? I picked the wrong thing and now am I screwed? No, you're not out of luck. You just delete your

virtual environment and start over. But yes, things are a little, I think, I think having many of them, one is a problem. Yeah. And I think something that have forces workflows on you, I'm not a huge fan of, um, I feel like we we've already got lots of tools that solve it pretty well. I'm kind of not against pip doing a little bit more. I use pip tools for managing my dependencies and it is so good. It is so good. You state just your top level dependencies and when it's time to, let's see what new, let's make sure we upgrade to the new things. You just run pip tools upgrade and it'll regenerate. You can evaluate what the changes are. It's, I really, really like pip tools. I think it's, it's a much simpler scenario than a lot of them. And I know other people really like them, but anyway, this

is what I like. We could possibly leave pip alone and expand pip tools to do the rest of the workflow stuff yes potentially yeah it's like we could but i kind of agree with that like unix small tools do one thing really well which is why i've kind of gone with the the pip tools approach as well because i really feel like pip tools does such an incredible job at that dependency resolution and getting exactly what you need but way better way better and way faster like pip tools does such an incredible job at that dependency resolution and getting exactly what you need, but way better, way, way better and way faster than pip itself does. I think that approach that like flip takes, it seems like, I don't, I've never used flip, but the fact that it can just wrap around preexisting tools to provide a common interface

for, for users to be able to build package, push the whole, whole deal seems like really nice because it guides them through step-by-step that process until maybe at some point they don't need it or they just enjoy it. And it's using some of those standard tools behind the scenes. Yeah. I'm also with Michael. I don't like the predefined workflows that like, I'm not a huge fan of poetry necessarily because it just doesn't fit the way my brain wants to work down a project.

And I'm not surprised. So I was thinking an analogy of like, if you're going to have a pocket knife, which tools should be in the pocket knife? And if you go into like the medium pocket knives on the Victorinox site, oh no, it won't load. You get like tons, even the small ones. So the medium ones, you get like tons of different tools. Which tools should be there? Nobody's going to agree. And I thought, well, at least in the small ones, get like tons of different tools which tools should be there nobody's going to agree um and i thought well at least in the small ones maybe people can agree because oh no not even in the small ones people can't agree uh which should go together so yeah i want my um my

swiss army knife to also have drywall tools and something for my car but it seems like the combination though of really small tools to do one thing really well with some tools to layer on top of it whether it's your ide whether it's flit and you can have the opinionated workflows layered on top but they they rest on top of a solid set of identical tools that produce the identical thing yeah i i'm i'm in that camp as well that's where but i totally get that that's confusing for people oh totally confusing i mean the first time i go to explain to someone how they're going to manage like their dependencies on a django project i'm like oh my gosh i have to step back and think about the 20 steps that kind of go into how i learned to do this that

i'm now explaining to some new person i'm like like, I'm sorry, this doesn't sound easy at all. There's got to be a better way, but I don't know if there is. Yeah. Anyway, okay. Rabbit hole, but... Oh, totally. I mean, Python packaging is the ultimate rabbit hole in the Python community.

Yeah. Speaking of packages, Michael, do you want to jump into yours? I do want to talk about more packages. This is the simplified version, but also a bit of real-time follow-up as well. Again, I'm having many of the folks that were on that discuss thread that you mentioned, Brian, about this topic on TalkPython probably in a couple weeks as a big panel discussion about it. So if you all want to hear more of this, but for a long time, with the folks who are participating, and dive on in.

Okay. Oh, also, apparently, I said chat GTP, and I meant chat GPT, as Musharraf pointed out. So thanks for that. That's the one I meant. You know the one. All right. So there's this cool GitHub page, I guess, called Top PyPI Packages.

And so this is a pretty neat place. It shows you the top 5,000 most downloaded PyPI packages updated monthly. So you can scroll down here and you can say, show me the top 100, show me the top 1,000, whatever. I'll pull up the 1,000 for you, Brian. There you go. So these are updated over the last 30 days, and it actually says when it was last updated, and that was February 1st, which is a week ago as of this recording. So that's pretty fresh, really. And so you can find things like PyTest Check. Is that in here somewhere, Brian?

It's in the top 5,000, but not the top 1,000. Oh, okay. Did I get the wrong one? Sorry. I tried to pull you up there. But you see things like Boto3 and URLib are the most popular. So Boto3 is downloaded 522 million times every month, every 30 days or so, which is just insane. You got to be careful because some of these are really popular dependencies rather than directly really important libraries. Like I use Boto3 all the time as a dependency, less often directly. are really popular dependencies rather than directly really important libraries. I use Boto3 all the time as a dependency,

the less often directly. Definitely for your OLIB3, I don't think I've ever used it directly. But obviously, it gets installed. But I'm going to use many things. So this is pretty cool if people want to check it out. Calvin, what do you think? about this too because it's just thinking about the number of times the amazon cloud must go download photo 3 from like pi pi mind-blowing like there's all the serverless that's on server

someplace downloading packages in the background now you get a feel for it with a big number yeah it's really nuts which is also a little bit ironic because it comes from AWS and they send it over to PyPI and then it comes back to AWS. It's a weird world. Don't they use Fastly for their CDN? I think they use Fastly. PyPI? Yeah. I believe so. Yeah. It's like they have to go to a competitor to get like... Yes, exactly. Yeah. How interesting. So this is interesting in and of itself and it tells you which ones are there and there's an API which you can hit. Let's not interesting in and of itself. And it tells you which ones are there. And there's an API which you can hit. Let's not hit the minified one. Let's hit the non-minified one.

And it'll tell you actually returns when it was updated, what the query was, et cetera, et cetera. And so you actually can get this as a JSON endpoint, which is pretty cool. It's just a static file that gets updated every couple of days on this GitHub page setup. So that's a also an interesting way to think of an api my api is a static file that periodically gets refreshed but

there it is so uh you don't think you'll hear much there i kind of love it though that's just a kind of do too just yeah yeah think how scalable that bad boy is okay especially if you put a CD in behind it. And then related to that by the same person, there is HugoVic top PyPI packages on GitHub, which is a regular dump of the most downloaded packages from PyPI. So that sounds like, yeah, Michael, you told us about that. Thanks a bunch.

No, it's not the names. It's all of it. It's all of the data that is here. Where do they have it? This one? I don't know if I want to open this up, but it's really big. So it's all the XML. I'm not sure where it is in here, but it's all the XML files of, or rather, XML, the

JSON files that Untangle got me thinking XML. So it's all the JSON files of what comes out of the PyPI API, but all of them. It's when I checked it out and unzipped it and it was like 22 gigs on disk. So this is a big beast right here if you download it. Actually, no, this is not the right link. I'll have to find it. I'll put it in the show notes. But there's this guy. Darn it. This is the wrong one. But there's also linked off of this. There's one where you get all of the packages, which is, uh, which all the Jason for every package.

I'll have to figure out where I got that from. Unfortunately, it's the wrong link I pulled up, but anyway, these are both really cool resources and you'll have to check the links for that other one. Cool. Yeah. All right. Coming in at 57 on that list for the last 30 days is SQL

Alchemist. So for those of you who aren't familiar and do like Swiss Army Knives, this is the Swiss Army Knife of database tools. It's not only an ORM, but it has a whole SQL toolkit built into it. So if you've never touched SQL Alchemy, but do deal with databases, you may want to check this out. And more importantly, and this kind of ties in with my previous announcement on the MyPy 1.0 release, there's a lot more support in this release for types and typing. So there's kind of native out of the box MyPy experience has been improved. Now the author of SQL Alchemy, Mike Baer is actually going to be joining us in a few weeks here at Python Web Conference and giving a tutorial-length session on SQL Alchemy. He did this last time, two years ago, when he released 1.4. So for those of you who've kind of been following along in the

background, the 1.4 release was kind of the first half of this major revamp of SQL Alchemy into this new world. And so 2.0 is the second half of that revamp. So it's really been like four years coming for this major release of SQLAlchemy. So if you want to know what's new and hear it from the horse's mouth, Mike Baer is going to be joining us. And he'll be happy to answer all of your questions. Let's see. There's a ton of new things released in here.

I think if I scroll down. Yeah, so plugin-free, 484 compatible ORM syntaxes. So again, kind of ripping out the old stuff. All the typing support in here is all fresh. If you are using the MyPy plugins from before, you're going to want to take all those out. They're considered deprecated at this point. So that's something that's very important for you to consider. But now SQLAlchemy 2.0 is using all the new Python 3 wonderfulness of data classes, enums, inline annotations. It's just really a nice modernization of a really powerful package. Let's see what else was in here. There was a super important... Oh, yeah, some performance stuff. So

this all-new fully integrated ORM approach to bulk inserts is quite interesting. You will get a major speed increase, except if you're using MySQL. The MySQL folks have not implemented the insert returning syntax, but if you're on MariaDB, you're good to go. So that's something to pay attention to.

In addition to that performance, there's also the bulk optimized schema reflection. So if you were using SQL Alchemy, it was basically doing a table by table reflection if you were asking it for metadata about the tables. Now in all of the back ends, there is basically a, oh, sorry, I think it's only for Postgres and Oracle right now. So Postgres and Oracle support the bulk schema upgrades.

You can see right here for Postgres, a 250% improvement and for Oracle, a 900% improvement. I'm not sure what it was doing before, but it's a heck of a lot faster now at 900% improvement. Always a benefit there. And in addition, I'll kind of point out some other things that were in the migration guide and the what's new in 2.0 guide.

You're going to want to make sure you check those out here. There's like the migration process link from this article or blog post. You're going to want to make sure you read through those because there's major incompatibilities from 1.4 into 2.0. But the migration guide is really similar to like the 2.3 guide Python had. Tells you how to mechanically go through and make sure you're gonna be compatible for the latest version of SQL Alchemy.

Another speed improvement here is that all the native C extensions have been ported to Cython. Some of them are, they're all as fast. Some of them are slightly faster than their previous C extensions. But this also removes risks of memory corruption and stomping on each other and things that C does really well that you don't want. So that's also a nice benefit. And then the kind of

tying into that same benefit is the SQL Alchemy is now PEP 517 enabled. So that means the PyProject.toml file that we just saw in the last couple announcements is supported, which means when you're on your local machine and doing a source build of SQLAlchemy, it can automatically go grab some of the dependencies, such as Cython, which can be tricky to get installed for some people. So that is simplifying a lot of people's lives to go to SQLAlchemy 2.0.

Yeah, SQLAlchemy 2.0 is a huge release. Yeah, it's a big deal. It's been years in the coming. And it was in this intermediate 1.4 mode where you could choose either API, and they finally removed some things. But to me, the biggest deal is the async. Yeah.

Right? In the prior versions, there was just no way to do any async things, which meant on all the scalable areas, you were kind of stuck trying to find somewhere else to go. Now, if you really like SeekWalkMe, you can just use the async API.

Yeah. I think a lot of people are going to benefit from those types, all the type support in MyPy native support. Yeah, absolutely. And getting back to the editor. The Vulkan search have always been a hassle in ORMs. So it sounds like that's really gotten a lot of love, too.

Yeah, definitely. I look forward to it. I do as well. All right. Well, that's all of our topics. Brian, what do you got for us as an extra? I guess just one quick extra is like one of the things I've been working on on the side is I'm going to build a, I'm going to create a new build backend for Python and a new workflow tool. No. I'm not.

But what will you name it? Well, I think Flick. Because I always thought Flick should have been Flick. Like a little football. There you go. How about let's go to Calvin's extras. Sure. I kind of mentioned this in the intro, but we are putting on the Python Web Conference. This will be our fifth annual. So big five years. I'm wearing one of the jerseys from last year. You can't see it, but it was really awesome last year. We had 90 speakers. We had over 400 attendees, something like 23 or 22 time zones. It was really a global event. That's one of the things I'm really proud of. This event was meant to fill a hole,

I felt like, in the Python community for folks who couldn't travel, couldn't afford to go to an in-person conference or wasn't a regional conference near them. I know PSF's doing a lot of work right now in getting some regional conferences into other areas, but this is still and will always be virtual and always be accessible to folks.

So if you go and register and you can't afford to pay for this, we do have a grant program. We want to make sure that if you have a need to be in this room, you should be in this room and everyone is included. This year is going to be no exception. There's a lot of amazing speakers who have joined us. It'll be five half days from the 13th to the 17th. There'll be a keynote speaker kickoff every day,

a keynote speaker at the end of every day. And there's some awesome speakers coming up. We've got some people from GitLab. We've been focusing on finding some folks from Climate Initiatives to actually come and give some of our talks where they're using technology for good in these areas. There'll be a set of tutorials as well. So I mentioned Mike Baer's tutorial already, but there'll be three or four other tutorials as well. I know Matt Harrison's gonna be giving one of the tutorial not tutorial, he'll be giving a keynote this year. So he's back again from last year, he gave a keynote and a tutorial. Man's hardest working man Python. But we really appreciate him joining us as well. If you've got

questions, make sure you just go to pythonwebconf.com. You can also find me on, you know, CalvinHP on Twitter. There's also a Twitter account for Python Web Conf. So you can follow Python Web Conf on all the socials and join us. There'll be socials actually during the event as well. So it should be tons of fun.

We'll have just everything for the community. So I have a question right off the bat. It says Web Conf. If I'm not a web developer, am I still going to be interested in this or is it primarily web development? That's an excellent question, Brian. We originally, the web conf name meant a conference for web people, but we switched it around, you know, because we felt like this was an opportunity for the conference for Python to be on the web. And now we have app dev track, which is like not more than just web.

We'll have a cloud track. We will have a PI data track. It's actually officially sanctioned PI data event. And we have a culture track in addition to the tutorial. So there is actually something for everybody in the Python world here. And we're really trying to, again, I've mentioned filling the gap for people

who can't make it to specific conferences. We're also trying to, again, I've mentioned filling the gap for people who can't make it to specific conferences. We're also trying to fill the gap for talks that I feel are a little more on the intermediate to advanced level. If you're looking for very entry-level tutorials, this may not be the conference for you. I mean, there'll be great community, lots of questions you can ask, and there'll be tutorials. But I really wanted to make sure that the talks kind of scaled up that next notch. When I go to a lot of regional conferences or even PyCon, there's some entry-level stuff there that's great for people who are new to Python. This is that next step. Cool. I don't need to cut you off, but can we see if Michael's got any extras?

Yeah, I do. One, while Calvin's thing is up, I'm going to be speaking at their conference about making your Python web apps fly with CDNs, speaking of CDNs earlier. So I'm really excited about that one. That's a fun topic. But I want to tell you a couple of tips and tricks. I'll keep these short here, but they're kind of fun. So I recently discovered that with many of the browsers, like Vivaldi or Chrome, sadly not Firefox, honestly, that's one of the browsers, like Vivaldi or Chrome, sadly not Firefox, honestly, that's one of the reasons I quit using Firefox.

They support progressive web apps, which many people may know. But even if you have a thing that is not a progressive web app, you can install it as a standalone, from your perspective, application that lives in the doc. So the thing I got on my screen

and I linked to in the show notes is, here's my Vivaldi, but then i have my different mail clients i got proton mail and gmail i got the google calendar all of those are just regular web apps i don't think any of them are progressive web apps but if you right click on the tab you say create shortcut and say open in a window they become their own little app that you have you put on your doc or your taskbar or whatever so for example like here's proton mail running you can see again link in the show notes to the picture and it just looks like an app like you wouldn't know it was an app it does you'd think it was an electron js app

basically but so if you want to have those as separate things you're going to run in an alt tab or control tab over to there you go oh no i closed my browser my mail's gone again i got to open it back up right if that ever frustrates, here's a cool fix for it. All right. Also, speaking of Proton, I started using Simple Login. Have either of you all used this? No. So I have a pro account at Proton, which is like, I don't know, a couple dollars a month for a bunch of years.

If you pay like way in advance, I think it's not very much. But along with that comes this thing called Simple Logon, which every time you go to a website, I don't think I have the extension in this profile in my browser, but if you go to a website, it suggests, hey, we'll create an automatic fake one-off email address that gets sent to wherever you decide it gets sent to. And you can reply to it and it goes back through there and things like that.

It's really cool. So like if I went to arstechnica.com and I created it, it would be like some random thing at arstechnica-simplelogon-ish.io or whatever. So you kind of know where it comes from, but if you want to just delete that and make it mail stop or you can figure out if it's sold or whatever. So anyway, recommendation on checking that as well.

It's also open source. You can host it yourself if you like hosting email. I don't really feel like doing that. If you've heard about a new topic, if you've heard about all the crazy stuff with chips, the Chips Act in the US, similar stuff in Europe. If you've heard about Biden banning chips or the US government banning chips to be used in certain things, primarily in China. But there's a bunch of angles in which this kind of stuff is heating up, not just with the US, but primarily around the US. There's an incredibly

good documentary on YouTube called US versus China, the war you can't see that talks about the history of this. And it just reminds me of how much good stuff there is on YouTube. I mean, I know there's a lot of stupid cats falling off of chairs and like idiots, but hidden in there, there were some, this is a better documentary

than you would find on, you know, professional top tier television networks. It's really good. So anyway, if that's interesting to you i will i will second that uh documentary note um i have a 15 year old here who's obsessed with long form youtube and some of the things he has shown me just blow my mind like why the super conducting super collider didn't succeed eight hours of like documentary on that i was like yeah what yeah there's there is no more discovery channel there's no more history channel yeah i know they exist in name but not in what

they were where they actually have real science and real information they're just reality tv and other silly stuff so all right i know we'll get short on time brian so uh i'll go quick um talk python's hiring so i'm looking to hire somebody that does Flutter and Dart, not Python, because if it's Python, I'd be doing it myself. But if you're out there and you have experience with publishing apps and Flutter apps in particular to the various app stores, if you're used to working on like Android and iOS and others with Flutter, and you can show me an app in that store, I would love to work with you. I'm going to post this somewhere pretty soon, but I want to put it out to the community first because I'd rather hire somebody from our community than just some random person off the internet. And it's primarily to do a

complete rework of our mobile apps for TalkPython training. So that'd be a lot of fun. If people are interested, just email me, michael at talkpython.fm. That's it. Those are all my extras. Yeah. Nice. Calvin, thanks for being here. michael at docpython.fm that's it those are all my extras yeah nice Calvin thanks for being here thanks for having me I really enjoy it it's lots of fun I get to go learn new things

each time I come yeah we do every time we show up as well it's a lot of fun yep alright and Brian thanks as always

thank you bye everyone bye