Python Bytes - #389 More OOP for Python?

Episode Date: June 24, 2024

Topics covered in this episode: Solara UI Framework Coverage at a crossroads “Virtual” methods in Python classes Extras Joke See the full show notes for this episode on the website at pythonbytes.fm/389

Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds. This is episode 389, recorded June 24th. I'm Brian Ocken. And I am Michael Kennedy. This episode is brought to you by Scout APM. Listen to their spot later in the show and check them out by going to the show notes and clicking it. You can connect with us on Mastodon. We love hearing from you. And if you're listening to this later, join us live every once in a while if you want.

Go to pythonbytes.fm slash live to be part of the audience, and it'll tell you when the next episode is. And I'd like to say thank you to everybody that signed up for the mailing list to get our show notes. It's nice to see that little creeping up in listeners. And I actually find it quite handy to find those notes later on also. Absolutely.

Brian, I would like to add, we're coming up on a milestone number there, and I feel like we should probably do some kind of giveaway or some kind of contest. And they're probably up in about the next month to six weeks. So you to be on the list to win the prize that we invent for the thing that we'll talk about later so sign up yeah

on my side of him click on newsletter put your info in all right well why don't you kick us off with uh it's a nice sunny day um maybe a some sort of solar topic for yes let's do it let's do it how about this brian let's talk about solara and this one comes to us as a recommendation from a listener so thank you to florian for sending this in solara is uh solar solar i don't tomato tomato solara is a pure python framework but in react style so it is a sort of rapid application development, somewhat data science-y focused front-end framework, a framework for building front-end UIs.

That's like React that allows you to write better Jupyter and web apps. So it does this by basically integrating IPy widgets and other types of React-based APIs, programmable like code, not APIs you call call on top of I Python widgets. So that's super cool. It can either be stuff that runs inside notebooks that makes them better interactive things, or it can just be standalone web apps, like fast API or stuff like that. Yeah. Pretty neat, huh? Yeah. So we always need more, more, uh, UI frameworks than Python. I believe I would put this if I was considering streamlit or dash or something along those lines, it's kind of in that realm. Okay. So let's see, it talks about the benefits of things together, but the most important thing I would recommend to you is, um, probably check out their examples to start. So let's, let's check out their examples. So in this area, we've got a whole bunch of different examples that don't want to scroll.

Why won't you scroll? Hold on. There we go. Now it's girls. Yay browser. So let's pick, let's pick one of these. Let's go to the full screen ones. These are fun. Jesus really doesn't like the scroll, does it Full screen. Okay so we've got different ones here. You can just pull these up and let's just say the scatter one's kind of interesting. Check this out Brian. This is how this works. So you take your ipython widgets, your notebook like stuff, and look what you would see on the screen if you load this up. It's like a fulli that is just it fills the screen here right and you can either upload a data set and figure out i don't know how to figure out what the data set's supposed to be but probably a csv or something and then you can also just click show

me the sample data and check it out you get this cool interactive probably plotly uh yes plotly ui here and i can change the size of all these things that it check that it works on I can say I would like to see this talks about like GDP life expectancy by country so I could say I want to see the life expectancy by country and pull that up um continent rather I think is how they have data where's this it was working just a minute ago why is this not running for me maybe i made the size too weird for it don't know uh let's go entry nah i guess i'm picking the wrong thing that's just the live demo curse it just won't work it totally is i don't know why it's not working anyway there we go i have to just have to reverse it there we go this is looking good so uh you can say show me the

life expectancy by country and then you get all these really interesting interactive bits. You can resize it. So this is all a super easy UI to build, Brian, with this UI framework. That's pretty cool. And if you go back and look at the example, they'll show you like one of the cells in a Jupyter notebook

can just be this graph here. And it has a full screen option or it can just be like the output of a cell it's one of these interactive apps how does that huh that's crazy yeah and then you can also go and see you know what does a tutorial look like somewhere I gotta go to get started quick start so if you go to the quick start it'll show you basically how to program this stuff. And it's super easy. You just put a decorator, say this is a component, and it shows up in your page.

It's really focused on building these little reasonable and composable components. So it's a little bit like Shiny, actually, I think, actually. So anyway, super cool way to build these interactive dashboards and stuff that's more than just a picture, but a thing you can actually play with and publish to the web yeah especially i love stuff like this like especially if you don't really know how you want to look at the data yet um so you can you can give people lots options too absolutely and it i don't see a price all i see is staris on github so i think it's just

