Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.
This is episode 317, recorded January 3rd, 2023, and I am Brian Okken.
Hello, I'm Michael Kennedy.
Welcome to 2023. How exciting.
It is very exciting. It's a lot like 2022, but I think maybe a little more optimism. We'll see.
Yeah, but I've had one extra shower since 2022. Do you remember 2022? It just feels like a few days ago.
It honestly, it really flew by. Yeah.
I mean, we stayed inside for like two years and they're like, hey, look, we're going to go outside.
Oh, time flies when you're not just stuck inside.
I even actually rode a bicycle the other day.
Nice.
And then Oregon said we're going to rain for two weeks.
Of course. Of course it did.
Yeah. Well, let's kick it off. What do you got for us first?
All right. Let's talk about the Stack Overflow 2022 developer survey.
Now, this is one of the better surveys that gives you a pulse on the developer community.
It's, you know, we do the PSF survey every year and that one I think is really well done.
This one's interesting because it's not just Python, obviously.
It's all of Stack Overflow people.
Yeah.
And it's really, really long.
Notice the scroll bar.
So I'm going to try to go through these and just hit on some of the high points for us.
All right.
So they did that as well for us at the top here.
They kind of summarized some little things you can call out in the jump to other sections saying,
learning to code online increased by 10% year over year.
However, respondents older than 45 years are most likely to have learned from books,
whereas the youngins are more likely to use some kind of online course or, you know, YouTube video or something along those lines.
Does that surprise you?
No.
Yeah, me either.
So last year they said we saw Git rise as a fundamental tool of software development.
So like if you are a software developer, you basically just need to know Git.
Surprisingly, this year they said that's Docker this year, increasing from 55% usage to 69% usage.
And I kind of feel like the hype and the heyday of Docker was actually a couple of years ago.
And I hear a little bit less, maybe it's just less hype, but it's just more like, yeah, we're just using it.
But I don't know that that was surprising and interesting to me.
I'm using it more in places where I didn't used to.
Like what?
Build chains for just to keep them consistent.
We're just, and it isn't even a cloud thing.
It's just having, being able to have a consistent build system no matter what machine you're on.
Yeah, that makes a lot of sense.
CI systems are utilizing Docker more.
Sure.
I've heard of even people using Docker to manage and employ.
Is that how you would phrase it?
Little apps to Raspberry Pis for like home automation and stuff.
Really?
I'm sure there would be more of that if you could actually get a Raspberry Pi, but you know, this is more of a theoretical.
Those who already have the Raspberry Pi.
The most, one of my favorite sections of this is the most loved, most dreaded and most wanted.
Yeah.
Because it really tells you, you know, how do people feel about how things are now and how do they feel about where they're going?
Right.
What, what would they do if they were unencumbered by, you know, their boss saying, nope, we're using this particular database or nope, it's all Angular.
And you're on the team that does Angular, so I don't care what you want, you're doing Angular, you know?
And so Rust is on its seventh year as the most loved language.
Seven years?
Is it even seven years old?
I know.
That's my thought as well.
Okay.
Seven percent of developers saying they want to continue using it.
Wow.
I mean, yeah, anyway, that's pretty interesting.
But it also, Python and Rust are basically exactly tied as the most wanted programming language.
That's cool.
I can see that.
Yeah, absolutely.
Phoenix.
Phoenix is some web framework I've never heard of that is apparently the most popular.
AngularJS, it continues into its third year of being the most dreaded.
All right.
What else?
Go ahead.
Oh, just React.
Yeah.
It's most wanted, but who knows?
Yeah, exactly.
So some of these questions and some of these phrasings and analyses are super, super good,
and others are really bad.
So I'll try to highlight some of these.
So let me jump down here.
Well, I don't really care about the education stuff.
Education.
Education profile.
It tells you things like, yeah, there's an insane number of guys versus women.
No, that's fine.
I just thought it was funny that you said I don't care about education.
No, I don't.
Teacher, you know, leave the kids alone.
All right.
So no, like it's fine, but it's, you know, people can check it out if they care about it,
right?
Like there's stuff about the demographics, like age and gender.
That is pretty interesting.
I wish some of these numbers were better.
Like, yeah, it totally is.
Right.
But, you know, that's also not news.
So, yeah, some of the most popular technologies here.
Now, I know, Brian, I might just be getting older and grumpy, but when I look at this,
there's like, it's almost all these responses are broken into two segments, professional
developers and learning to code people.
And the default is to take all those together.
And I guess that's the biggest picture.
But I don't know.
I just, when I look at this, I'm just like professional developers tell me about this.
Like, you know, if some, if you're on your third week of a coding tutorial and that tutorial
says use this, like how, how much does that really speak to the state of the community?
I don't think it, you know.
Agreed.
So I'm checking, like when I think about these, I'm just going to check professional
developer.
And if you want the same numbers, you can do so as well.
So where are we?
We are on programming languages, scripting and markup.
JavaScript is definitely the most popular here.
This is one of those areas where I don't, I think you need to phrase it a little bit different.
Let's see what the question exactly is.
Which programming languages have you done extensive development work in over the year, over the
last year?
Okay.
I, I don't know how quite how to solve this problem, but there's a ton of Python people
who did JavaScript work.
Yeah.
There is a ton of C++ people who did SQL, right?
There's also Python people who did SQL.
So SQL ranks above Python, but there's very few people whose job it is as a developer to
write SQL and not use something else.
Right.
So that's, it's weird to have SQL even in there.
Yeah, I know.
Well, HTML and CSS, right.
Is, is like a little bit weirder as well.
And so I feel like it should say like, what is your primary programming language or something
like, you know, something like that.
Right.
I feel like it's, it's, it's kind of like favorite movie.
Like what's your favorite movie, but not princess bride.
Other than that, what's your favorite movie?
Yes, exactly.
Exactly.
So like there's people who do Node.js and JavaScript, and that is what I think this top bar where
JavaScript is should represent.
Yeah.
But it's that plus everyone else, right?
Aggregated.
Um, so I don't know.
It's, these are a little bit weird, but I'll just go to the top.
Yeah, back end.
So like, unless you're primarily just a front end developer, what back end languages?
Right, right.
Or maybe you're using Node on the back end, but then other than that.
So, JavaScript, number one, HTML, top programming language.
Okay.
Uh, SQL, third most, and then Python and then TypeScript.
So, you know, like a bunch of interesting ones.
And then you've got your, your, your, VM, garbage collected JavaScript, Java and C# back there.
And then it starts to fall, fall off pretty quick after that.
Down at the very bottom, let's see the very bottom one is Crystal.
Okay.
And APL.
Oh my gosh.
APL.
APL is, is, something.
All right.
Uh, another one that's worth, talking about is databases.
So we've got Postgres, MySQL, SQLite, SQL Server, MongoDB as the top five.
So, it's pretty clear that Postgres has the momentum.
Like MySQL was higher and now Postgres is passing it.
But, you know, that's kind of, going up, here.
So this is which environments have you done extensive work in?
We'll also see that in like the loved versus dreaded section.
Yeah.
And by the way, on the audience, Marco says, I've already aged myself with that Pink Floyd reference.
Indeed.
Yeah.
All right.
So cloud platforms, you know, AWS, I'm going to surprise you that AWS has over half of the entire market.
No.
But only, it's only a smidge over half, it's 55.
So.
Yeah, exactly.
Uh, web technologies.
Here's another one.
Um, no, not this.
This one's kind of, kind of okay.
But like, for example, they've got Node.js, but they don't have Python, right?
So, I don't know.
It's a little bit funky.
Like they've Node and Express and Express runs on Node, whereas they have Flask and Django, but they don't have the thing that Django and Flask run on.
Which is, I don't know.
Anyway, it's a little bit of a challenging one.
But Node and React are quite high up there.
Look at this artifact, this living fossil right here, Brian.
What's number three?
jQuery.
You know it.
Dollar document ready.
Let's go.
All right.
I learned jQuery a long time ago.
Yeah, I still use a little bit of jQuery if there's some site that's already using it.
I'm like, yeah, whatever.
It's gonna, I'm just gonna put one handler in here and not worry about it.
FastAPIs on the list.
Yeah, FastAPIs on the list.
Django and Flask are 14.6%.
Both.
FastAPIs, 6% and going up.
FastAPIs just actually had a Ruby on Rails, which is pretty interesting.
Wait, so Phoenix is down at 2%, 2.13%, but I thought it was like.
It's the most loved.
Okay.
It's the most wanted.
I'm not, I looked at it, I'm not sure I agree with that, but it's a web framework built on
the Elixir language.
So, there you have it.
And we'll see.
So, yeah, another one here that's worth pointing out, I'm not gonna go over too many more.
Other frameworks and libraries.
This one is pretty weird in terms of like the partition.
This is what I had in mind when I'm like, there's something really weird about this.
So.
.NET and NumPy in the same bucket.
Exactly.
So, .NET is the equivalent of Python.
It's the equivalent of C++.
It's the equivalent of Ruby, right?
It's like a huge and broad.
And it's the thing that all the other stuff in that ecosystem runs on, right?
ASP.NET or whatever.
And so, they say, what other language do you work with?
Do you work with other libraries?
Do you work with .NET or do you work with NumPy?
Or do you work with Pandas?
There's no Python here, right?
And there's no Go and there's no, no.
I don't know.
Like, it's just, it's, I feel like this just fully is like out of place here.
So, if you just go past that, the top two are NumPy and Pandas, which by quite a good margin.
And then Spring for Java, React Native for mobile with JavaScript, Flutter.
And, but then back to a bunch of Python libraries.
Yeah.
Like you learn PyTorch.
Yeah.
So, Python actually ranks pretty high in the other frameworks and libraries you might be using.
All right.
Let's just, let's jump to the loved, dreaded, wanted section.
And then that's probably enough.
People can check out the rest.
All right.
So, they've got this sort of, you know, like what is driving the market?
Greed versus fear type of thing.
And so, they put each technology up and it's got a how much love versus how much hate does this technology get in a single bar, which is, the graphics here are pretty nice.
So, Rust, 86% love.
So, people who use Rust really like Rust and they don't strongly dislike it.
It's probably a self-selecting group, right?
If you made, if you took, I don't know, JavaScript people and told them they had to do Rust, they might not like it.
But Rust people seem to really like Rust.
Elixir.
I've never done anything with Elixir, but it's also really high.
Clojure TypeScript and Python is there at about two-thirds loved, one-third dreaded, I suppose, or not loved.
And you can see it goes down from there.
Yeah, I kind of want to talk to those 32% of the people and say, what is it that you don't like?
Well, I agree.
I feel like there's a lot of people who end up, so, for example, if you look at just the third that says they don't like it,
that's 11 times as many people using Elixir.
And that's two times all the people using Rust.
So I think it's a little bit, you know, a scale thing, right?
Like, there's a bunch of people who were working in one technology and then they were told, you're going to do Python.
And some of them wanted that change and some of them probably like, but I like C++ or I like whatever I'm doing.
And, you know, they're unhappy to be in that situation.
So I imagine there's some of that going on here.
There's less people like being moved into Elixir projects unless they really, you know, want to because it's a pretty small group.
Anyway, there's that.
And then if you switch to the wanted, though, Python and Rust tie for number one in most wanted, along with TypeScript is showing very notable there.
Yeah.
Nice.
Yeah.
Last one, we'll say databases, I suppose.
Postgres, most loved, least dreaded.
Redis, again, one of the things like, does this really belong on this list?
Redis is cool.
It's mostly for caching and message queues, not really as a standalone independent database.
So can it really be the most wanted database?
You technically, I know, can make it work that way, but it's not really built for it.
So I don't know.
Anyway, Redis is number two, whether it belongs there or not.
And then MongoDB and SQLite and so on.
In terms of wanted, Postgres and Mongo.
Nice.
No, not too much of a change.
All right.
I think that's pretty much it.
I'll give just a quick shout out to some graphics that are down here that people can play with.
If you really want to go explore, Brian, check this out.
Like, which one is this?
This database one's probably fair.
So there's this giant, I don't know what section is this.
It is work with versus want to work with.
Okay.
So it has this wheel.
And as you move around the wheel, it'll show you, for example, 5,000 people who worked with
Postgres want to work with SQLite.
8,000 people who work with MongoDB want to stay with it.
Whereas 7,000 people who work with MySQL want to move to MongoDB.
And similarly, there's like, it shows you all these interesting trends and flows from this
technology to that technology.
Like if you go up here to the language one and you go to pros and you click on C#, it's
pretty interesting because like the C# people, they want to go to TypeScript or Python
or JavaScript or HTML, but they don't want to go to Java.
Like there's no arc over to Java, right?
Because these are basically the same technology with slight different trade-offs.
So if you wanted to be in Java, you would just be in Java, I feel like.
Yeah.
You can sort of check out these flows and stuff.
Anyway, I think that's more than enough on this survey, but people should go check it out.
There's a lot of data here and a lot of things to learn.
So does that say HypeScript?
HypeScript?
It doesn't fit on the screen.
That's all.
Oh, okay.
It's HypeScript.
Hype.
Yeah.
There's just YPE script.
HypeScript with, yeah, it's just a scaling.
Nice.
Yeah.
Okay.
Before we move on real quick, John out in the audience says,
it's interesting that MySQL and MariaDB are perceived so differently.
Yeah.
That is true.
Yeah.
I don't know much.
I think that MySQL has a problem that people used it a long time ago,
and maybe it's different now, but I mean, that's what I'm basing it.
My experience with MySQL is like all over 10 years ago.
Yeah.
Same.
All right.
What you got for us next?
Well, I wanted to talk about Peppy, or I don't know.
It's P-E-P-Y.tech.
So I found out about this from the person that wrote it, Petru Reres.
So we've talked about something similar.
What we've talked about before is PyPI download stats or pypistats.org.
And so I was like, well, what's different?
So Peppy does download stats for packages.
So what we're showing here is the stats for pytest.
And what the PyPI stats does is it shows you a breakdown of like you've got the overall packages,
but then you can also look at downloads per Python 2 versus 3,
and then major and minor versions of Python.
And so that's kind of interesting.
Okay.
But actually now, after we're like so much far past the 2 versus 3 split, like I'm not even supporting 2 anymore.
So what I like is Peppy doesn't do that.
So Peppy's same stats are same for pytest.
What it's looking at is it grabs like the top handful.
So let's do the default.
I have it all customized right now.
So let's drop those off.
By default, it shows us the last few versions of pytest plus all of the downloads for the last major one.
So all the 7x downloads.
And so the numbers are a little different because we're not showing everything.
So right off the bat, I kind of like that I'm just caring about the last few versions.
That's kind of nice.
And it also has a daily, weekly, monthly chart so that you can kind of see trends going on, which is nice.
What I didn't realize at first is that you can select different statistics.
So if I wanted to see everything on all versions, I can just go ahead and type a star there.
I think that works.
Yeah.
There you go.
And then it does all of the downloads.
And then also when I just dropped that, I don't know if you noticed, but it shows all the different download stats already.
So you can kind of get a glimpse of what you're going to find right off the bat.
Now going down through the chart, we've got both a chart and a table for when they grab the data.
And this split up of, I'm not looking at Python version.
I'm looking at version for the package that I care about or possibly my package.
So I did this recently for pytest-check.
And I was thinking about it for pytest of like, which version should I support?
And clearly, like most, like tons of people have switched up to, most people have switched to 7x already.
So yeah, I think it's perfectly fair game to not support 6x pytest anymore.
So why not?
Anyway, so just a different take on download stats.
Plus, it includes some cool badges that if you want to grab your, like add this to your repo to say how many downloads per week or per month.
Kind of neat.
Yeah, that's really cool.
If you, you know, if you're open, if you're maintaining some open source package and you're like, and it depends on something like this, like pytest, you just, you can quickly look at that and make a call.
Like, well, how, how important is it for me to support this old version?
Or how ready am I to move to the new thing?
Adopt this feature that won't allow older versions of, you know, Python or whatever it is you're looking at, right?
Like, should we add types?
Well, that might not work on like, where is that?
3.3 and before.
Yeah.
Well, like on pytest-check, I've got a feature that I'm going to deprecate.
And it's only been in since like the last version.
I just didn't think through the API enough, I think.
But so I wanted to take a look how many people are using the most recent version.
And actually, so most of the people are, or quite a few people are using the most recent version.
But it isn't most.
It's, if I do like a total of every version, it's definitely not most people using the most recent one.
But I don't know.
And of those, I have no idea what, if they're using the feature or not.
Anyway, interesting.
Take a look on it.
And I appreciate it.
And it's an open source project as well.
And some of these graphs have been updated by a contributor.
So it's kind of nice to have it alive and well on open source.
Peppy.
Tech.
Yeah.
Very nice.
Good find.
I like it.
All right.
Off to our sponsor for the week.
Yes.
Thank you, Microsoft, for sponsoring this episode.
This episode is brought to you by Microsoft for Startups Founders Hub.
Starting a business is hard.
But by some estimates, over 90% of startups will go out of business in the first year.
Ouch.
With this in mind, Microsoft for Startups set out to understand what startups need to be successful and create a digital platform to help overcome those challenges.
Microsoft for Startups Founders Hub was born.
Microsoft for Startups Founders Hub provides all founders at any stage with free resources to help solve startup challenges.
The platform provides technology benefits, access to expert guidance and skilling resources, mentorship and network connections, and much more.
Unlike others in the industry, Microsoft for Startups Founders Hub does not require startups to be investor-backed or third-party validated to participate.
It is truly open to all.
So what do you get?
You can speed up development with free access to GitHub and the Microsoft Cloud with the ability to unlock credits over time.
To help with your startup and to help innovate, Founders Hub is partnering with innovative companies like OpenAI, a global leader in AI research and development, to provide exclusive benefits and discounts.
Through Founders Hub, becoming a founder is no longer about who you know.
You'll have access to their mentorship network, giving you access to a pool of hundreds of mentors across a range of disciplines, across areas like idea validation, fundraising, management, and coaching, sales and marketing, as well as specific technical stress points.
You'll be able to book a one-on-one meeting with the mentors, many of whom are former founders themselves.
Make your ideas a reality today with the critical support you'll get from Microsoft for Startups Founders Hub.
To join the program, visit pythonbytes.fm/foundershub 2022 or click the link in your show notes.
Indeed.
Thank you, Microsoft for Startups.
Let's move over here.
So this next one comes to us from several folks recommending it.
And to be honest, I'm not sure if I would cover it if there wasn't a bunch of people said, hey, you should cover this.
This is really interesting.
So I'll sort of take their lead and say, this does look pretty interesting.
So Jeff Hutchins and Abdulaziz Al-Skwasim sent this in.
Thank you both for sending.
And this is the CodeOn Python compiler.
Have you heard about this, Brian?
Just from people submitting it.
Yeah.
And people talk about Python performance all the time.
Sometimes, I would say most of the time, it doesn't really matter to you.
Most of the time, you're spending way more time waiting on a network, waiting on an API call, waiting on a database.
But sometimes, it really does matter.
And you need your code to go faster, right?
So traditional options have included things like Numba or Cython or even PyPy, P-Y, P-Y for the JIT compiled version of Python.
So here's one more thing to put into that category of options called CodeOn from ExaLoop.
And it's a high-performance, zero-overhead, extensible Python compiler using LLVM.
And LLVM is one of the compilers that gets used all the time, of course, for a bunch of different things.
And they claim that it is on the order of 10 to 100 times or more faster than regular Python for single-core performance.
And because it really compiles to some native code.
They say also, by the way, sometimes better than C++ in terms of performance.
But it also, because it compiles to some native representation, it doesn't involve the GIL, so you also get better scaling.
And it comes out of this, I think, genetics project called SEC, bioinformatics, rather, which is this language for bioinformatics.
And I think what they've decided is like, you know, let's just go and just do straight Python, right?
And if you go to exaLoop.io, they've got a couple of sort of selling points here.
Performance, I see, is a Python.
It adopts Python syntax and is fully interoperable with Python.
And they've got this little flow graphic type thing.
Shows your Python code.
And if you look, it's not even type annotated, which kind of surprised me, Brian.
I figured they would at least require you add, you know, Python type ints.
Yeah.
But no.
It says you take Python syntax and semantics and you feed it in.
It builds up an abstract syntax tree.
It does some kind of type inference to figure out what the types are, like ints.
Comes up with an intermediate representation and then applies a bunch of JIT style optimization.
And domain specific optimizations and outcomes.
Pretty interesting.
Native code, as I said, but also, where does this show?
I guess it doesn't have a better picture because it's cut off here.
Outcomes, native code, but also WebAssembly and GPU targeted code.
That's cool.
Think about that.
You want to write some code?
This Python code does matrix stuff.
I want it to run on my NVIDIA GPU, you know, --GPU or whatever the thing you do to make it come out with that.
It's pretty, pretty wild.
Or put it on the web with WebAssembly.
It sounds great.
It does sound great.
So they've got some examples.
It says we're going to have a list of fruits, just three strings, banana, apple, and lime, and some prices.
In the dictionary, banana has a price, apple has a price.
And it says we're going to write standard for fruit in fruits.
F string, print out the price of the fruit.
And then it's going to put a bunch of stuff in the cart by doing list, multiplication, and addition, like you would expect.
Call the sum with a comprehension and print it out.
And then, boom, no problem.
Compile that to native code if you want.
Okay.
It says if you know Python, there's nothing to learn.
Yeah, it's a bunch of...
Yeah, go ahead.
The question is, which Python?
It says Python syntax, but which Python syntax?
Is it 3.10, 3.9, 3.11?
It's not clear other than 3.6 or above because of the f-strings.
The only giveaway I see here.
And possibly lots of people are fine with not exactly knowing which version of the syntax.
Yeah, it didn't say.
I mean, maybe if you go into the docs, it'll exactly say right, but not on the little landing page.
It was initially dissolved to solve computing challenges in genomics, which it's so focused on.
Also, it's got a bunch of stuff focused on finance and GPUs for CUDA programming, as well as WebAssembly, which is pretty dope.
Yeah.
Also, if you scroll down a little bit, there's a little video.
Let me, I'll hit, tell it to go.
There's a video.
I'll tell it to stop.
I don't know.
Where they show it running as a kernel in Jupyter Notebooks.
Oh, wow.
Just doing standard Python stuff with kind of mass intensive things and then pulling in matplotlib and showing the various things you get with matplotlib.
So, yeah, it looks pretty good.
So, what do you think?
I think even if it, I'd like to know what version of Python it's compatible with, but other than that, it looks fun.
It looks really good.
It's on GitHub.
And so, it is technically at least source open.
What is the license here?
The license is a business source license.
What the heck is a business source license?
Okay.
From MariaDB Corp.
Yeah.
I'm going to have to figure out what the business source license is.
I don't know.
You can read the source, but it's hard.
I don't know.
That's what I said.
Is it source open or is it not?
Yeah.
And so, all this stuff is good.
And the reason I'm hesitant to recommend it, but I think these benefits are really big and, you know, people can use it, then great.
You go a little further, it says ExalupinU.
This is free for non-production use.
If you want to use it for things that are commercial, then do you know what it costs?
Don't know.
Contact us.
I don't know either.
If you got to ask, it's too much for you.
Let's just put it there.
That's what my dad always said.
If you got to ask, you can't afford it.
Exactly.
Which, I don't know.
I'm not against them charging for it.
I understand that this is probably an insane amount of work to put together.
If that's their model, that's their prerogative and it's fine.
I don't think everything has to be given away free.
There's tons of work that goes into a lot of stuff.
And sometimes charging for it is the right answer.
But just tell people what it costs.
You know, don't make them email you.
That is really not good.
So, Robert mentioned, Robert Robinson, maybe it's a sliding scale.
And it's like, it depends on who's asking.
You know, Microsoft calls up and asks.
It's a different price.
I'm sure it is a different price.
And I'm sure that's, oh, do you want to run it on all of Azure?
Well, here's the price.
But, you know, put some common cases in there.
Are you a data scientist and you want to use it for an API?
Here's what it costs.
Are you trying to host it as a server?
Well, here, like, then maybe you need to, like, there should be at least a little bit of a,
here's the realm of where you start, right?
A lot of things have, you know, here's the base price.
Here's the pro price.
Here's the enterprise price.
And here's the contact us if that doesn't fit you, right?
But to say it costs money and we won't tell you what it costs.
I don't know.
It just sounds not great.
And I hope people, so the free non-production, non-commercial versus commercial, that's still a fuzzy line.
And I wish there was, like, more detail.
Whenever anybody does that.
Because I've been in situations a lot where I'm just some dude writing a script in a company.
And the company's big.
But I just want to get this thing to work.
And it's just a small piece of my build chain or something.
I'm not going to get okay to do a corporate license for something just to save me five minutes a day.
Yeah.
Maybe you're not selling it, right?
Yeah.
For example.
Yeah.
That's another thing.
Is it part of the thing I'm selling?
Or is it just part of my work to get something else done?
Yep.
Indeed.
So anyway, pluses and minuses.
But it's an interesting contribution.
And thanks, folks, for sending that in.
Definitely.
Indeed.
Well, so I want to talk about type hints a little bit.
I've been thinking about type hints a lot.
And ran across this article called Eight Levels of Using Type Hints in Python.
And it's from Yong Cho.
And first off, I love the graphic.
This is an Unsplash graphic.
But I'm kind of a fan of it.
It looks like posters, like band posters or something like that on something.
And half of them are peeled off.
So cool image.
Anyway.
Yeah.
Complete side note.
So I was attracted to this because this eight stage.
I kind of thought of it as like eight stages of using type hints.
Because that's kind of how I started using type hints.
And it almost got the order the same.
So let's go through these orders.
So the first one is, did I skip over it?
The first was type hints for basic data types.
So basically, you kind of do this if you're using data classes at all.
You just say, well, I've got my age as an int.
And it defaults to 29.
Just to kind of tell people what you're thinking about.
And while you're, you know, my hosts are a tuple.
And they default to an empty tuple or something.
So this is pretty much how I started as well.
And I started mostly because I started using type data classes.
And this is what they look like when you're declaring the contents of a data class.
And then, so where do you go from there?
The next stage is defining a constant using final type.
Actually, I've never used this.
Have you ever used final?
I've wanted to use it.
But it's so not exactly enforced type of thing.
It's like, I would love to have a constant in Python.
But doing it through typing means the only time it's going to be validated or checked
is if I run mypy or something.
And most of the time, I'm not.
So it's like, well, okay, whatever.
I'm not saying.
Yeah.
I'm actually increasing the amount of times I'm using mypy or other type checking things.
But yeah, I wouldn't have put this number two.
But minor gripe.
It's kind of a cool feature.
It is a cool feature, though.
Yeah.
I don't knock its existence.
I just wish it was more supported in the language.
Yeah.
The third is adding multiple type hints to one variable.
Like it shows here a couple different ways.
The union of an int and a float or the bar of int and float.
And the number one way I use this, I mean, I use things like this also.
Like it could be an int or a float.
But I mostly use it for like int or none or something or none because I've got a default
value of none.
And I kind of wish there was another way to do it.
Because when you have a, I don't know, it's kind of convenient anyway.
But like let's say I've got a parameter to a function and it defaults when I internally
I assign it, it defaults to none if nobody passes anything in.
But I also don't really want somebody to pass none in, you know?
So I wish there was a like the default is none, but users can't pass in none or something
like that.
Yeah.
But anyway, it works.
And in the end, it helps with testing anyway to be able to pass in all the types.
But so yeah, and I've totally switched to the bar thing.
I think it was 310 that added that.
Do you remember?
I think it was 310.
Yeah.
It says right here.
It even says there.
Yeah.
Uh-huh.
Yeah.
So anything I'm writing, I support 310 and above because I like the bar.
The next thing is using general type hints, which also this is, yeah, I think now we're starting
to increase the stage of understanding of how type hints can help you.
And the notion, like in the example, they use iterable as, you know, from typing import
iterable.
So you say that, you know, I'm accepting something like numbers and it takes an iterable.
I love this use.
And I, you know, it takes a little bit more of advanced use.
You get a little more comfortable with type hints.
And to be able to say, I'm going to do iteration like 4in and nums, it doesn't really matter what
it is, if it's a list or a tuple or something else, as long as I can iterate over it, it's
good.
So, and the other thing is probably, and I'm not sure why they didn't put, is optional, but
along the same as iterable, I like, I'm going to often say it's iterable, but the type inside
is an int or something like that.
But anyway.
Right.
The fifth one is a little bracket int or something like a whole bracket string so you know what
you get out.
Yeah.
The fifth is a type hints for functions.
And I probably would have put this as like number two because I started using this right
away of, yeah, to say, because it's, that's one of the things that's hard with when I came
to Python from C++ is knowing like, where do I put the return value?
Like the return type is, is, you know, maybe, maybe it's multiple return types, which I don't
really want it to be.
But, but it's nice to be able to see what the return type is and type hints add that
with, with type hints for functions.
Right.
Or you read a function, you know, like I want to call that, but what do I do?
Yeah.
Do I have to read the function and try to understand it?
Or can I just read the definition?
Right.
I think this is one of the main uses, right?
Yeah.
And it's also nice to be able to see right there with a union type is, is not a possibility.
Do I have to deal with nothing coming back as something is possible?
Number six is alias for type hints.
And I kind of love this.
I haven't been using this much, but I'm going to start using it more.
Especially it says with in Python 310.
So before Python 310, you had to do like from typing import type alias and have this weird
syntax thing around it.
But it's not really that weird.
It's a, but the, after 310, you just sort of declare a thing.
It says like post type posts type is a dict that goes from it to string.
That's great.
And then you can use that as a type hint or other places.
So that's interesting.
That's news to me.
Yeah.
That's really interesting.
So definitely, I'll definitely start using that.
So I'm glad I read the article for that.
Type hints for class for a class itself, which I'm not sure why it was titled this, but basically
it's the self type.
And this is very helpful if you have a class, a class that has objects that refer to other
objects of the same type.
I don't know how you did that before then.
I guess I wasn't caring about it, but.
You had to do as a hack or you put it into quotes.
So the example from this article is a class called list node, and it's going to be past the
previous node, right?
So what is the type of that?
Well, it should be a list node.
Yeah.
Python is in the process of building up the list node class.
So it doesn't yet know what it is.
But you're trying to define a function that has that.
So there's this weird patch 22 thing.
Yeah.
Chicken and egg thing.
So what you put is you would put list node in quotes.
That's the old version.
And of course, it was just a string.
But then it's like, well, but it's a string that says that.
So we're going to just guess that that's what you want.
It was weird.
Okay.
Well, the eighth and final one is to provide literals for variables.
And I haven't done this, but it's kind of nice also.
And I didn't know you could do this.
Just to say, and in the example, it's from typing import literal.
And then you define like a weekend that's a literal that can only be the strings Saturday
or Sunday.
And so this isn't an enumeration.
It's a it's just saying that it can only have these particular values.
So I think I got that right.
I don't think it has to be an enumeration, but no, no.
So this is in the end.
So like the example says, well, if you assign that variable to Monday, it's going to your
your type checkers are going to complain because you didn't assign the one of the known ones.
And I probably would use this in conjunction with enums or maybe I don't have to with enums.
I don't know.
But but there's a lot of stuff that is passed around that it's kind of like an enum, but it's
passed around.
It's just a handful of strings that.
It can only be one of these strings.
So yeah, be nice for this to support it.
Henry on the audience points out that X colon final equals true also maps to one of these
literal checks.
So is literal of true rather than just a bool.
So the type checker can make sure it's always true, not true or false.
So there's an interesting tie together of those as well.
And Robert points out that it sounds like a case of the Mondays.
Oh, dear.
And Henry mentions that last time I checked self was not supported by my pie.
But so we'll have to check on that.
Yeah.
Anybody from my pie listening?
Let us know.
Well, that's it for for this.
I just thought it was a good I and I do think this is a good idea is to to not try to jump
in the deep end of type hints.
Try some of the simple stuff first and then you get to caring about it.
Yeah.
That was a good little discussion around it.
That was fun.
Yeah.
All right.
Got any extras for us you want to throw out there?
The only extra I wanted to bring up is the testing code hasn't had an episode since like
October or something.
And it's not dead.
I just kind of wanted to take the holiday off without telling anybody.
And it's coming back.
So sometime in January, there will be a testing code episode.
Oh, excellent.
Looking forward to it.
All right.
I have a few extras and one leads to another, which leads to another as is the nature of
all these things.
So I wrote I ran across a couple of articles.
Let me start that way.
that sort of talked about RSS and how RSS is actually kind of important as a foundation
of the independent web and in ways maybe bigger than like I really realized.
So there's this one called Back to RSS.
I'll just read a little excerpt from each of them.
It says it's 2023 or 1999 or whatever.
Personal sites are back.
Blogs are back.
RSS is back.
And owning your data is becoming real, which kind of a cool thing.
And then also there's this one the same day on The Verge called Bring Back Personal
Blogging.
And yeah, anyway, so I ended up writing a welcome back RSS article that kind of riffed
on those ideas and talked about some more, talked about Reader, which I talked about before
and stuff.
So yeah, anyway, people can go check out that article.
And it's interesting.
And as part of the conversation, I learned about Reader, as in reader.readthedocs.io, which
is a reader is a Python feed reader library.
So it does things like let you subscribe with Python to RSS and Adam and JSON feed.
Mark articles as read and important.
Filter them.
Get stats.
Do all of it.
Like basically, if you wanted the logical internals of an RSS reader, here's a Python
library to do that, which is cool.
Now what we need to do is have a listener like take Reader and put a textual front end on it.
So we have like...
Yes, actually, that's a pretty interesting idea.
That'd be cool.
This guy over here built this thing called Kustos, which is basically like Instapaper, a self-hosted
Python web app built on Reader.
So people can check that out.
And then Readwise looks really interesting.
Are you familiar with Readwise?
No.
So it's like an RSS reader, but it also lets you take notes, mark stuff as read for later,
even if it doesn't have an RSS feed and highlight like your research as you're going through it
and save it.
So think how good that would be for people that say, dude, Hogcaster, you got to remember a
bunch of stuff about an article.
Pull that thing back up and it's got your highlights and your notes on it.
So...
Oh, I'm liking this.
I'm going to have to check it out.
Yeah, that's looking pretty good.
So anyway, all that stuff came from this little article that I wrote.
People can check that out.
Nice.
Another very important thing.
There's this Mastodon account called Year Progress, and it just goes along.
And every day, it just hosts a progress bar for how far we are in the daily progress.
So it's like a little ASCII, you know, TQDM style progress bar of the year.
And it's just notable that we just had 100% progress for the year.
Now that we're done, it's reset to zero, but it was 100%.
Actually, it looks like it doesn't actually do it every day, but it does it when it goes
to a new percentage.
So it's every few days or two or three days, right?
Yeah.
It looks like it, which I guess is probably good.
I mean, thank you for not doing it.
It's like saving 3.6, 2.6 posts, something like that.
Yeah.
All right.
And don't just watch it.
Wait for it.
It's not that exciting.
It doesn't actually that often.
It has no decimal point.
So it's got to work in big ASCII blocks.
So it does what it does.
All right.
This is something that people might want to keep an eye out who had automated builds running
over the winter break and also used PyTorch.
So one of the thoughts I had was I was just kind of kicking back.
We were hanging around.
I'm like, you know, I'm going to work on some of these little weird projects.
I'd like the login page on Talk Python training to just be a little smoother and cleaner.
Maybe I'll just go play with that.
I'm not really going to do real work, but it'd be kind of fun to do some web design and just
sort of like no pressure, redesign that a little bit.
And I thought, but I'm going to be careful about adding new libraries, updating existing
ones like pip-tools style, update them because is anybody watching?
And if something bad got in there, would anybody know?
Are they all on break?
Right.
Well, it turns out my paranoid side was on to something.
Luckily, not anything I was using, but PyTorch discloses malicious dependency chain compromise
over the holidays.
This is bad.
If you pip installed somehow the PyTorch stuff, I don't know the exact how it links together,
but it says PyTorch has identified a malicious dependency with the same name as the frameworks
Torch Triton library.
So that was like somehow shipped or directly linked in PyTorch in a way that I don't fully
understand because I don't use it.
But what happened is on Merry, Merry Christmas, on December 25th, users who installed PyTorch
nightly should ensure their systems are not compromised because of this Triton torch.
What they did is somebody put a malicious version on PyPI.
And when PyTorch was getting set up, instead of picking its own version, it preferred the
PyPI version, which was a virus.
So anyway, people can check that out.
It's sub-ideal.
Since the PyPI index takes precedence, this malicious package was being installed instead
of the version from the official repository.
This enables somebody to register a package to do bad things.
Anyway, people can read all about that.
But if you have PyTorch and you pip installed it over the point of break, read that.
Yeah.
Plus, you know, kudos for them for coming up with a great domain name, bleepingcomputer.com.
Yes, I know, bleepingcomputer.
There's a lot of good articles on bleepingcomputer.
It's in my RSS feed.
All right.
Well, that's all I got for extras.
How about a joke?
Yeah, it sounds great.
So first of all, let me, I don't want to kill the punchline before we set the stage.
Okay.
So I pulled up just the picture.
Can you tell people what this is on the screen, Brian?
You remember these things?
Well, remember, they're still there.
Not on my laptop.
Not on my Mac mini.
It's on the back of like a computer or something.
A desktop computer.
Next to the power cord, there's a toggle switch with a on and off.
It's on and off toggle switch.
Right.
It's like a physical power button directly on the power supply on a desktop computer, right?
Yep.
Yeah.
And Robert got it exactly right.
So here is the joke.
They finally made a switch to exit Vim.
And they've highlighted that physical power button on the back of the power supply.
Nice.
You're a Vim lover.
So I won't rub it in too much.
But that's a pretty effective way to exit Vim.
Vim runs in a window.
So just close the window.
You know, whatever.
The funny thing about power switches.
So I used to work with a lot of embedded systems.
And some of them run Windows embedded.
And embedded systems are supposed to be able to toggle the power off, just like from the power supply.
Yeah.
And now normal Windows, you're not supposed to do that because, you know, you want to let it shut down gracefully.
And if the disk is moving at the time, and there's even with Windows embedded, there's some issues or any embedded operating system.
There are a possibility you could do some damage to the disk if you power off at exactly the right time.
But there's supposed to be safeguards in place to take care of it.
So I'm just in the habit of using these things all the time of, like, toggle off and on.
And if we get, like, a new batch of people in that are mostly from DevOps or from non-embedded worlds, they're like, what are you doing?
You're going to break it?
Yeah, you're going to break it.
Like, no, these are good.
Yeah.
That's awesome.
Yeah, my little circuit Python thing.
It doesn't have a power switch.
You just disconnect it from power if you want it off.
That's how it works.
Well, and one of the reasons, now I'm going in the weeds, but one of the reasons for the need for the ability to just power off is because a lot of times instruments are in a huge rack.
And you don't go through and power off each individual instrument.
You just turn the rack off.
Wow, interesting.
Cool.
Well, it's good to be back in 2023.
Yeah, it is good to be back.
So welcome back.
And thanks, everybody, for tuning in.
Yeah, you bet.
Bye, all.