Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.
This is episode 362, recorded November 28th, 2023.
I'm Michael Kennedy.
And I'm Brian Okken.
And this episode is brought to you by Scout APM.
We will tell you more about them later, but please check out what they're offering.
It really helps support the show.
And if you want to connect with us on the socials, the place we're all hanging out at is Mastodon, fosstodon.org specifically.
I'm Adam Kennedy.
Brian is at Brian Okken.
And the show is at Python Bytes.
fosstodon.org is invite only.
Of course, you can follow us from any place on Mastodon.
But if you want to be part of it, just shoot one of us a message.
We can send you an invite.
Help you get over there to hang out a little bit closer to home for us.
And finally, if you want to be part of the live stream and see how the show is made, see what we're doing, even the real mistakes that we might edit out.
Check that out at pythonbytes.fm/live.
Usually Tuesdays at 11 p.m.
And older videos are there as well.
Let's kick it off.
What do you got?
This is a gentle ease back into the show.
Over the Thanksgiving break, I was thinking a lot about kind of what I wanted to do for the next year.
Starting to think about plans for how to, where do I want to focus my time?
And I ran across this great post by Vadim, let's just say Vadim, Habits of Great Software Engineers.
And it's kind of, there's a lot of great stuff here.
So also, nice index on the right, which is cool.
So focusing beyond the code.
So I'm not going to go through all these.
I'm going to go through, there's like 12 or 13 listed, but I'll go through a few of them.
Focus on the code.
So I don't know if I buy this, but he says, as a developer, you will code 20% of your time.
You should excel at coding nonetheless, but it won't be enough to be great.
I think I code more than 20% of the time.
I would say too.
Well, define code, right?
Okay.
So is coding, is that reading code?
Is that thinking about code?
Is that...
Oh, the design part.
Right.
Or is it actually, I'm hitting keys on keyboard.
You know what I mean?
Yeah, that's true.
Right.
Because people say you code as read way more than it's written and stuff.
But I think for me, coding is like the act of being in the code and adding features or evolving it,
even if like I'm not keystroking it at that moment.
So unclear, but if that encompasses all, then 20% is way too low.
Agreed.
Okay.
Well, I guess the point of this, regardless of the percentage, is focusing on the other parts of your job also.
And focusing on, you know, not just being a better software engineer, but also...
Well, being a better software engineer encompasses more than just coding well and knowing Python details and things like that.
Like communication skills and all that.
Design skills, learning other...
Learning to read other people's code, things like that.
Helping unblock your teammates who are having a challenge.
Instead of writing code yourself, like I'm going to help them get that problem fixed or something, right?
Like...
Yeah.
Yep.
All those things.
Well, and...
Okay.
So number two was efficiency and anti-fragility.
I'm not really a fan of the anti-fragile word.
I don't even really know what it means, but I guess...
I think it originally comes from Nassim Taleb and that whole philosophy, although I haven't read a whole lot of that either.
Anyway.
It's kind of about things that get better the more they kind of get abused, right?
Like they sort of build up a resilience.
Well...
I think it originally comes out of economics.
Okay.
Well, the next one is one I really agree with is the joy...
Number three is the joy of tinkering.
Build projects, try out frameworks, build stuff on the side.
Keeps the spark alive.
And this is one I couldn't agree more.
It doesn't...
I...
For a while, I was often thinking about, like, what could I build that I could actually release or that I'd be proud of?
That's great.
You could try to at least do a side project that tries to make money or something.
But if you just want to try out FastAPI, for instance, just build something with FastAPI.
Just come up with a toy project and build it and learn it.
And it's fun.
Even if you never apply it to other stuff.
I've had so many times in my career where I've had something that I tinkered with just as a toy that suddenly, like, I could use.
I'm like, oh, yeah, I've built wikis before and stuff like that.
I can go ahead and do that for a project or, you know, I've done a flask app on the side.
So if I need a flask app at work, it's going to be pretty easy.
Things like that.
Tink, playing with toy projects.
I say, put that on top of your list for 2024.
More toy projects.
I'll go through the rest of these pretty quick.
Number four is knowing the why.
Number five, thinking and systems.
Number six, tech detox.
Recharging away for the monitor.
This makes you a better programmer.
Couldn't agree more.
The art of approximation.
I don't really know what this is about.
I didn't read this part.
Knowing important tech numbers.
Anyway.
I will.
I actually have one.
I want to cover that as one of our items.
Okay.
In the future.
There's a couple of hosts or charts or whatever that somebody put up that I think would be really interesting.
So this is like, what is the relative speed of L2 cache versus RAM?
RAM versus disk?
What is the cost of like a CPU core or a database operation on the cloud?
Et cetera, et cetera.
But I don't like some of the numbers there.
I think they're way, way skewed.
So I want to come up with my own table and then put them both forward.
So that's why I haven't covered it yet.
But that's what this is about, I think.
Okay.
Well, what's funny is that like the teaser at the beginning of this post says there's only eight, but there's more if you read it.
But there's a table of contents on the right.
So you can just look at the table of contents.
The last one I think is the most important for me is strong opinions loosely held.
And for me, this means that I'm going to have a default approach to test for a lot of problems and a default way to do things.
It just speeds things up.
It's like, if I don't care about it, just do it quickly.
You've got an opinion on how things are done.
However, be open-minded enough to when somebody approaches you and says, hey, there's a better way to do this.
Or keeping your eyes open with the tinkering, trying new ways to do things.
Be willing to abandon your old strong opinion and go, oh, there's a better way.
Cool.
My new opinion is this now.
That pretty much sums up our podcast.
Yeah, exactly.
Yes.
So, yeah.
Nice.
Nice post.
Just thinking about, you know, kind of planning for your time allotment for the upcoming year.
Yeah.
Lots of feedback on this one.
Jeff out there says, tech numbers like LEET1337.
So, excuse me.
Yes.
Those are the important tech numbers.
Those are the important ones.
Yeah.
LEET, NOB, all those things.
And then Grant, following up on the anti-fragile, says this.
Number two speaks more to reactive principles that came about with the cloud.
It could be summed up as build with the expectation that your K8 pods can be nuked mid-task at any point.
Yeah, exactly.
That you might just use one VM, but it could die.
But if you like know that it's always getting abused, you would build like failover and those types of things into it, making it hence less fragile.
I think that's kind of that principle there.
Yeah.
Okay.
But also, if it's a side project, if it's down once in a while, it's fine.
Yeah.
This is not a side project.
Yeah.
Maybe a habit of great software engineers.
I don't know.
I wonder how many blogs run on Kubernetes.
I don't know what the answer is, but I bet too many.
The answer is too many.
Too many.
Too many run on Kubernetes.
Okay.
What do you got for us?
All right.
I got eight nines uptime on my blog.
Okay.
Although we probably do, Brian, because ours runs on a CDN as a static file.
Okay.
That's pretty good uptime, right?
Yeah.
Then the database doesn't need to be migrated for that business, does it?
All right.
Moving on.
We've covered this enough.
Let's talk about a new version of Flask.
So Flask obviously is a super important web framework.
Like everyone has heard of Flask.
It's kind of one of the two main pillars that I would think of, like the old guard pillars, right?
There's Flask and Django.
And the debate for so many years has been like, do you use Flask or do you use Django?
What kind of web developer are you?
Well, Flask 3.0 was released just a little while ago.
Is that three weeks ago?
Something like that.
There's also a 301 that is only unreleased, but has like very, very minor changes.
So anyway, the changes for a two to three release are not that huge.
Although I think the numbering probably comes from this removed, previously deprecated code there.
That's probably what pushed it from a two to three rather than some mega new feature.
Yeah.
Right.
Because it's like, hey, it's not backwards compatible.
Miguel Grinberg actually wrote an interesting but controversial piece on that.
I'm not going to link to it, but y'all can check that out.
I just want to cover the release here.
But a lot of this, actually this first line, there's a lot of discussion about it, let's say.
Neutral there.
So some of the things that are interesting here though, Brian, are not so much interesting because
they're Flask.
They're just like, wait, what?
You could do that?
So deprecated the Dunder version attribute.
So frequently people will go to their Dunder init.py for their package and put a Dunder version global variable and set it to a string.
And then you can say, well, what version is the thing?
Well, it's Flask.Dunder version is the version.
And that's just a string, right?
Yeah.
So the idea is that's deprecated.
And now the way you're supposed to get the version of Flask is using feature detection or with import lib.metadata.version of, quote, Flask.
Okay.
Which I had not, like, okay, so cool that that might work.
But how in the world do you make it possible for a package that that comes out of it?
If I wrote a package and I wanted to say dot version of my package in import lib, how do I put a number in there that makes it the version, right?
So do I have it here?
Yeah.
Basically, you have to go, if you use a pyproject.toml, at least one way is, and you just set the metadata category, set the version to something.
And now that's that.
Yeah.
Okay.
Yeah.
Pretty cool.
And so that's where that value comes from when you say import lib.metadata.version.
Pretty cool.
What's more interesting is deprecated a global variable.
How do you deprecate a global variable?
I know how to deprecate a method, a class, but a variable?
But just delete it.
No, that's removing it.
You wanted to give a warning when you access the variable.
Hmm.
Okay.
And the variable's value is a string.
Like, okay, what?
So I'm like, I got to see it.
So I went and I tracked down the changelog.
I checked down the PR that made this happen.
I'm like, I got to see the code.
What is this?
So it says it deprecated Dunder version.
And here you can see somewhere, you can just see they literally, like you said, they deleted the Dunder version variable, but they added a function to the module called Dunder get adder.
For some reason, I thought that only applied to classes, but no, apparently modules.
And given that it comes in and it asks for the version, it says no, there's a warning.
And then it calls the import lib.version thing on itself.
Interesting, huh?
Yeah.
Actually, this is a handy thing to keep around.
Yes, exactly.
If you're asking for Dunder version, it warns and then it does the new thing.
Otherwise, it just says, no, we don't have one of them.
But yeah, that's wild, right?
Yeah.
Huh.
I love how dynamic Python is.
It was a global variable.
Now it's a function.
Now it's a function call to a Dunder get adder method on the module.
Wow.
Yeah.
I think I'm going to replace all of my global like function declarations as get adder.
Exactly.
It's going to write all.
Yeah.
The whole function is just a bunch of dispatch to get adder.
It's going to be awesome.
Yeah.
We structured the code such that the Flask app and blueprint classes have sans IO bases.
I don't know what sans IO bases are.
But that moves things like a request and response over to wrapper sections and out of the app itself.
Things like that.
Requires a new version of Vexoic.
And that's pretty much it.
So interesting.
So it's interesting that 3.0 is out.
Way to go.
Palette's team.
But it's this deprecate version attribute.
This is interesting to me.
Yeah.
And so the meta.
I haven't played with it.
But that import lib metadata version.
You showed it working with like a static version metadata.
But it probably works with dynamic versions in PyProject Toml based projects also.
Yes, probably.
Yeah.
It's just my lack of experience with that kind of stuff to talk about it.
No.
Interesting.
Cool.
Mm-hmm.
All right.
You know what else is cool?
Our sponsor this week.
Let me take a moment and tell everyone about them.
Once I find where I put my notes.
Okay.
So this episode, as a couple of recent ones, have been brought to you by Scout APM,
Application Performance Monitoring.
Definitely a cool, cool service.
You know, there's a lot of profiling and stuff you can do, Brian.
And it's great to run your code in the profiler.
There's a bit of a Heisenberg type of thing.
As you observe it, it changes the behavior of the performance.
But you still get a sense.
But it's nothing like my app is running in production.
Let's see how it did during Black Friday.
Oh, this was the part that was slow.
We could, like, save a ton of money, run fewer servers or Kubernetes pods or whatever it is you're doing.
If we change it this way, right?
So having that data is awesome.
So if you're tired of spending an hour trying to find the root cause of issues impacting your performance, then you need to check out Scout APM.
It's a leading Python application performance monitoring tool that helps you identify and solve performance abnormalities faster and easier.
It ties bottlenecks such as memory leaks, slow database queries and background jobs.
And of course, the dreaded N plus one quorum query problem and more directly to source code so that you can spend less time debugging and more time building.
I don't know where that fits in the 20% of your code example, but I think this kind of stuff counts too.
You'll love Scout because it's built for developers by developers.
It makes it easy to get set up and deliver insights in less than four minutes.
Seriously, you could be done by the time you're done listening to this episode or live stream.
So start your free trial and get instant insights today.
Visit pythonbytes.fm/scout.
Please use our link because it really does support the show, right?
If they don't know you're coming from us, then they might not sponsor us anymore.
So please, pythonbytes.fm/scout to check it out.
Thank you to Scout APM for supporting Python Bytes.
Off to you, Brian.
What's next?
Well, next we've got something fun.
On real Python, there's a post, build Conway's game of life with Python from Leodonis Ramos.
And I just couldn't resist because I think I have a feeling that maybe there's some new,
like younger software folks that maybe aren't familiar with game of life.
Maybe I've got to live a while to know about the game of life.
Well, I hope everybody knows about it, but it's a it's kind of fun.
And so this is just a fairly good walkthrough of if you were going to build game of life.
And it's one of the cool things about it is building on the command line.
It's using art parse, but also curses.
And you've got a curses version in the terminal of game of life.
And how cool is that?
It's pretty, just pretty fun.
Looking through, I've seen some rather awful implementations of game of life over the years.
Like a little bit of Pearl golf going on sometimes.
But the this one looks pretty good.
It walks through setting up an entire project using PyProject.toml, which is great.
And then talking about the different splitting up the implementation into like a grid in one module,
the patterns in another, different views, and then the CLI in another.
Just the split up looks good for modularizing the application.
And kind of if you're a lot of times people want to play like build games or something.
And this is kind of a game that you don't actually have to play.
It just plays itself.
So it's a I just wanted to highlight it.
It's just a fun, fun walkthrough of implementing game of life.
Yeah, that's, you know, you already talked about these little projects in your first thing, right?
Here's a cool little project that you can play around with.
And I think games are a good way to get into coding.
Not, you know, Doom, Half-Life, whatever.
I've been playing a ton of Small Lands, by the way.
Also not a good way to get into programming.
Seems like something that would take forever.
Well, Small Lands is awesome.
However, I think this is like little games.
You know, they're easy.
You don't have to have a huge amount of domain knowledge.
You don't have to know about like databases and connection strings.
And like, how do I embed the password?
How do I make it run?
All that.
Like, just have fun.
Yeah.
And so one of the fun things about this is like the hiding of, so it has like a life grid.
So one of the, of this project, almost all of the project is going to be transferable to other stuff,
except for the curses part.
Like, I'm probably not going to write a whole bunch of curses applications.
But that's the same thing with like most, a lot of games.
Unless you become a game developer, a lot of the game development,
it's using some sort of, you know, user interface stuff that you're probably not going to use
for a lot of projects.
Unless you go into using game, writing more games, which is great.
But having that isolated off to one little part was actually, it's pretty kind of nice to be able to set that.
Anyway.
Good.
Yeah.
It's really cool.
It is cool to see how you might create that little UI as, as well.
I mean, usually people are doing Unreal Engine, Unity, Pi Game, Arcade.
One of these is like quite, you quite deep down in those frameworks.
Yeah.
And it's just a little bit.
One of the things I wasn't sure about, and I, so I, I didn't see any disclaimer at the top.
I did not run through this, but was if I didn't know that you could use curses on Windows, for instance.
So is this a, maybe somebody in the, in the audience knows if you could.
Yeah.
Maybe someone knows.
It might be because of Windows terminal versus command prompt.
Oh, okay.
Yeah.
Possibly.
But I have, that's a guess.
Zero knowledge.
All right.
Enough of this fun, Brian.
Let's get down to business.
Okay.
Polar's business, that is.
This comes from Marco Gorelli.
And this is just a simple plugin for Polars.
Now, if you don't know Polars, Polars is like Pandas with two major differences.
It has a lazy, fluent API.
So you can kind of chain commands together and it doesn't actually execute until you kind of work
through them kind of like generators and those sorts of things.
And it's written in Rust to be super, super fast.
So this is a plugin for Polars.
And the idea is it lets you answer questions like how many business days between now and then.
So if like my, my payment system says you get paid net 30, well, or you get paid after 10 business days.
But one of those days is the 4th of July.
And then there's the weekend.
And then there's like how many days, you know, calendar math is already gnarly.
If you want to like throw in skipping weekends, skipping holidays, even worse, right?
So super simple.
This thing, the extension itself is written in Rust.
So it's kind of compatible with Polars.
I believe Polars has actually a Rust API as well as a Python API.
So maybe this is available there.
I have zero information about that.
All you do is you can even define your own holidays and weekends.
Like every Wednesday, I'm taking it off, whatever.
So the way it works is you just go import Polars and then Polars business.
Somewhere down here, you can go to grab a column, say offset by and just say 5 BD.
And it'll skip by, you know, it'll go through all the columns, figure out what their dates are.
And using vector math, convert those to five days ahead by however they offset, like each one individually.
That's pretty awesome, right?
Yeah.
Fun.
Yeah, I don't know how that works.
That sounds complicated.
But yeah, so you can put in like, what are your weekend days?
What are your others?
You know, obviously Saturday and Sunday is pretty standard, but like we have restaurants around here that are closed on Sunday and Monday.
They're open on Friday and Saturday.
So if you're trying to like do business math around like that kind of schedule, like you could just say Sunday, Monday for your weekend and you're good to go.
Nice.
Yeah.
Well, like one of the things I was thinking about, it was like education wise, schools often have like tons of.
So many times, so much time off.
Yeah.
Like in like teacher non-work days, which or whatever, it's the teachers are still working.
It's just the students aren't working.
They should call it student non-work days.
They should.
Yeah.
Like my daughter is like, oh, I don't have school this week.
I don't have school this week.
Why?
Like, oh, it's parent teacher conference.
Oh, my.
Okay.
Yeah.
My daughter even calls, they call it, her friends call it like no school November.
Yes, exactly.
Exactly.
Anyway.
All right.
So that would be good for that.
Or lots of other businesses have wacky holidays.
So people can check this out.
It's, you know, easy to understand, easy to adopt if it's relevant to you, but it seems pretty cool.
Yeah.
All right, Brian.
How extra do you feel today?
I just have one extra.
And that is last week you get what I got convinced that to do a Black Friday sale for the complete
pie test course.
And it is one word, Black Friday, all caps, just that.
And you get 50% off the course.
So check it out.
And over the break, I did a whole bunch on it.
So I've up to, what, chapter 13.
Oh, chapter 13 was great.
I wanted to talk about that a little bit.
Chapter 13 was on debugging.
And instead of just, like, artificially adding errors to the code, I decided to do a, like, a test-driven development little thing of writing a couple tests first, doing the implementation, and resisting the urge to refactor during the implementation.
And then once everything was green, going back and doing a refactoring.
And then explored, I enjoyed learning this anyway.
So it was exploring testing or debugging using pytest plus PDB for the Python debugger.
One of the cool things about learning PDB is you can use it with talks.
So you can debug an individual environment if maybe your code's only failing on 3.8 or 3.9 or something.
So anyway, that's still up.
And that's my extra.
How about you?
Very cool.
Yeah, congrats on getting chapter 13 up.
And I think debugging 13, I think stuff could go, that's perfect.
As long as you didn't release the chapter on Friday the 13th, everything will be fine.
Right.
I got a few things.
First, there was, like, a really heartfelt message from Kenneth Wrights that he posted on X Twitter.
And so I thought maybe I'd just read that because it's, you know, just kind of remind everyone of, you know, how nice the community is and why we all like to be here.
You up for that, Brian?
Yeah.
All right.
Kenneth, who's done things like requests and many other projects, says, dear Python community, I hope this letter finds you well and thriving in your various endeavors.
Python, my name is Kenneth Wrights.
I've been part of this vibrant community for quite some time, contributing to projects like Quest, Pip, Envy, and among others.
Today, I write to you not just as a fellow Python enthusiast, but as someone who, like many of you, have faced moments of uncertainty and feared my journey with programming.
It's a path that, while rewarding, is often fraught with challenges and moments of self-doubt.
I'm reaching out to share these feelings because I believe in the power of our community to support and uplift each other.
In recent times, I've found myself grappling with a sense of fear, fear of not living up to expectations, fear of the unknown or ever-involving field, and perhaps fear of not being able to contribute as significantly as I have in the past.
These are feelings I'm sure many can relate to.
But in these times of vulnerability, that I'm reminded of the strength and compassion of the Python community, that we're a group that not only shares a love for programming, but also cares for the well-being of its members.
Your support, encouragement, and willingness to share knowledge and experiences have always been a source of strength for me.
So, reaching out to ask for your understanding and continued support, not just for me, but for everyone in the community facing similar challenges.
It goes on. I'll let people read it. I'll link to it in the show notes.
But I just think that's kind of a nice message, and I wanted to amplify it a bit for Kenneth.
Yeah.
I mean, obviously, he's someone who I know many people look up to as like, wow, look how much he's accomplished.
And so, if you're feeling uncertain or like you're not contributing enough or whatever, like if Kenneth also feels that way, like, you know, maybe these are just feelings people have and not so much things that should stop you.
All right, so that's one.
Remember last time I talked about Python 3.13.0 alpha 1 being out?
Well, this time, since it was so close to when 3.2 or alpha 2 was coming out, alpha 2 is here as well.
So, I just wanted to link over to that.
Really, many of the features that they talk about, what's coming in 3.13 really just has to do with like deprecations and very concrete stuff.
But I know there's the faster CPython initiative making a lot of changes, although they're not even at all mentioned here.
It's like we remove many deprecated things and many of the dead batteries that we talked about, like Telnet Lib.
Go find another way to implement your Telnet client instead of the standard library and so on.
So, alpha 3 will be scheduled for December 19th.
So, we can round out our year with a third Python 3.13 alpha release.
So, that's nice and quick.
And finally, as you touched on as well, thank you to all the people who participated in the Black Friday thing.
And just, we raised a bunch of money for charity, which is awesome.
So, really happy to have done that.
So, just a bit of a heartfelt thanks on my end for people who participated.
All right, ready for a joke?
Yeah.
The joke is called Select Star, and I think we can all relate to it.
Okay.
So, Select Star being theoretically a bad thing.
Can I get this image all the way over?
No, not really.
Okay.
So, the question here says, it's a person.
I think this is Will Smith from iRobot kind of type of thing.
Anyway, it doesn't really matter.
The developer says, can an AI really write efficient SQL queries?
And the AI looks back at the developer and goes, can you?
The developer goes, hmm.
Maybe not.
And, of course, the title is Select Star, which is like barring joins and other crazy group buy stuff.
Like, pretty much the worst thing you can do for performance.
Like, give me everything.
I don't care if I use it.
Right.
I know there's like a 10 kilobyte per row description.
I don't need that.
Just give it to me anyway.
I think this is like the ideal use case for using an AI is optimizing SQL queries.
Yeah.
Anyway.
I wouldn't trust.
I don't trust myself with production SQL.
Can an AI really write efficient SQL queries?
Can you?
Okay.
Well, I see some agreement in the audience out there as well.
Very nice.
I want to add a just a funny thing that my wife shared with me yesterday.
And as many of you know, or maybe you don't know, I used to have short hair and over the pandemic,
grew it out.
And now I have longish hair.
I would say that counts as long.
And so often it's pulled back, but it's often not also.
So I wanted to share this, this funny thing that my, my wife shared said, I admire those
with hairstyles.
I don't have a hairstyle.
I have hair.
Most are most days.
It has zero caterpillars in it.
That's as good as it gets.
So a girl, woman with like long flowing air.
I just, honestly, the length is about the same as yours right now.
So that's pretty awesome.
And apparently this was, that came up by Tom Cox.
So that's funny.
Anyway.
Yeah.
Very good.
Well, also a very good episode.
Good to be back with you and with everyone.
Yeah.
Thank you.
Yeah.
You bet.
Thanks everyone for listening.