a open source project that you can use for your stuff, not a commercial thing from what I can tell. So one of the things I was, I was looking at this the other day, and I don't know if you came across an answer to this question, but was, it said a pure Python React style framework for scaling Jupyter and web apps. The and is like, I was a little bit confused. Does it, do i have to be a jupiter type programmer to do this or do you know if i know if you want to use fast api it can and there's a thing called uh what do they call it um a so solaris server or something like that so you can run that and it says look at a run of fast api starletask, and so on. Okay. And I imagine you just create, just basically serve up some common template that starts it all, those kind of things.

The other thing that's worth pointing out in this whole discussion is it's built on top of Reacton. And Reacton is this interesting project here. It says it's like React for, yeah, it is. It's a really good logo. It's a Python logo as the nucleus of an atom and then a bunch of little small Python logos circling it like electrons. It's good. So this basically lets you create code for IPython widgets that is in the style of React. So if you go down here, here, you can create, for example, a component which is a clickable button, and you

basically initialize the state, and then you write the handler. And just like the handful, it's a code. Yeah, it's pretty neat. So that's what this thing is all about, is creating these little widget-type things, or components, and then building up your UI out of it. So I say certainly worth checking out. I kind of want to just do one of those, like just a button that just tells you how many times you've clicked it.

Exactly. I'm not going to do anything, but. After it gets out. Yeah. After it gets past a hundred, it'll be like, what are you doing with your life? Leave and go do something else. Stop clicking me.

Yeah. All right. Yeah. All right. Yeah, people check that out. Thanks, Florian. Next up, I wanted to talk about coverage a little bit. I think, no, I'm on the wrong page. I do want to talk about coverage. So Ned Batchelder wrote an article called Coverage at a Crossroads.

And so there's a couple of things I wanted to point out about this. The really, so just the gist of it is it's a, there's, Ned wants to make coverage.py faster. And one of the issues is the way, with the way coverage is written right now and the way it's composed. So he starts the conversation discussing really how coverage works. And that's the part where I really like, even if you don't care whether coverage is fast or not, this is a nice fun article to realize how coverage works. And so

coverage uses a thing called a trace function. So it takes your code and adds these trace functions to every line so that coverage can know when any line gets hit. And then coverage also does branch coverage. So coverage does branch coverage with allowing a thing called the arcs. So it generates these four lines that look like branches, these arcs of like it could go like your line. You could go from line one to line two or line two to line three, things like that. And so it keeps track of all that. And the reason why things could be faster is because like, let's say you hit line two already.

You don't have to. And there's no branches in there or anything. It's just a line of code. You wouldn't need to actually hit the trace function every time you hit that, but there's no way to take it out. So there's some ideas around making it faster. And SlipCover, for instance, has a bunch of ways. So he uses a bytecode thing that there's a discussion around SlipCover

as a different coverage tool. There's also discussion around sys.monitoring that came in in Python 3.12. And with sys.monitoring, you can do something like a trace function, but it's something that you can take away later. So the idea like for line coverage, this would work just great. So you could just say with sys.monitoring every time, if I hit this line, great. Now I can take that out. So I don't have to worry about that line ever again. And then, but there's some discussion that Ned has around how do you deal with branching for that? And it's an interesting take on kind of an interesting idea. There's an interesting problem set for how to deal with it.

Kind of like maybe arcs aren't the right way to do it. Maybe there's some other way to deal with branch coverage. And it's not trivial because there's an example of a try finally block with a return statement happening in the try. So you don't necessarily hit, you always will hit the finally, even with the return, but you don't know if you'll hit the line after. You know, you'd have to look at the code. But really fun discussion.

There's a call out of where, if you want to get involved, you'd like to offer some solutions or just help with the discussion. There's that too. But even if you're not going to help, I think it's a cool discussion of how coverage works. And I also just wanted to thank Ned for putting time and effort into making sure coverage is an awesome tool. So thanks, Ned. Yeah, that's pretty excellent. And of course, there's going to be functions and branches of

execution that are in some kind of tight loop and run a million times but after the third time you've already realized it's 100 covered yeah so if you could just because uh running with coverage and stuff like that all this profiling and code coverage stuff puts a serious hurting on the performance so if you could say all right that part's done 100 stop stop slowing it down that'd be cool yeah i i did like the this this cool idea of um with the other ones of creating like adding no op statements in just so that for branches so you just like check to see you know if i if i hit that then that branch was taken that's kind of a neat idea you could you, you know, add these extra little hooks, but yeah, anyway, cool.

Awesome, awesome. Up next, thank you to Scout APM. Let me tell you real quick about Scout APM. They're big supporters of Python Bytes, so we appreciate that very much. So if you are tired of spending hours trying to find the root cause of issues impacting your performance,

