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 Okken.
I'm Calvin Hendryx-Parker.
Welcome, Calvin. Awesome to have you here.
I'm excited to be back. I love 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 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 in the show notes.
And if you're listening but not watching, just go to pythonby.fm.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 Hendryx-Parker.
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 IndiePy community here, local 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.
You have, 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 it's so much talent.
So many great people.
Indeed.
All right, Brian, kick us off.
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.
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 it walks through what you, you know, walks through setting up your directory structure.
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.
So you've got the directory set up.
I know you're a fan of the source directory for packages.
It looks like.
Yeah.
Exactly.
Your philosophy is winning out here is 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.
So it just, it's a, 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, 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
if you're sharing it.
So there's this.
So, and then what do you put in it?
So it talks about what you put in the different things in the PyProject.toml and a little
bit into the readme and some of the metadata.
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, this project itself, or this document talks about hatchling, setup tools, FLIT and
PDM.
And they, 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 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 is it really tough to like, know why should you do it?
Maybe setup tools probably shouldn't be the choice.
I don't feel like that you're kind of moving a little bit away from that, but yeah.
The history here is so deep.
Like, I feel like there's like a whole day, a whole college course you could give on why
these things are the way they are now.
Yeah.
So the, in it, 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 by PI.
And you have to get a token and it's not trivial and all this sort of stuff.
So it's a little, it's still a little daunting, but this will walk through, walk you through
the, 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.
There's, 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.
So.
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 space 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, OFEC, the creator of Hatch, and I are going to have a conversation
March 1st on Talk Python.
So if 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 pretty nice.
It works well.
You give it an XML document.
But then you do sort of navigate it through like child parent or dot attribute.
There's like some, you know, it's not 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.
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 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 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 have 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 where you have multiple ones, right?
You could have child, child, child, child with name one, child with name two, right?
As a list of things in this XML.
So it's, there's probably, you know, maybe if there'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.
Yeah.
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.
It's just like a thin wrapper over top of it, but I don't, I don't know.
Let's see.
Oh, it's using defused XML.
Yeah.
Sax.
Okay.
I have no, I don't know anything about Sax XML, but yeah.
Okay.
Pretty interesting.
No, I don't know anything.
It doesn't.
Unfortunately, the read me 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 sweet, 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.
Well, something else that could benefit you is going to be, my pie is official one.
Oh, released, I think this was as of about a week and a half ago.
So it was pretty, pretty new news.
A ton of stuff here.
So for those, you don't know, my pie 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 type languages, really appreciate.
And I think it's something that a lot of Python developers are moving to, especially with like the surge in populative languages like TypeScript, because the IDEs are really supporting this like so well.
So it, you, you get a significant improvement in your quality of life.
If you move to a tool like my pie and start using my 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, you know, they kept kind of extending this like 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 backward incompatibilities.
although they should be very minimal is what they claim.
But something you may want to be aware of if you are upgrading to this.
And when you go in and pin your, you know, my pie version, you want to be really explicit about it because they're going to make sure they announce those significant backward incompatibilities in any kind of blog posts in the release before that feature releases.
So the idea is...
Do you say it has a, like a gut feel ver?
Yeah, yeah, right.
A season dance ver?
Like what's the official term?
Like, 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, there's going to be a backward incompatible 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, you know, 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 if you have a sub class, you get the correct sub class return instead of having to explicitly, you know,
redefine that for every sub class you are doing.
So more convenience methods for those who are diving deep into the typing system here.
The self type is so good.
Yeah.
It's really, it cleans up a lot of problems.
It was really janky to, you know, if you're inside the class, you put in quotes, the name of the class.
Well, how's it supposed to find, you know, 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 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, that class doesn't exist yet because it's not done defining until you're at the end.
But if you've 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 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 stuff in here that I don't know too much about.
We're not heavy into types yet.
We're doing a lot with Django and doing some type ins there to start making some APIs.
But that's where we're still diving in.
A bunch of new like miscellaneous features.
So if you are looking for features galore that has happened in mypy 1.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 310 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 ins better be using the mypy stuff.
For those who don't know, it's also supported by Dropbox.
So when I said 40% or no, yeah, the 40% faster, that was actually running against the Dropbox main code base.
So they're actually, that's the benchmark against Dropbox itself.
Interesting.
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 live in a different world than a lot of folks.
But for me, it's really about making the editor tell me what 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 string or is that a BSON from MongoDB?
I can't remember what kind of thing this stores for this day, it says, you know?
Yeah.
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 that extra smart.
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, two pieces of real-time feedback.
One, I found out with the untangle that if you have 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 posts.
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...
There's not that much to it, right?
There's 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 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 First 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 First 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 will check it out.
So what it 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 First Startup Founders Hub, you get access to free resources.
So this includes platform technologies like Azure, GitHub.
They partner with OpenAI.
I've heard ChatGPT 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/foundershub 2022 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 on to 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.
Okay, 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, Subtools, and HatchLink.
There's another page on the same in PyPI or PyPA that is the packaging flow.
And this one talks about it as more of a high level.
It's not a tutorial that talks about the high level thing.
And there, it lists all of those, FLIT, Hatch, PDM, Poetry, Subtools, and then also Trampolin and Way, which I've not heard of.
So 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 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# person that just was trying to package a front end to his tool, a Python front end.
And he was like, I don't know how to do all this.
And it is confusing.
And it even is confusing for seasoned Python developers.
And here, we've got...
Oh, I didn't link it right now.
But there was a Doug Hellman from Module of the Week posted that 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 Pradyan 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 mess.
It's going to be a mess for a while.
And I think it's going to be...
I think it's good that it's a mess in some cases.
It's good that we have...
We don't just have setup tools now.
We have a lot of ways that are working on different pieces of the problem of, you know, how to make it easier around PyProject.atomla.
And you can have a different build backend.
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 an...
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, you know, 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, of the scroll, is pip.
One of the top 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.
Flit's more like I want to build, just build a wheel.
It also does publish, but mostly the workload is around building the wheel.
Whereas PDM and Poetry are like this whole workflow thing, control your virtual environment, do a whole bunch of stuff.
And I know a lot of people from other languages like JavaScript, 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.
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, and then also do some workflow stuff?
And 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.
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 as someone who teaches Python, this is a huge problem for people getting into 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 having many of them, one, is a problem.
And I think something that forces workflows on you, I'm not a huge fan of.
I feel like 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.
I really, really like pip-tools.
I think it's a much simpler scenario than a lot of them.
And I know other people really like it.
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, 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
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 way better and way faster
than pip itself does.
I think that approach that, like, Flit takes, it seems like...
I've never used Flit, but the fact that it can just wrap around pre-existing tools to
provide a common interface for users to be able to build, package, push the 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.
But 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.
the 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, maybe people can agree.
Because, oh, no, not even in the small ones, people can't agree.
Which should go together.
So, yeah.
I want my Swiss Army knife to also have drywall tools and something from my car.
But it seems like the combination, though, of really small tools that 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 of it.
They rest on top of a solid set of identical tools that produce the identical thing.
Yeah.
I'm in that camp as well.
That's why.
But I totally get that that's confusing for people.
Oh, totally confusing.
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, 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.
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 Talk Python probably in a couple of 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, right?
And I meant ChatGPT, as Sharaf 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 or
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 pytestCheck.
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 URLlib 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.
Definitely for URLlib3, 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?
Oh, I'm excited about this too because just thinking about the number of times the Amazon cloud must go download Boto3 from PyPy.
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 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 also an interesting way to think of an API.
My API is a static file that periodically gets refreshed.
But there it is.
So you don't have to go hard on much there.
I kind of love it, though.
I kind of do, too.
Just a static file.
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 all the JSON 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, definitely.
Yeah.
All right.
Calum?
Coming in at 57 on that list for the last 30 days is SQLAlchemy.
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 SQLAlchemy, 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 SQLAlchemy, 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 SQLAlchemy.
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 SQLAlchemy 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.0 wonderfulness of like data classes,
enums, inline annotations.
It's just really a nice modernization of a really powerful package.
See what else was in here?
There was a super importance.
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 SQLAlchemy, it was basically doing a table by table reflection.
If you were asking it for metadata about the tables.
Now in all of the backends, 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 of the 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 linked 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 to 3 guide Python had.
Tells you how to mechanically go through and make sure you're going to be compatible for
the latest version of SQLAlchemy.
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 SQLAlchemy is now PEP 5.17 enabled.
So that means the PyProject.toml file that we just saw in the last couple of announcements
is supported, which means when you're on your local machine and doing a source build of SQL
Alchemy, 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 then 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.
It's 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 SQLAlchemy, 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 game back to your editor.
The Vulcan 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 the side
is 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 flit should have been flick.
So like a little football.
So yeah.
There you go.
So how about let's go to Calvin's extras?
Yeah.
Sure.
So 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, I think it was over 400 attendees, something like 23 or 22 time zones.
Like 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 the PSF is doing a lot of work right now and 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 is going to 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 the hardest working man in Python.
But we really appreciate him joining us as well.
And if you've got questions, make sure you just go to pythonwebconf.com.
You can also find me on 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 webconf.
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 webconf 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 PyData track.
It's actually officially sanctioned PyData 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 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.
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 that there 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 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 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 dock.
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 ProtonMail and Gmail and 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 put in your dock or your taskbar or whatever.
So for example, like here's ProtonMail running.
You can see, again, link in the show notes to the picture.
And it just looks like an app.
Like you would know it was an app.
You'd think it was an ElectronJS app, basically.
So if you want to have those as separate things, you're going to have running an Alt-Tab or Control-Tab
over to you.
There you go.
Oh, no, I closed my browser and my mail's gone again.
I got to open it back up.
If that ever frustrates you, here's a cool fix for it.
All right.
Also, speaking of Proton, I started using SimpleLogin.
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 away in advance, I think.
It's not very much.
But along with that comes this thing called SimpleLogin, 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 if I went to arstechnica.com and I created it, it would be like some random thing at
arstechnica-simple-logon-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 vs. 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 are some...
This is a better documentary than you would find on professional top tier television networks.
It's really good.
Anyway, if that's interesting to you.
I will second that documentary note.
I have a 15-year-old here who's obsessed with long form YouTube.
And some of the things he has shown me has just blown my mind.
Like why the superconducting super collider didn't succeed.
Eight hours of like documentary on that.
I was like, what?
Yeah, 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, I'll go quick.
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 the app 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 Talk Python training.
So, that'll 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.
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.
All right.
And Brian, thanks as always.
Thank you.