#348: Dear PyGui: Simple yet Fast Python GUI Apps Transcript

00:00 I'm always on the lookout for a good Python UI framework. In this episode, we're going to focus on one called Dear PyGui. Dear PyGui is a fast and powerful graphical user interface toolkit for Python with minimal dependencies. It's created by Jonathan Hofstad and Preston Cothren and they're here to tell us all about it. This is Talk Python to Me episode 348, recorded November 18, 2021.

00:38 Welcome to Talk Python to Me, a weekly podcast on Python. This is your host, Michael Kennedy. Follow me on Twitter where I'm @mkennedy and keep up with the show and listen to past episodes at 'talkpython.fm' and follow the show on Twitter via @talkpython

00:51 We started streaming most of our episodes live on YouTube, subscribe to our YouTube channel over at 'talkpython/youtube' to get notified about upcoming shows and be part of that episode.

01:04 This episode is brought to you by SENTRY and TopTal. Please check out what they're offering during their segments. It really helps support the show.

01:12 Let me tell you about a new project I'm working on. It's a YouTube series called Python Shorts. This series will consist of fun and quick videos teaching you one amazing thing about Python. They are usually less than five minutes long and put a practical spin on topics you might have been wondering about but never took the time to dig into. I just released the first two videos, 'Parsing Data with Pythonic' and 'Counting the number of times an item appears with Collections Counter'. I already have a list of about 100 videos to create over the next year in this series, so there will be many more to come. And if you have an idea for one, please shoot me an email or tweet and I'll add it to my list. If these sound fun, please subscribe to my personal YouTube channel. Just visit 'talkpython.fm/pythonshorts' to see the playlist and there you can click on my face and subscribe. You may already be subscribed to talk Python's YouTube channel. That's where we do the live streaming recordings, but I decided on my personal one, so be sure to subscribe there too if you want to get these videos. Thanks for listening and thank you for supporting all of my work. Let's get to that interview.

02:14 Jonathan, Preston, welcome to Talk Python to me.

02:17 I'm glad to be here.

02:18 Hey, it's great to have you guys here. I'm very excited to talk about GUI's and UI frameworks and stuff like that. I think Python needs more of it and building some cool projects frameworks there. It will be fun to talk about it. We're going to talk about Dear PyGui, which is one of these frameworks, tries to have a quick getting started story.

02:39 That is correct.

02:40 Let's just get into your stories. Here a little bit about both of you. Maybe not too extended, but Jonathan, how did you get into programming Python?

02:48 I got into programming when I was around 13 years old, my step dad and mom got me a C++ for Dummies book.

02:57 Okay.

02:57 And worked with that for a while until just as a hobby project or as a hobby thing. And once I got to College, I went to mechanical engineering, which is also where I met Preston. They typically like to use MATLAB, which everybody knows isn't a real programming language. The indices started one, of course, as an alternative to that came across Python. It has a lot of the same features, actually, a lot more features than MATLAB. And it was free, so didn't have to pay for the MATLAB license.

03:28 Matlab is expensive for people who haven't messed with it. It's like really expensive outside the student story.

03:35 It is. And you have to use their entire environment and everything just to use. So aside from that, on top of that, with the Raspberry Pi into electronics and things like that, and the Raspberry Pi are able to control the GPIO pins using Python, naturally. Just started playing with Python from there.

03:54 That's pretty much where Python came into my picture.

03:57 So you said you were in chemical engineering. Is that what it was?

04:00 Mechanical?

04:00 Mechanical. Okay. I was in chemical for a little while and they said that I asked if I could take a C++ class. They said you can as an elective, but you have to take Fortran because that's going to be the most important language you ever learn. I thought, wow, I'm just jealous. Matlab is not that amazing. But I'll tell you what, it's better than Fortran.

04:16 That is very true. We occasionally have to use Fortran at work with our FEA programs, Finite Element Analysis programs with Abacus. You're able to extend it with Fortran. So occasionally we have to look at a little bit of Fortran to do that. It's ugly.

04:30 Yeah, for sure. Preston. How about you?

04:32 Mine was mostly Junior year in College MATLAB course, Incidentally enough. That's why it's not a real programming language. I moved from that directly into Python when I started my first job, and I just started working with C++ after that and then tailed into a little bit of C. Not much.

04:50 Right on. And what are you all doing now? Sounds like still engineering work.

04:54 Yeah, engineering.

04:55 So I'm doing mechanical engineering.

04:57 I do design on threaded connectors. Oil and gas industry mainly designing the seals and threads that hold production tubing together down hole that actually sends the oil up to the well.

05:09 So you must be talking about a lot of pressure. Talking about materials that would like to destroy rubber and other things as well. Possibly.

05:17 Yeah.

05:18 I guess that tails into coding. Mainly, I use most of Python to just extend out because like we were talking about for scripting and stuff like that.

05:27 Yeah.

05:28 Jonathan, I started out in the same position and slowly moved into the software side of things. A lot of that's working with Preston, some of the other mechanical engineers on extending some of those applications, like Abacus, and that using Python or extending AutoCAD. And that's the C++. That side of the day to day work. And then the other side is we actually have some internal software that we work on, one for inspecting connections without contact. So using lasers and robot arms and all that stuff to basically just take measurements instead of having to go out and manually doing this be on an assembly line, and most of that's in C++ and C. We do use our library, Dear PyGui, for a lot of the prototyping and some of the tooling for the project, but for projects in C and C++, sure.

06:20 I don't think I've really covered mechanical engineering on Talk Python properly. What's the story with software automation and that kind of stuff? Is it mostly using programs like sounds like this Abacus one versus writing your own software, doing your own automation.

06:36 A large part of Mechanical engineering, at least in our field, is stress analysis and computational fluid dynamics, fluid flow type problems. And as far as software goes, it's usually in relation to that, like Abacus. As an example, software package for stress analysis. And then there's other ones. Open Foam. Open Foam. You wrote some solvers. That your first job for that? Yeah, that's correct. We took some electives while we were in College, and some of those were for writing these solvers, and most of those you could write in whatever you want. Those professors didn't actually care. And a lot of times I wrote in Python on there. Most of the time it was Python.

07:17 What's the story for packages PyPI type of things in your store as far as what we used?

07:24 Yeah. Is there a lot of stuff out there? I know. For example, Astronomy is filled with libraries like AstroPy, and whatnot that people could just grab and use for mechanical engineering.