then you owe it to yourself to check out Scout APM. They're a leading Python application performance monitoring tool, APM, that helps you identify and solve performance abnormalities faster and easier. Scout APM ties bottlenecks such as memory leaks, slow database queries, background jobs, and the dreaded N plus one queries that you can end up if you do lazy loading in your ORM. And then you say, oh no, why is it so slow? Why are you doing 200 database queries for what should be one? So you can find out things like that. And it links it back directly to source code. So you can spend less time in the debugger and healing logs and just finding the problems and moving on. And you'll love it because it's built for developers by developers.

It makes it easy to get set up. Seriously, you can do it in less than four minutes. So that's awesome. And the best part is the pricing is straightforward. You only pay for the data that you use with no hidden overage fees or per seat pricing. And I just learned this, Brian. They also have, they provide the pro version for free to all open source projects. So if you're an open source maintainer and you want to have Scout APM for that project,

just shoot them a message or something on their pricing page about that. So you can start your free trial and get instant insights today. Visit buythumbysite.fm slash Scout. The link is in your podcast player show notes as well. And please use that link. Don't just search for them

because otherwise they don't think you came from us. And then they'd stop supporting the show. So please use our link Python by side of him slash scout. Check them out. It really supports the show. This one, Brian comes to us from another Brian. Okay. Way in the past though.

This is Brian skin that back in January said, Hey, guess what? Hep six, nine, eight has been accepted. How awesome is that? And I haven't, it hasn't bubbled to the top of my list until now, but I think it's, we're talking about this is in Python three 12 and, uh, Leah, let's, let's check it out. So if we go over to the pep, it is an override decorator for static typing. So, you know, some languages, um, C-sh sharp, I think C plus plus, but it's been a while since I messed with it, you know, have explicit override keywords and virtual methods.

I know C plus plus has virtual methods. I just don't know if you indicate that you're overriding it. Tell me, Brian, do you use the override keyword or do you just, do you just write the function? You just, just write it, but you can. Yeah, that's what I thought. Yeah. Yeah. And in C sharp, you actually say there's a virtual function in the base class, which

is intended to have a potential people overriding it. And then in the, the derived classes, you say override instead of virtual to indicate that you have to say that, right. To say that you're, you're replacing this behavior and you might need to call the base class version and all that kind of stuff. Well, basically Python gets that if you want it. As a lot of things with typing, it's optional in multiple ways. So let's jump over if you scroll down. It's kind of weird to me. The PEP says this PEP is here for historical reasons.

It's now part of Python. So please see override. When you click it though, it doesn't take you to the Python documentation. It takes you a separate typing documentation for Python, but it's also in the Python documentation. Interesting. Which one wins? I don't know, but whatever. The example here in the link from the pep is super clear. So you got a parent class and you don't say virtual

because we don't have that, but you can say at override. So the parent class, the base class has a foo function that takes no parameters and returns an integer. I'd hear you in the child class, you say override and then as a decorator and then foo, same signature. And if you were to say override something that didn't exist, type checking will say there's no signature.

Your intention is to override this thing, but it didn't exist, type checking will say there's no signature. Your intention is to override this thing, but it doesn't exist. Maybe you meant to type, I don't like these examples, but this is what's written here. So here we go. You overrode foo because that existed, but you tried to override baz,

but it's bar and you misspelled it or something like that. Now, I don't know what happens if you mismatch the parameters, but you get the name right. You know what I mean? Like I'm overriding. It takes two parameters.

Like, no, it takes one. I don't know. I have to test that out. But anyway, if you want to have a little bit more validation in your Python typing for your classes and your inheritance, check this out. It's part of Python. It's nothing special that you add.

It only executes at definition time for the class. So it's not like a runtime type thing. So it should be low overhead. Yeah, pretty neat. Why not use it, right? Yeah, low overhead, high override. High override, low overhead. That's right.

There you go. All right. Well, thanks, brian skin for sending this in and uh yeah interesting cool um one of the other things that's neat is speeding up um speeding up python bits um and so there's a there's kind of a neat article called uh from gauge oh that must be the group that makes this stuff. Anyway, called Parsing Python ASTs 20 Times Faster with Rust. So this article is talking about

speeding up a tool called TAC. Now, TAC is a CLI tool that lets you define and enforce import boundaries between Python modules in your project. Yeah, remember, I talked about Python modules in your project. Yeah. Remember, I talked about that a few weeks ago. Yep. Actually, right?

Yeah. Episode 384, you talked about it. So yeah, that was just May 21st, just a couple of months ago, or last month. Nice. Anyway, at first I'm like, okay, you sped up with Rust. We're kind of hearing that. Why I'm calling this out, though, is not just that tech seems cool, is that I really liked the methodology that they're talking through here. So they talk about not just how they made it faster,