07:35 I don't know if there's NumPy or NumPy.

07:38 Yeah.

07:38 But as far as specific to mechanical engineering, I really don't think there's any there may be a few FAA solvers, but I don't think they're maintained or well documented. For sure.

07:47 We typically found that a lot of engineers end up staying in the MATLAB realm and not really venturing into any more hardcore languages. So they end up using it because a lot of them want symbolic math integration and Ode solvers and all that. It's all right there in MATLAB, and then the companies typically pay for so you're in that room.

08:07 Once some group gets embedded in there, it's just going to stay in that space unless somebody takes some effort. All right. Awesome. Thanks for that background. Although we're not here exactly to talk about deep dive in mechanical engineering, it's cool to get a look. Let's talk about your project. Dear PyGui. So when I think of the GUI Graphical User Interface space in Python, there's Tk Enter, there's IQ, there's a few other things, but they all have some kind of oddity about them. There's not like one framework that people just like, yeah, we're just going to use that thing. It's not like Swift and Objective C Coco controls would be in, say, iOS app or something, whereas it really could generally use that one. Where did you guys get started working on GUI's and Python? What was the goal with Dear PyGui? Like, where does it stand out? Where does it fit in this space?

08:57 I got started in UI, working at one of my internships while I was in school, and we were using this package, which I think already mentioned once.

09:07 OpenFOAM for CFD, and it didn't have a front end interface at all. It was a C++ solver that just pretty sure just output text files in the end. I don't remember. It's been about six or seven years. So I wanted to build a UI so that the other engineers could use it. At that time I was just getting into it. So I used to TKenter because of Python and then also used VTK, if I remember correctly.

09:32 I would say that's the first experience I had with it. And then our senior design project being pressed. We're also on the same team for that was to build an arc welding 3D printer.

09:42 It actually created things by doing arc welding.

09:45 Right.

09:47 Some other sort of material out of it.

09:50 Right, Yeah, welder I was on the software side. That person was on a lot more of the physical side. We should focus on the software for now. Yeah. Anyway built, that was the goal of the project, and we use some open source slicing software. I don't remember it's like Slicer 3D, but it's three for the E slicer and it has three for the E. And we basically modified that and ran it in a headless mode and built a UI on top of it using to enter. And once they use Py game to be able to access OpenGL and Tom Reefs Legacy OpenGL, those are first experience with graphics APIs.

10:28 Yeah, which OpenGL is pretty neat. It was certainly good when it first came out. It was as good as anything else, but I feel like it hasn't been getting the same amount of growth and adoption. Maybe some of the other frameworks, DirectX and Metal and so on.

10:43 Dear PyGui uses DirectX Metal and OpenGL at the moment, so we've been using a lot of them over the last few years, and biggest reason for that is just that the hardware has changed since those APIs were created and they no longer directly match the hardware.

11:01 Dear PyGui came out of trying to basically build something better than Direct OpenGL access, would you say? Or Direct Framework access?

11:12 Not quite. It came more out of, I guess, going back to answering where DBG itself came from. We had a previous project that we worked on, a commercial project called engineers sandbox the program had an embedded Python interpreter in it, and you basically created little mechanical engineering apps and we could create one in an hour or two and it was just this collection of apps. And over time it started to get a little annoying to have to recompile it, especially before we added Python. We added Python because we were getting tired of recompiling it every time we want to add an app or modify something and have to redeploy from there. We embedded Python and it's very limited. You were able to create a few small apps. It really wasn't a full GUI library. What happened is we were trying to sell it didn't really work out. We can never really catch traction. We had some users and customers, but most people weren't really interested in it and developers aren't really interested in paying for libraries or any SDK wanted to be free, so that just kind of fell aloud. We gave up on that after that.

12:20 It's a tough place to be, right? You want to put a lot of energy into building tools and making stuff for people. How do you put enough time into it if people just want it to be free?

12:30 Maybe what we got to do is maybe the world is the VS Code model where there are large companies that have other motivations for creating it rather than directly funding through that. But that's a deeper conversation.

12:44 Selling to developers in the easy is the key point there.

12:48 We did keep it in house and we still have apps written in our day job. We ended up revisiting it because it didn't do everything we wanted to do. And we said, this time, let's target developers from the beginning. So it's not going to be very limited.

13:01 You should be able to do most things you can do in any other UI library, and on top of that, make it free. And that's where Dear PyGui came from. And between those stages we came across the library I'm GUI or Mgui, which I'm not sure if you're familiar with.

13:17 But yeah, I'm not familiar with it. What is this? It is the ImGui.

13:22 It is an extremely popular immediate mode graphical user interface for real time applications usually use C++. Yes, it's C++. Yeah, but it's kind of a weird. It's an immediate mode interface and there's not many, I would say there is no Python user interface that's like that.

13:43 Maybe we should talk about the different modes real quick since you bring it up. Is immediate mode versus retained mode. What is it? What does that mean?

13:52 I take this one, so I don't want the Internet to jump on me here because there's a little bit of argument there. But there are a few key points I think that really make it stand out. One of those is that the stage is not retained. If you have a slider that controls a float, you don't have to basically have a float stored on your side and a float stored in the UI, and you're constantly having to deal with keeping them up to date and things like that. Instead, the library itself doesn't store that at all. Now, the way it's implemented, it's a little different, but I'm talking about from the user side of using an immediate mode library, it doesn't retain any state. The other big thing is that, at least especially with GUI, is the UI items and widgets are submitted every frame. So 60 times a second. And that gives you a credible amount of dynamicism, I guess you call that. So we had to do a lot of things. We completely redo the UI on a per frame basis. You can. Yes.

14:53 As opposed to something where maybe you say a text box goes here and a button goes there and then set the text the button, and then the button knows what its text is. This is almost like a game loop type thing where each time, whatever the frame rate is, 50, 60,200 frames a second, it's like draw the UI, draw the UI, draw the UI, right.

15:13 Yes. And very interesting. That kind of 60 frames a second can lead into. We just put in a few weeks ago talking about not redrawing the UI every 60, every frame. Right. That's a good point one of the issues we had, especially early on with some users complaining as well. Do you need to update everything every brain 60 and 60 times a second? So we did recently, adding 1.1 the ability to basically stop, only update if there is some user input, whether that's moving the mouse or resizing the window, things like that. Because a lot of people.

15:46 They can plug in to be more energy conscious with having a your GUI.

15:51 Which you might care about, say on a laptop or a tablet, but less so if you're plugged into the wall, right? Yeah. Interesting.

15:59 And even some of the new are they pro res displays like the new MacBooks and stuff like the entire display will slow down. Stuff is not happening. And I wonder if maybe if you had GUI app that was refreshing the screen a lot, maybe it would prevent it from actually going into a slower mode.

16:18 Look into that variable refresh rate plays into the software actually rendering.

16:22 Yeah, I don't really work at that level. I don't really know for sure, but all in the same space a little bit.

16:30 This portion of Talk Python to Me is brought to you by Sentry. How would you like to remove a little stress from your life? Do you worry that users may be encountering errors, slowdowns or crashes with your app right now? Would you even know it until they sent you that support email? How much better would it be to have the error or performance details immediately Sent to you, including the call stack and values of local variables and the active user recorded in the report with Sentry. This is not only possible, it's simple. In fact, we use Sentry on all the talk python web properties. We've actually fixed a bug triggered by a user and had the upgrade ready to roll out as we got the support email. That was a great email to write back. Hey, we already saw your error and have already rolled out the fix. Imagine their surprise, surprise and delight your users. Create your Century account at talk.

17:19 Python.

17:20 .Fm/sentry and if you sign up with the code talkpython all one word. It's good for two free months of Sentry's business plan, which will give you up to 20 times as many monthly events as well as other features. Create better software, delight your users and support the podcast.

17:38 Visit talkpython.

17:39 Fm/sentry and use the coupon code 'talkpython'.

17:45 It looks to me like there's some similarities from the ImGui in terms of the UI look and feel, but then you've got the retained mode versus immediate mode and things like that. What's the relationship between these I'm GUI itself

18:00 Just outputs. You can read this, read me, but outputs an optimized Vertex buffer. It sends basically the coordinates and everything needed to draw the UI, but it is up to you to take that and actually do something with it and render it.

18:14 We use I'mGui to basically create those Vertex buffers. As far as the retain mode stuff, originally we were doing more of a one to one wrapping with that library, and we started to hit some performance issues with Python itself just because 60 times a second. If you're having to do a lot of conversions between maybe the Python types and underlying C types, that can slow things down. Also, just the GIL gets in the way with a lot of different. So what we did with the retain mode is we basically just created a barrier between that where we do go against the immediate mode style thing, and we do keep up with things like the underlying values, just the floats, the INTs, the strings, whatever it is. So it goes back to a more retainer, which is what every other library is that most Python users will be used to. That flow actually stores. Sorry, input text has its underlying string and you can get that value, set that value.

19:09 A lot of UI code. You don't even need to have some variable that holds the thing. You might just put it in the button and if you need it back, you could get it from the bottom potentially, right?

19:19 Yes. And that's how it works, I guess one of the only other things that's neat is underneath it is just a raw. I'm pretty sure part of these in smart pointer and you can actually link a lot of these widgets together to when they're truly controlling the same value, and you can get some pretty cool effects with that. So we're directly moving this slider is updating the plot and there's not some update code that's happened to happen or any callbacks. It's just that they're truly the same value. And because we're updating 60 times second, you're able to see those changes live, which is pretty neat, and you can create some pretty cool stuff with that.

19:54 Yeah, that's fantastic. Before we jump into some of the details, if you visit the GitHub page, which of course I'll link to, maybe just talk through some of the features. I was going to go to the Gallery, but maybe the features is a better place to start. And you guys have this engineering background. It feels like a lot of what this creates and allows us to build really easily has this engineering visualizing aspect to it, right? Yeah. So maybe talk us through some of the features and things you can do. So, for example, one of the things you have you see right at the top of the feature section is the Im Plot stuff, which looks like really interactive and dynamic, all plots and graphs and pie charts and so on.

20:35 Yes.

20:36 It's another immediate mode interface. That the guy that wrote it, Evan Peasant. I'm not sure how to pronounce his last name, who also happens to be located here in Houston, wrote it on top of on GUI and tried to model that immediate mode interface. So again, you get all the same dynamic features that you get with GUI itself. And that's why you see on here a lot of the how crazy dynamic it looks. Right. With the live querying and everything you see there. And obviously again built on top of it, because we have to go from that immediate mode to retain mode style. And you have multiple axes. You have drag and drop support, custom drag and drop support. There's a lot of series you don't see there candlesticks, shaded series, stem plots.

21:21 One that looks really good is this one down here that has full zoomed out graph and then a graph below it that as you pan around and Zoom in, you can actually it's like a high level and then a low level or zoomed in detailed view of what you're exploring there.

21:37 And that's pretty obligation. Then the demo that's actually not technically built in. That's a query region.

21:44 So you have to set up another plot with the same also looks like they have animations and stuff. The one below it sort of just cruising by without any interaction. So are you able to just feed it live data and it just keeps refreshing 60 frames a second or something?

21:59 Yeah, that's exactly how it's working, because it's again, already updating 60 times a second. All you're doing is changing the data. And just by default, you basically get an animation.

22:09 If the data changes, it's going to rerender it no matter what. And so then it gets a different picture, right?

22:14 Yes. It's worth noting that it's only 60 frames a second.

22:18 If you use V Sync with your screen.

22:21 It actually runs as fast as your screen can run. So 144 to whatever hurts your monitors on interesting GPU and everything else. Yeah. We'll control the render loops.

22:32 You can actually slow it to whatever exact frame resolution you want. 30 whatever you want

22:37 Right.

22:37 You probably can't exceed your monitor, but you could slow it down or do something if you need to. You can. It just won't the effect of people seeing it, they won't see it.

22:50 That's really cool.

22:52 Yeah, it is cross platform, but I was going back to it. There are some cases where we will turn V Sync off to just test how fast certain things are happening.

23:01 What's the performance upper limit of this? Regardless of the screen.

23:05 A lot of people love to send us messages with that. While we're trying to do something like update a texture or something as fast as they can and trying to get 300, 400 frames a second, it's pretty neat to see that.

23:17 What else should I highlight in here? There's a bunch of graphs. I think people really just need to go see them. But there's nice heat map looking things. There's some statistical stuff. Anything else you want to shout out on the.

23:29 Yeah, there's some candlesticks.

23:30 We've seen some great action with some API's through some actual cryptocurrency interfaces.

23:35 People have done.

23:35 They made crypto wallets.

23:37 Which is pretty cool. We've seen some of that. So we've seen probably maybe ten of those, but a lot of people seem interested in that.