but like the process they went to to figure out which parts. So they used profiling, they used a pro used profiling, but in specific, I think they used a tool called pie spy and speed scope to, to visualize the and get flame graphs for, for performance. Interesting. I've not heard of either of those. I have not, or, you know, maybe I have, but we, we cover a lot of tools, man. Um, anyway, uh, these look slick,

but the output of it showed that there was roughly 90% of the total time was taken by a function called get project imports. And in that, it spent about two thirds of the time parsing the ASTs and the remaining one third traversing them. So some great information and some great examples of instead of trying to just throw rust at it to speed things up, or even just, you know, using Python to optimize your own Python, taking a look at exactly what you're doing and only speeding up

the little bits that are slow, which is, I love that aspect of this. So, okay, so they took those bits, also went by and there's a discussion of why the AST parsing was slow anyway, because that should have been some C code as well. But there's a little bit of a deep dive into there, but then they jumped into just rewriting it in Rust. And then we've covered these tools before using PyO3 and Maturin

to help quickly develop some Rust for a couple functions. And yeah, so that, that was it. And it like went from what the, the example they had was a code base, but there was a common code base, which was the century code base, about 3000, 3000 lines of Python files that took like 10 seconds to, to, to test. And with this speed up, it dropped it down to one second. So that seems like a pretty fast speed up. So nice. Yeah, that's real nice.

Also just kind of a great user example and a short write up on using profiling to really look at where your bottlenecks are and then maybe throwing Rust at it there. Yeah, and it looks like they just basically re-implemented that one function in Rust and then just used it as a dependency, right? With their PyO3 extension.

Yeah, so I totally want to try that. Like just that'd be a great way to get into Rust a little bit is to just not try to make a Rust application, but just replacing like one, one function. This one algorithm is called a ton of times. It's super slow, relatively. It's where we spend all our time, but it's not that big, right? Like we could write it, probably figure it out in a day or two and rust and then off you go. Yeah. I don't need to learn all the rust. I just need to make this thing faster. Tell me how to do a for loop in Rust. Tell me. Okay.

Well, tell me, Brian, do you got extras? Do I have extras? Let me check. Yeah, I do. Last, when was it? Let's go ahead. Episode 388. That was just last week, wasn't it?

It was last week, where we talked about not deleting all the repos. Yeah. Well, one of the things I talked about was, what did I talk about? I talked about import by string with packageutil.resolve name. Bad on me for not doing my homework a little bit. Brett Cannon notes that discussions around this are maybe not really great things

because packageutil is deprecated or it's going to be or something. So Brett's recommending not using package util, just FYI. If it doesn't give you a deprecation warning now, it will someday. Don't go that way. Okay. Next up really quickly, kind of a fun thing. At the Python Language Summit, there was a discussion, should Python adopt calendar versioning? And this kind of fun discussion. So we have like Python 3.12 right now.

Should somehow it be like Cal versioning? And if we went to Cal versioning, what would it be? And a fun, I think it was Carol Willing. Yeah, Carol Willing brought up that we want to at least keep our current versioning through 3.14 because then it would be the Py version. Yes. We've got to do 3.14 now. Yeah. So a lot of this boils into a PEP 2026, which is also nice numbering because the shout out of 2026 is when we would switch.

So the idea would be what we've got. Oh, there's a table here. 3.14, no change. That comes out in 2025 if we go to this. And instead of 3.15, we just make the 2026 version 3.26. No. Which would confuse. We're going to end up with a year 3K problem. That's okay.

But that's like 75 years in the future that we have to care about that i guess they could put a one two six then it'll be a thousand years it probably doesn't matter at that point oh yeah we can we can add it yeah so i think i think we're okay um well actually i'm not sure that would be weird wouldn't it i don't know You could have 126. I think you can get to year 2099 without going too bizarrely out of sequence. Yeah. Maybe we're ready for Python 4 by then. No. We're not ready.

Too soon. Too soon. So what do you think of this? It's a little weird to me. Why not just 3.2026, 3.2027? Because to me, this doesn't communicate calendar versioning. We already have calendar versioning if you don't care about what the number is because it's yearly release cycles, right? 312 means 2024.

313 means 2025. And so if you're not using the calendar numbers, I know 26 is closer to 2026 than 15, but there's still, to me, it's like, well, 16, 27, I don't know. It's just, like, here's the next year's version. Yeah. Okay. I'm all for it. I think we should switch because I think that since we've gone to a one-year release cycle anyway, why not somehow encode that in the number? I totally agree with that. I agree with that. I just, my vote's for 3.2026,