23:42 Interesting.

23:43 Yeah.

23:44 So people are using Dear PyGui to build something like a Dashboard trader application.

23:51 A lot of dashboards. Yeah.

23:53 Okay. We can pull in a comment from the audience. Mr. Hypermagnetic, good to see you again. Always make sure why not use HTML for desktop GUI's and then also adds that these are definitely nice looking graphs and user interface, which is cool. Maybe I'll let you take a shot at answering that question for you.

24:09 If you got that.

24:10 If not, I could throw something out there as well.

24:13 We got a ton of Electron apps that fit that realm.

24:16 That's what I was going to bring up with electronic.

24:18 VS Code and other things. Slack. And whatnot I think there's a couple of areas that you would care about. One is you probably are not going to be getting 300 frames a second refresh rate with HTML. There's a lot of layers in there if you want to take advantage of the GPUs in deep ways. If you want to push a mesh of objects in there and then have them rerendered, that's not really what HTML is for. The native integration also gets tricky. I don't know about Dear PyGui you want to integrate with the menu bar and other stuff, right?

24:52 We need the hardware access. Now, you can use WebGL, but basically be using HTML just to create that GL canvas. And then after that it's the same thing as what we're doing now. So you could do that. I think we have some sample projects where we use that. You can get 60 frames a second higher, but again, you're just using HTML just to get to the canvas. And then after that, the HTML is going to use it for anything.

25:16 Let me see here. If I can get a quick read on, say, like VS Code here. Hold on. A little activity monitor doesn't update very quickly

25:25 By having to run through the browser, your text app becomes considerably deeper when we're trying to be as light as possible.

25:34 Yes. If you want to do a lot of the stuff that we're seeing on the screen here, you're almost done to rendering directly on canvas. And then at that point, there's not a huge value for the HTML side of things because you're just drawing pixels anyway. So to wrap that up, Hyper Magnetic says, I've seen performance issues with Electron versus more native apps. Antonio out there. Hey, Antonio, good to see you. Loves these plotting features. He's also in the oil and gas industry. So very cool.

26:01 Great.

26:02 And following up on that, John says there's also a limitation to threading and concurrency, which you definitely have more control. Right. Very quickly. So, for example, I just launched VS Code and it's doing nothing. And there's 1,2,3,4,5,6,7,8,9,10 processes running VS Code, which quick math across those looks like something like 350 Megs of Ram. I don't know what Dear PyGui would take, but I suspect it would be far lower than that.

26:30 It should be much lower.

26:31 Multi processing and so on.

26:34 Although Python itself is not known for it's like massive, taking advantage of multicore stuff because of the Hill. Still, you got a little more flexibility.

26:43 Cool.

26:44 It's always interesting to think about. Now let's see. Let's scroll down and look through a few more of these pictures here. So you've got this Node editor and this note sounds like a core thing in this UI framework.

26:56 That's another one of those libraries that somebody had built on top of GUI. It's usually just a single file and a pretty light. A lot of people made some really cool stuff with that because you could put any widget that's in the UI library in these nodes.

27:12 Let me take a shot at trying to describe what this looks like for people listening. You can check out under Node editor on the GitHub page. It almost looks like a database diagram where you've got relationships between these nodes. But instead of just having table info, you've got graphs, you've got XY values, you've got other little bits of computation and stuff that are visually in the nodes that are also connected together. That looks pretty cool.

27:36 Sounds like a data flow thing, which is an actual picture you're looking at is a tool we built here at work to prototype some of the systems that we're working on here. We took a little piece of that as a snapshot, but yeah, it's a pretty cool feature. A lot of people do a lot of cool things with it.

27:51 So I could build a little section that will take in some, let's say, fluid flow rate and then apply some algorithm and visualize that, but then also as an output value that can be passed on to some other part of a simulation that's also showing up there and stuff.

28:08 Is that my understanding that's it and you can redirect the inputs from one to the output of the other or whatever widget that are being connected. Really interesting, whether it be a slider and input or radiobox any of those.

28:24 And it's a pretty low level. Some of this stuff can be a little bit misleading when you looked at it, and it looks like it should just come right out of the box. And most of these are not. For instance, this node editor that you're looking at in general. You create these nodes, and when a user tries to grab one of the pins and link it to another one, a callback is ran and it's up to the actual user to decide whether to make that link, where it's given information about where it came from, where it's trying to connect. So it's really up to the user to make something with it. It's pretty low level. And you'll notice that with a lot of these plots, they're low level, and it's meant for the user to wrap on top of and build more complex functionality because we want it to be as generic as possible.

29:04 There's an example of Tetris, like, who doesn't love Tetris? Of course. What is this last one here? Several tools to help the developers. There's a lot of built in tools like tab views and list views and stuff like that. Or what are we talking about?

29:20 As an example, whenever you go to create the UI, you may create a window and then add a group and then a collapsing header and then a button, and you have this parent relationship. One of the tools is the Item registry, and if you just type in the command show Item registry, you get this basically tree view where you can look through all the items in your UI, click on it, see information about the state of it, is it visible, is it clicked on? Is it hovered? That's one of them.

29:46 Most of these use for debugging.

29:49 Yeah, it's tricky to get a view into that kind of stuff in the UI. Right. Obviously, you can print out something or set a Breakpoint and see it, but a lot of times the hierarchical and whatnot and the right visualization of that makes a big difference.

30:02 Another great one is to say if you're loading a texture or a couple of textures into the Texture Registry, preparing them to be added to a widget, you can use the Texture Registry viewer to actually go in and inspect your different resources. Like you can preview it before you actually use it.

30:18 Oh, that's really cool. Yeah.

30:20 With fonts, you can inspect fonts and other things with that.

30:23 Is Dear PyGui primarily focused on 2D UIs, or does it have a 3D component?

30:30 Currently it's 2D, but we are working on a 3D engine to go with it. The UI won't be 3D, but there will be 3D Widgets, and we have support for that now, but it's not hardware accelerated. The actual 3D engine working on will be.

30:43 Yeah, cool. So for example, all these charts that are on the GitHub page that are active and moving, I can totally imagine that one of his spherical or it's modeling spikes that represent peaks of some kind of measurement all over the place, and you want to look at it from different directions and whatnot.

31:00 Yeah, I think at the bottom of the reading, you can see some examples of users that have already skipped ahead and hacked in to some 3D work.

31:10 There's a Gallery section that people should check out. One of the things I really like to do when I hear about a new UI framework or some tool that does UI graphical stuff is to just go look at the screenshots and go, what? I want my app to look like this. Maybe that looks pretty cool. Let me take the time to learn it. Honestly, it blows my mind. There's a lot of UI frameworks out there that don't have a single screenshot of what's your whole job is to build pictures, show us some pictures.

31:38 Really important Gallery part of it.

31:40 Yeah, the Gallery is looking really good. So one, it looks like almost the first one is almost like an AutoCAD thing. Looks like some kind of turban or something. Is there maybe you know more about it?

31:50 You guys can one of the users made it. Wasn't sure what they were working on. We helped them a little bit with getting access to the underlying OpenGL context because I was on Linux, but not sure what they're working on past that.

32:02 This next one looks like some kind of modeling system.

32:05 Either one of those saw user with it. We snapped the photo and no idea what they were doing with it. Just looked cool.

32:12 Definitely looks cool. Bunch of left hand side, right hand side elements here. Almost looks like it could be modeling, some sort of machine learning thing, but I don't think so. Yeah, definitely some kind of interesting model here. Might have been some really nice visualizers here for it. Looks like maybe looking at some astronomy stuff, which is great. And then a game and some more drawing tools.

32:36 Yes.

32:36 Here is this maybe a Ray tracing?

32:39 No, that was just a Fong render that we were working on when testing some of the earlier versions of the 3D engine we're working on.

32:48 Okay, so that's just some of the early prototypes, and we thought it was a pretty neat picture to do. And you can do that now if you just kind of like that other user did, just hack in and get access to the OpenGeo contacts or Direct Tags.

33:00 Okay, so one of the things it sounds like you can do is work with Dear PyGui. But when maybe there's some low level thing you need to do, like a shader context or some weird graphical thing. If it's not directly supported, you can just go, all right, let me just get straight to the GL context object structure and just do some OpenGL stuff on. Is that right?

33:24 That's correct.

33:25 And for now, that's the way it's done. But one of the things that we've been working on and a lot of the users have been around a while, notice is like I said, right now, the back ends are for Windows reason, DirectX Eleven, for Linux using OpenGL, and for Mac we're using Metal. That was early on. That's probably a bad decision. So now we've been working on replacing the back end with Vulkan across board. Then part of that would be that we'd be able to directly support giving users access to the GPU there. Because one of the things with the library is we do want it to be cross platform and not have to change the code, pretty much not have to change the code at all across the platform. Right now, with us using different back ends, we wanted to expose access to compute shares. When you're on Windows, you'd have to write it in HLSL. When you're in Mac, you'd have to write it in whatever their language is, metal and then an open GLSL. So by switching to the Vulcan back end, we're going to be able to expose that and use the same thing across the board. And that's part of one of the big things that we've been working on and takes a lot of time. And the 3D engine itself is also going to be written in Vulkan pictures of that, too. By the way, on the.

34:34 Okay, where do I find that?

34:35 Go to the very top. Might have to actually click on my name, but it's DearPy 3D.

34:40 Oh, got it. Okay, so it's a separate repo up there.

34:43 It will be combined just while we're prototyping it.

34:46 Sure. Right here. And by the way, nice GitHub profile.

34:51 Your nice README looks good.

34:52 Yeah.

34:53 Here you go. So the Dear PyGui 3D engineer. Pretty neat. Look at that.

34:58 Yeah.

34:58 You do have some cool pictures in here.

35:00 That will be stuff. Yeah, that's true 30.

35:04 real time. So, let's go back just for a minute on this cross platform business, because I think this is worth thinking about. First of all, I was really impressed that you had support for DirectX and Metal and OpenGL, because that means on Windows you get the best option there, which is DirectX on macOS, especially in the new Apple Silicon ones. If you want to take advantage of the GPUs that are built in there, the best way to do that is Metal and so on. But yeah, those APIs are super different. So if you're going to expose them, say here, let me just hand you the low level context and talk straight to it while setting them up for getting locked into one or the other. Plus also having to learn Metal and or learn DirectX and all that. Right.

35:50 Again, that's part of the reason we are switching to Vulkan. We will leave those back ends as legacy. Legacy is a bad word, but you'll be able to switch to those back ends. But if you're really wanting to do the low level stuff and wanting to access the 3D engine, but you will have to use Vulkan. Yeah.

36:04 So tell people about what this Vulcan thing is. I've heard of it as a way to have one API that talks both DirectX and Metal and OpenGL or something like that.

36:13 Is that sort of deal OpenGL DirectX 11, and I guess that's the two main ones.

36:21 I guess the previous generation graphics APIs and those are used to they go through the driver and they talk to your GPU directly. Like I said earlier on in this, that basically the hardware has changed considerably since those APIs were designed very different. So it's a lot more work on the driver developers to have to go from here's how the hardware works to here's the API we had. So the move over the last five or six years has been towards these lower level graphics APIs like Metal, DirectX Twelve, and Vulkan. And these are considerably lower level. Just as an example, to get a triangle on the screen and DirectX Eleven, it's maybe 300 lines of code and OpenGL it's maybe 100 if that to do it in Vulkan. You're easily at 1000 just getting a triangle on screen.

37:11 Really. I was already feeling bad that it was 300 in DirectX and I can just remember the Open GL code set, the scale, set, the transform, set, the viewport, all of those things. It's not easy programming type of work. So Vulkan is even lower than that, right?

37:28 Vulcan and DirectX Twelve are really the lowest level, but DirectX Twelve is just Windows.

37:34 With these APIs, you're able to utilize so much more in terms of what your GPU is capable of, but you have to manage a lot more. And that's part of why that even 3D engine and that's switching the back end is taking as long as it is because the driver developers do a lot less for those APIs.

37:52 As an example, in DirectX and OpenGL, you can say I need a texture and loaded with data and that's it. You get as many times as you want. And Vulkan and DirectX, well, there's a Max number of times you can do that. I think the loan number is maybe 4000 allocations. So it's up to you to instead allocate one big block, manage it yourself and not keep doing that as an example, right?

38:16 You end up with those sort of maps right where this square is the actual whole picture or something else. But to the right of it might be some other thing that you load all into one texture and you viewport into it or something.

38:32 That could be fun, but also you pull your hair out.