like most calendar versioning things. Oh, yeah, just do four digits? Yeah, exactly. That's all I'm saying is just put four digits so it really is the year on the end and it's really clear that it means the year. You don't have to know the code. That's all I'm saying.

But I'm also with uh carol on leaving uh 3.14 um yeah i mean there's nothing saying since it's bigger there's nothing saying we could go to two digits and then at some point go you know let's just throw four digits in there yeah anyway um okay last thing i wanted last extra extra, is Brett Cannon wrote an article called Saying Thanks to Open Source Maintainers. I just want to shout out. This is a really good idea. Quickly, what are our ideas? First of all, just be nice to the maintainers.

This is great advice. If you disagree with something, be polite. Be nice. It's good. Great advice be polite, be nice. It's good. Great advice. Start with being nice. Be an advocate. You don't have to actually thank him directly, but you could advocate for the thing.

So Brett's involvement with buyproject.toml, he sees other people promoting it, makes him feel good. It's a good thing. Produce your own open source code because maybe some of the maintainer might use your stuff now. And then actually say thanks. Nothing wrong with saying thanks to people. And then there's financial support, which is good for some projects to have open source. You know, ways to help fund the maintainers. Those are good too.

But you don't have to fund them. You can just be nice to them, say thanks, advocate their thing. That's good. So in that end, I kind of always forget that Brett was involved with PyProject.toml and we might not be using it as we are today without Brett. So thank you, Brett. I love PyProject.toml. I promote it and encourage everybody to use it. Awesome.

Yeah, thanks, Brett. Thanks to everyone. There's a lot of people I have to thank in this community for this kind of stuff. Yeah. Do you have any extras? I do. Let us,

let us check them out. I think only one extra extra in that is last week. I talked about the shiny for Python reactive web dashboards was shining that course over at talk Python. I said it was going to be available soon. It is now available 100%. You can go sign up for it and take that course. The course is completely free, no strings attached.

So just click the link and take the course if you want to learn about building interactive dashboards. A little bit actually like the Solara stuff, but more full-featured, I suppose. And a little more packaged, a little more like Streamlit in that sense. And then also I talked about working with PyCharm to get people six months of PyCharm Pro for free, as long as you don't already have an account that would have to renew.

With this course, you could just go to your account page after signing up for this and get that as well. So two extras on one tab. How about that? Nice. Yeah. All right, Brian, I need you to put yourself in like a calm and centered place for what is coming next. Okay. Are you ready? This has been recommended to us. Oh my gosh, who sent it in? I'm so sorry if I don't have the name

here. I don't. Cohen, I believe it was. If I got it wrong. I'll correct it next time. This is the Tao of Programming. This is a big, long book here that covers many things. Because we may come back to this, right? But I want to start with book one, The Silent Void, and just read you a few bits of it. And if you visit this webpage, folks, this is best viewed in Netscape Navigator 4.0 or older because it's got like the the digital noise background and all sorts of like whoever thought like this arts and

craft paper was the proper background for reading but here we are oh and also has a frame there's a frame inside of it so it's just missing the blink tag nonetheless here we go here is the introduction for the chapter thus spake the master programmer when you have learned to snatch the error code from the trap frame it will be your time it'll be time for you to leave so let me just read you a couple little sections from this 1.1 something mysterious is formed born in the silent void waiting alone and unmoving it is at once still and yet in constant motion. It is the source of all programs. I do not know its name, so I will call it the Tao of Programming.

If the Tao is great, the operating system is great. If the operating system is great, the compiler is great. If the compiler is great, then the application is great. The user is pleased and there is harmony in the world. The TAO programming flows far and returns on the wind of morning. Oh dear. I think it's a little crazy. This one's good.

This is one too. This is the last one. The TAO gave birth to machine language. Machine language gave birth to the assembler. The assembler gave birth to the compiler. Now there are 10,000 languages. each language has its purpose however humble each language expresses the yin and the yang of software each language has its place within the tau but do not program in cobalt if you can avoid it and fortran and burl anyway this goes on and on. There's books of this stuff. People check it out. It's fun.

Nine books. Exactly. Well, that's, that's the joke for today. If you will, it's the entertainment segment. I'm not sure it's a joke. Yeah, no, that's good. I like it. The meditation, it's the meditation section brian all right so uh with that i'd like to uh encourage everyone out there to send us good programming jokes because we're running dry no that was good um but also yeah we i always love program good programming jokes and dad jokes all together so keep them coming yeah they're always they're always good i um as always really enjoy talking with you enjoy talking with everybody in the community and um and yeah keep on going having fun thanks thanks