38:36 Another one of the things that the new APIs have changed is actually having to synchronize between the GPU and CPU and DirectX and OpenGL. When you swap the buffers, execute this draw whatever you're doing, your main loop where you're doing that, you don't have to wait till it's finished.

38:52 It's automatically synchronized between the GPU and CPU. I see with the new APIs, that's not the case. Typically you have to actually add in barriers and fences between the different operations than just a lot of stuff. You typically have more than one frame processing at a time.

39:07 You can actually utilize multiprocessing, which is a problem right now with Python because of the GIL. So even though Vulkan has that you can't really utilize it yet.

39:16 Maybe the no GIL stuff will gain traction in it. It won't be a problem anymore. One can help. So when I'm looking at the Vulkan page here, I see Windows, Switch, Stadia, Linux, Android. I don't see macOS. Is it still support Mac or what's the story there?

39:31 Yeah, the Molten VK is a layer on top of Metal so that you can use it for Mac.

39:39 It's not directly supported. You know how Apple is. You use Objective C, they don't want you using C++ as not supported. The same thing they deprecated OpenGL and as of right now there is no direct support for Vulcan.

39:52 So Molten VK is the it's like an intermediate layer between Metal and Vulkan.

39:56 Right. Talk about possibly leaving Metal and it's a possibility to leaving.

40:04 It breaks your perfect abstraction though.

40:06 Yes.

40:08 What are you going to do though? Pretty cool.

40:09 Metal is already doing that right now. Some of the formats for the textures aren't supported.

40:14 Good point. It's a little annoying.

40:16 Yeah. Everyone's a Snowflake over in the Mac world. That is correct, as I say on my Mac. Okay, let's see. One of the things I liked when I was looking through here is you've got a nice getting started tutorial. Maybe we could talk just a little bit about what the code looks like to get some stuff on the screen. But you also have some video tutorials. Jonathan, I know you put some of these together a while back.

40:38 They're a little outdated. They're six, which is pretty old, but we need to recreate them soon.

40:45 As somebody who creates a bunch of videos, they're very tricky to keep them in sync. You can't just edit a few words or change a thing here. Right? It's different, but yeah. So people want to learn through the video style. They can go through and watch some of these and get a sense of simple plotting or working with tabs and stuff like that, right?

41:07 Most of the things are there. Documentation still is a bit, both with video tutorials and our readme. It's still a little bit lack, and there's still some stuff that's undocumented that we're having to add. But as part of the point of the demo is you could see how all those most of the features are there and you can see how to code them. But that's no excuse for us, not for the docs.

41:29 This portion of Talk Python to Me is brought to you by Toptal.

41:33 Are you looking to hire a developer to work on your latest project? Do you need some help with rounding out that app? You just can't seem to get finished. Maybe you're even looking to do a little consulting work of your own. You should give Toptal a try. You may know that we have mobile apps for our courses over at Talk Python on iOS and Android actually used Toptal to hire a solid developer at a fair rate to help create those mobile apps. It was a great experience, and I can totally recommend working with them. I met with a specialist who helped figure out my goals and technical skills that were required for the project. Then they did all the work to find just the right person. I had short interviews with two folks. I hired the second one and we released our apps just two months later. If you'd like to do something similar, please visit talk.

42:20 Python.fm

42:21 /toptal and click that Hire Top Talent button. It really helps support the show.

42:29 That's true. But also contributing to the docs and contributing a tutorial or something like that. That's also a good way for people to contribute.

42:37 That's very good.

42:38 Where are you all open to having contributors and PRS and other things along those lines? Absolutely.

42:44 Yeah. Add a bunch of PRs and welcome to join the discord.

42:48 We're in there all the time talk with people about when they're working on different spots in the API.

42:52 The problem is mostly users are Python users and libraries written in C and Objective C and things like that. A little bit of a disconnect there where a lot of users would like to help and when they go over to the library and see if that they go, you know what?

43:06 Actually, I wanted to work on a Python project. We have this problem in a lot of the very popular places, like people want to contribute to Python itself, and often that means C, not Python.

43:17 It people want to contribute to Jupyter's, but a lot of times that means JavaScript, not Python. Come on. But yeah, that's kind of what it means to build tools. Sometimes you guys have the demo firing up on your screen here. Maybe you want to just talk us through a couple of the highlights and how we get this thing going.

43:36 Sure.

43:37 Got to keep in mind that not everyone can see what we're seeing.

43:41 The demo and we modeled this after Gui's demo and some of the other demos. We saw people doing similar things where you can see all the different features.

43:49 So if I pip install Dear PyGui, is there just a command I run to just get that going?

43:54 It's one end of the modules. You have import Dear PyGui, and then you have import Dear PyGui demo. And there's just one command show demo.

44:02 You could even do that from a REPL if you wanted, right?

44:05 Yeah, you can do that. You can kind of see a lot of different widgets, just your typical UI widgets that you have. Yeah.

44:11 Go back to the widgets real quick for a second.

44:14 Yeah.

44:14 So you've got a lot of nice ones. You've got buttons, you've got check boxes, you've got radio buttons. Like you can only select one versus check boxes. You've got drop down combo boxes, text text with placeholder hint. I guess one of the areas that you have a lot of UIs around is the slider. What do you call it? Slider INTs. It's like a thing that has a number, but then as you slot, you can not just type in it, but you can drag it around and actually scale it. I see this a lot in the Adobe Tools addition.

44:48 If you want to change something, you can click on a number and just move the mouse instead of typing to the number.

44:55 A lot of these other things because again, this is really meant for a lot of 3D engines and content creation on a color Maps.

45:02 Okay.

45:03 Like that. Let's see what else. Text input a lot of stuff here. And remember I told you a lot of the back ends of the same exact numbers so you can get things automatically like this. All these are linked together. All right.

45:13 So what you're doing is there's like three text boxes, one that's plain text and two that are passwords. And as you type in one, it's not really practical for passwords, but as you type in one, it will show you in the different.

45:26 So we're showing different flags. Just different flags.

45:29 Yeah. How do you create that binding between them?

45:31 As I'll send you, there is no actual binding. They're truly the same value underneath. Whenever you go to create this, say you call this item password one. When you go to create the second one, you can specify a source as password one, and it will just rather than have its own value, it will just truly use a pointer to the other one. And that's all.

45:50 Yeah. That's really cool. So that's how they stay in sync.

45:53 They are in the same data. It's free.

45:55 It doesn't cost anything. There's no callback that us to run a lot of basic, simple plots.

46:01 Pretty simple stuff. Let's see, again, these are linked in the same way.

46:07 I encourage people if they want to think about this framework is create a virtual environment, pip install Dear PyGui and then do the import command to run the demo.

46:17 Yeah, really date pickers. But some of the cooler ones that you want to see on there show these. These are all pretty typical on most UI libraries.

46:26 Some of the ones that's true. Some of the ones I guess we have a table API, which.

46:33 Oh, that's nice. Looking.

46:34 Pretty cool.

46:36 These examples are just showing text, but you could put any widget, you could put plots, you can do all kinds of stuff. Yeah.

46:42 With the table one, probably people think about it probably be called a grid and a lot of frameworks. It's kind of a read only Excel type of view, but very colorful and read only.

46:54 There can be any widget you want.

46:58 Oh, so you can put like a graph in one of the you could put a note editor.

47:03 Anything you want in these. It's best to think about a table is more or less a layout.

47:07 Essentially just giving you columns and rows where you can put anything in it.

47:10 Oh, yeah. Okay. That makes sense.

47:12 Yeah. And you see here this sorting one in Tennessee. You got a checkbox in here. There's an input, different things, tables cool. There's tons of blocks.

47:24 And we have that example they saw. Yeah.

47:27 You even have that high level than the detail graph in there. That's cool. Do you have trees?

47:33 We do textures and the high performance type stuff, those that haven't seen node editor. So those that are unfamiliar with that room here.

47:48 That node editor is exactly what I expected. So you got these three little boxes with different bits of information or graphs and you just drag and connect them and.

47:56 Yeah, that's fantastic. You can put any widget in the library in these. So it's not limited to just small subset. And then again with the drawing API, your typical stuff that you used to and other drawing APIs, being able to draw line, box, cube, things like that. And then also some support for a lot of 3D operations, things like perspective, divide and depth clipping and all that. To help support these type things.

48:20 Let's maybe round out our conversation here by talking a bit about just give us a sense on what it looks like to write some code. So I'm guessing there's not a graphical designer type of thing like Xcode storyboard or whatever.

48:38 Yeah.

48:38 You do this through code. You build up your UI through code and layout element. Just give us a sense of how do I get like a text box and a button or something on the screen? What is the code story look like? We talked about the 100 lines of OpenGL or whatever.

48:54 So pretty much every DPG app you just import DPG, we do it as DPG most of the time. From there you'll create a context which basically sets up the GUI context. Sets up. No, it sets up our internal context with all the different settings and state.

49:09 Oftentimes these lower level frameworks, they have to go and get some context from the graphics card itself and get that from the operating system. And I'm sure that kind of wraps that stuff all up.

49:20 Absolutely. Then from there you typically create the viewport. And again, that's platform specific. On Win32, we're using win32, we're using X Eleven, on Linux and on MAC, we're using Carrier or whatever it is. I'm going to touch that one in about a year.

49:35 How did it stay away from it?

49:37 Got it working and walked away from it for a while.

49:40 The viewport is basically like an empty window, right.

49:43 It's your actual operating system window.

49:45 Got it.

49:46 We call it a viewport. And from there you can create something like a window. There's these root objects, a window. It's like the on viewing window that you see below, the blue window that you would see on our demo, things like that. They're floating windows within the main viewport from there to just add something like a text widget, it's DPG add text, DPG add button, DPG ad input text, whatever the widget is. And you can't the hierarchy of parent child relationship with context managers kind of the way that if I'm going to create one of the windows.

50:18 One of multiple possible windows, instead of creating a window object and say window, add this or that, you would create a context manager and do a bunch of ads, because then it all just goes to that window.

50:29 Right. And we're not object oriented, which kind of also sets us apart here. If you weren't using the context manager, that same operation would be DPG add window and it returns either an ID or you can put the ID in with the keyword tag equals whatever your ID is. Then you would push to the container stack. And then when you're done adding items, you pop it back off. The context managers handles that for you, right. So it's adding, pushing it and popping it. And if you wanted to do something like I said, it's not object oriented. When you do add button, you don't get a button back. You get a handle to internal button and then you use that handle and you can store it, just say B equals DPG add button. And then all the various commands, you would use that handle to control. If you want to say get the check state of a checkbox control or configure everything you did when you created it, when you started off, you can modify later on using configure item, and then you just pass in handle and go from there.

51:29 Cool. Is there an event loop type of thing?

51:32 There is. So after you've created the viewport and you add your widgets you would do set up Dear PyGui and what that runs is that starts up the second thread. We have two threads, we have the rendering thread running, and then we have a callback thread where all the Pythons happening. So that's what setup Dear PyGui does. Show viewport actually shows the viewport and starts basically the platform specific event loop from there. Start Dear PyGui. That is your event loop. If you actually want to see the event loop, you would just do while is Dear PyGui running render dear Pag GUI frame, right. And you could do everything you want inside of there. And then when you're completely done, you destroy the context.

52:09 Looks super straightforward. One thing that I don't see here is the callbacks. So like when the slider slides or the button clicks, is there some way to hook that action? Obviously.

52:23 Yes. It's a callback. It's a keyword for callback. And basically it can have three arguments, the sender, which will send you the ID of the item that called the callback. The second one is app date, which for us that can be either the value or if the callbacks related to window resizing, it will be the new size.

52:42 It's data that DPG sends you. And then the third argument, user data is user can pretty much put anything they want, then it'll get passed through and it's useful for a lot of people that are creating OFB wrappings around the library.

52:55 Yeah. Nice.

52:57 Is there one callback that handles all the events and then you do like a switch statement.

53:01 It's really up to the user. You can have a different call back for everyone. Or you can have one master callback where you just check the sender and do different operations based on what code to call back. You have a little bit of freedom there. We do have callbacks.

53:14 You can attach to inputs such as the mouse or the keyboard or the window Resize.

53:20 Like you mentioned, we have callbacks.

53:22 It is nice to be able to say when this button gets clicked, do this and that makes it real simple. But there's also times that you might want to I want to capture all the button clicks and then do some common thing regardless of which button gets clicked. It's nice to have that flexibility to go either way.

53:37 That's the biggest thing. We try to be as flexible as possible and allow really geared towards a lot of people wanting to wrap and create their own kind of interfaces. There's a lot of freedom.

53:47 So I noticed that you have this, you call it the viewport. It's like window that comes out of the operating system and then the Jeep. I go windows live in that space. Is there a way to simulate it looking almost like the Dear PyGui windows? The whole thing. Could I not show the title bar of the one window and then maximize the inner window to fill it?

54:09 You can undecorate the viewport. There are settings for that. And then we have a command that's set primary window and you could basically set one of the one of your I'm doing windows to the primary one. It'll sell the whole viewport and you get that. But you can't necessarily move them when you do that. You can't have multiple viewports at the moment. We're still working on that.

54:27 Is there like modal dialogues and that kind of stuff in there?

54:31 There is modal dialogs. There is file dialogs. A lot of people still tend to just import to enter and use their file dialogue because a lot of people don't like ours. Right click contact menus.

54:42 Yeah, it looks great. Like I said, people who are possibly interested should check out the Gallery on the GitHub page. That's a good litmus test of what does it look like you want to use that? I think it looks pretty good. I like it.

54:52 Sure.

54:53 We're getting close to the end here. One thing we talked a lot about the future stuff already. Maybe we don't really need to go into that. We've got the Vulkan back end, the 3D engine and stuff like that. One of the things that I always want to do with a Gui is put it into my taskbar or put it into my macOS dock and I want to be able to give a binary thing to a user and not tell them about virtual environments and pip install and all that. What's the deployment story about giving somebody a distributable version of this app?

55:21 So a lot of users have used some of the tools py was that we did early on when we first started the project, had a batch file and some bash files that packaged it up for you, actually created the executable and everything so we could hand them around here, embedded the Python interpreter and everything. We did remove those, but we do eventually plan on adding back. So we really don't like having dependencies on other libraries. So even though you are using that now, we would like to bring back that. It wouldn't be that hard. We already do that when we develop it. We are using an embedded version of Python and an executable.

55:58 We're not actually using this. What is it? This utils and we're not using any of that. We're actually just using the Python CAPI directly and embedding it.

56:08 Yeah, just as a Sidebar. One of the things I really think would benefit Python as a community is if there was just a built in Python-M package.

56:19 Absolutely. Build executable or whatever. And out the other side comes a binary Linux app or Exe and you just hand it out right. There's so many scenarios where people would like a tool that they would like to be able to share. I feel like it's a bit of a chicken and egg thing. People aren't doing that very frequently. So why do we need that feature? Well, they're not doing it because it's so super hard and fragile. Right. If it were as easy as pushing a button, I think maybe people would do it more. So, I don't know. Anyway. Absolutely.

56:47 That was one of the original reasons for our engineers sandbox project. Way early on. We did do the tools in Python, but we couldn't hand them to people. We had to tell them we got to install Python and then pip install this. The idea of that one was we were able to just handle that a little bit.

57:01 Wrap up on the audience side, Mr. Hypermagnetic once again says very nice design and similar to small JS libraries. Yeah, nice.

57:08 Looks good. Last thing I always am interested how these projects gain traction, how people find time and energy to put into them. And one of the ways is for companies that use them or people that use them to sponsor you guys. Do you guys have a sponsor option here, which is part of the GitHub sponsor story, right.

57:30 I think that's actually a pretty big deal because it used to just be like we could put a PayPal donate button or something on there, which is fine and all.

57:37 But this is an awesome feature that I guess Microsoft added, assuming that they want to do it. It's pretty good. We do have the micro GitHub sponsors open, collected and buying a coffee. Yeah.

57:49 So this is a part time project for you guys, not full time. It sounds like you're doing mechanical engineering work full time. And then also this, both at work, but then also bringing it out to the community a little bit.

58:01 That is correct. Directly applies to something we're doing at work above or something. We'll add it here, but for the most part it is at home, at night, after our families are in bed and working on it.

58:11 There a labor of love. Awesome.

58:14 It's great to see more UI frameworks and more UI innovation in the Python space. So thanks for doing that. Now, before we get out of here, let me ask you all the final two questions. You're going to write some Python code. What editor do you use?

58:28 Typically? PyCharm

58:30 Yeah, pretty much PyCharm and then notable PyPI package, something you've run across. Like all those awesome people should know about.

58:37 Typically just NumPy is about the only one. NumPy is not the only one to use. We like to reinvent the wheel.

58:43 Fewer dependencies. Right on. Anthony. The audience says, I'm guessing question Mark, does your Python GUI play nicely with third party lives like Nuke, Py installer and so on?

58:54 Pyinstaller? I know it does. Nuke. Do not believe it does. And then NumPy or anything that supports the buffer protocol you can use and a lot of our functions.

59:04 Very nice work. Final call to action. People want to get started with Dear PyGui or maybe get back to it? Sorry, Anthony, it was a statement.

59:13 Not a question. Thanks, Anthony. Okay, yeah. Final call to action. People want to get started? Dear PyGui, what do they do?

59:20 Just pip install and run the demo on the Read Mayhem. You can also join our Discord server. There's about 1000 read the docs for sure. Read the docs. Contributing would be nice. We're still in the middle of refactoring a lot of things internally, so maybe a little hard. But other than that, also just sponsoring really helps out. Makes it worth it.

59:38 Jonathan, Preston, thanks for being here.

59:41 Appreciate it.

59:42 You bet.

59:43 This has been another episode of Talk Python to me. Thank you to our sponsors. Be sure to check out what they're offering. It really helps support the show.

59:52 Take some stress out of your life. Get notified immediately about errors and performance issues in your web or mobile applications with Sentry. Just visit talk.

01:00:01 Python.

01:00:01 Fm/sentry' and get started for free. And be sure to use the promo code 'Talk Python' all one word. With Toptal you get quality talent without the whole hiring process. Start 80% closer to success by working with Top tal. Just visit talk.

01:00:17 Python.

01:00:18 Fm/Toptal to get started. Want you level up your Python we have one of the largest catalogs of Python video courses over at Talk Python. Our content ranges from true beginners to deeply advanced topics like memory and async. And best of all, there's not a subscription in site. Check it out for yourself at training talk Python.fm be sure to subscribe to the show, open your favorite podcast app and search for Python. We should be right at the top. You can also find the itunesfeed at /itunes, the GooglePlay Feed at /play and the Direct rssfeed at /rss on talkpython.fm.

01:00:54 We're live streaming most of our recordings these days. If you want to be part of the show and have your comments featured on the air, be sure to subscribe to our YouTube channel at 'talkpython.fm/Youtube'. This is your host, Michael Kennedy. Thanks so much for listening, I really appreciate it. Now get out there and write some Python code.