Python Bytes - #17 Google's Python is on fire and Simon says you have CPU load Pythonically

Episode Date: March 18, 2017

See the full show notes for this episode on the website at pythonbytes.fm/17

Hey everyone, Michael here. Just a quick show note before we get started on this episode. I think we have a great set of topics to cover, but unfortunately, something went crazy with my computer and just pinned all the cores and basically made the recording of my high quality version fall apart. And so when you listen to this, there'll be a little bit of static on my end and I just want to say sorry about that. We had some backup audio, but it also got messed up. So basically, I've tried to make it as good as possible, but there's a little bit of issue with the audio. If you can handle it, there's some great news. And if you want to skip this one and just wait for next week, totally understand as well.

All right. Without further ado, let's get to the news. Thanks. This is Python Bytes, Python let's get to the news. Thanks. This is Python Bytes, Python news delivered directly to your earbuds. It's Monday, March 13th, 2017. And this is your host, Michael Kennedy, here with my co-host, Brian Ocken. Hey, Brian, you ready to share the Python news with the world? I am very ready. Excited. Would you say that you're on fire? I am on fire. Yeah. Awesome. Yeah. Google's on fire too, right? Well, yeah. So I'm, I'm actually a little confused about where this is coming from, but there's a, yeah, our first topic is, was suggested by several listeners. We got it through email and through Twitter

to cover a tool called Python fire from, I, I don't know where it's from it's it's on the google repo um on github uh but it at the bottom it says it's not a google product so i don't know what that means i think it means it might have been created by somebody at google but it's not supported in any way it's just hey this is a cool thing we made so i should have it yeah i downloaded it gave it a shot it says um so we haven't even said what it is. It's a command line interface utility. And their tag at the top of the repo says, Python Fire is a library for automatically generating command line interfaces

from absolutely any Python object. It is pretty cool. Another thing, it says a list of the benefits. It's a simple way to create a command line interface in Python and you can use it for exploring and debugging existing Python code and it makes transitioning between bash and Python easier I actually so I tried it out downloaded it wrote a couple little tools and I actually was pretty fun but I don't think I would use it for a shippable a shippable

python like command line interface because it's pretty big yeah and by big you mean it has some heavyweight dependencies right yeah like it includes all of ipython that's quite a bit coming with it I mean it also includes six but that's really not that big of a deal yeah six is just like a basically one little module or whatever but yeah ipython that's that can be one of those things that's really hard to to even install for some people right like you give that to somebody on a windows machine they don't have like a compiler set up like that can be quite challenging i'll have to see i'm gonna import i'm gonna install it on a Windows machine this week to try that out. Yeah, cool.

But it does look really great. You basically have a class, and you just, for your main, you just call fire, and you pass it the class. And boom, that thing is CLI callable, right? Yeah, but you don't have to use a class. You can also use just, you can have a set of functions you can put together and add those as the interface. And there can be multiple entry points as well. Like I tried throwing in like two or three functions and then listing those as all things that you can call from the command line.

And it actually picks up doc strings pretty well to show you, so you kind of have help built in as well. I'm going to use it for like we've got test instruments it picks up doc strings pretty well to show you. So you kind of have help built in as well. I'm going to, I'm going to use it for like, we've got test instruments we try to communicate with and writing, writing to and from the instrument from Python is really easy from the bash. Not so easy. But I'm going to think,

I think I'm going to use this to try to do that at work. Okay. Yeah. It sounds cool. You have to give us a report on your experience. Cool, so the next thing I want to talk about is Simon. Like, not Simon Says, but a cool menu bar application for macOS.

So if you don't care about macOS, maybe you don't care too much about this, but one of my pet peeves is I think we need more full-on native cross-platform GUI things. We've had PyCute and PySide and the Qt Framework. That's one option that we've had that's pretty good. But there's a lot of versioning, licensing, funkiness going on until maybe until the end of this year, actually, until they come out with PySide 2.

Maybe that becomes a really really great option but we have things like PyOBJC similar stuff for Windows similar stuff for Linux where you can basically somebody already has wrapped the truly native OS elements so with this thing called PyOBJC, you can basically create using Python what is indistinguishable from a native app. Like the controls literally are the same as if you had done it with Xcode and Objective-C or Swift. That's pretty cool, right? Yeah. I hadn't heard of this. This is neat. Yeah. So the Simon thing is not like a framework. It's just an app, right? So some guy is like, hey, I really want to have a little thing I can click on and it'll tell me my network usage,

my CPU usage, battery or whatever, something like this, right? And he did it as one of those little menu bar things, like what runs in the top right by the clock on macOS. And you click it and it drops down info about your system. If you look at the code, it's like it depends on PyOBJC, but beyond that,

it's like 150 lines for a full implementation of that app. That's pretty cool. And so if you're thinking about you need just a little simple something to run, like as a menu bar app or the notification tray on Windows or something like this, you know, this is a really cool option. And I mostly wanted to pull it out as like, hey, here's an example. You could probably clone and tweak or just take the ideas of this and go. So you just, you create an app, you derive from NS application, which comes from PyOBJC. You implement a few methods and boom,

you've got a nice native GUI app. Okay. I'm going to have to try this one out too. It's neat, right? The final mix would be to use something like Py2 app or something where you bundle it in a distributable way. So it's not like, well, make sure you, you know, pip install this thing before you can run it, right? Like that's probably not going to fly so well for like end users, but still pretty excellent. So is this PyOBJC? What is that other one? PyOBJC as Objective-C. Like the Python wrappers for Objective-C.

Okay. So that's just a Mac only thing, right? Yes, exactly. Okay. But we can do similar stuff in the other Mac-only thing, right? Yes, exactly. Okay. But we can do similar stuff in the other frameworks, I believe, right? Like on the Windows side, you can use WPF, which is kind of way more heavyweight, but you can build the Python stuff using IronPython,

and I'm sure there's something with GDK and Linux as well. Neat. Yep, neat. It's kind of lunchtime. I'm getting hungry. I wish I had some free food. Really, I'm hungry. Well, I had some free food. I'm really hungry. Well, I was just amused.

I don't know if these are useful or not, but I was amused by, in reading Reddit this last week, there were a couple things that popped up. And one of them was finding, this was actually useful, finding free food with Python. And it's actually an article talking about using web scraping to,ilio to occasionally check on this and then text him information about the free specials. And I probably won't do this, but I think it's a nice example of combining Twilio with

web scraping. It's cool. Do you know what I like about it? It's taking these techie digital API type things and it's making real stuff happen. You're integrating Twilio and screen scraping and then you have free food. How cool is that, right?

Yeah, definitely real world, probably have free food. I think it'd be cool to run. I was thinking about doing a similar thing like monitoring. So we have build machines and stuff, and I wouldn't mind having something that sat around and monitored that and then texted me the results because I don't know how to do that. Yeah, that's cool. Definitely some cool Twilio integration there.

And then the next article just amused the heck out of me. It's called Notification When Friends Order Pizza. So I don't know if this is a great thing or not for dominoes to do, but there's apparently a way that you can plug in phone numbers and find out whether that phone number is ordered pizza recently. And so somebody wrote a script to put in all of their friends' phone numbers and text them or let them know when one of their friends is ordering pizza. I guess another way to get free food is to mooch off your friends when they order food. Yeah, I'm not sure how I feel about that, actually.

That's a little creepy, man. It actually is creepy. I was thinking that, like, I was, yeah, wondering whether or not I should include that, but it amused me. So, I don't think that really it ought to be that easy to find out whether or not somebody ordered some pizza. Yeah, well, if all your friends start showing up every time you have dominoes yeah that was trying some funky stuff man they also have a bot like you can order pizza just by like chatting with dominoes which is also kind of funky i want yeah but but like you could order food for other people then or something i don't know. It seems like they're playing with scary interfaces,

but at least they're playing with interfaces. Yeah, exactly. Exactly. Like it is pretty cool. Okay. So speaking of food, I want to talk about Pi. HTT Pi, which is a little utility written in Python that is kind of like Wget or Cur curl, except for that it's awesome.

And the reason it's awesome is it runs on the command line. So if I wanted to like call a JSON API, I could say like HTTP space. And I would give it the URL, whatever that is, maybe some additional data. You can even post data from the command line and so on. And it comes back formatted, pretty printed, color-coded, everything. So it's quite glorious. You can create sessions and have those, like,

authentic sessions persist across multiple calls. You can do XML. You can do JSON. You can do HTTP or HTML, all these different things that it knows about, it will color-code and format pretty for you on the command line. That's great. And this is multiple operating systems.

Yes, absolutely. Yeah, so this works everywhere. This is just a Python 3 little library, and that's the Py part, right, the Python. And so I spoke about Postman before as being a really cool way to test apis and just play around with them but this is kind of like the cli version because if you do that with curler or even with python and request and then you spit it out like it shows you it but it's usually not well formatted it's usually minified it's not color coded so this is this is pretty tricky the color coding actually makes it really readable. That's nice.

So if you've been using curl or wget a lot, check out HTTP. HTTP. The link's in the show notes. It's on GitHub. And it's got a cool little interface. I put the link to the homepage in there. Just click on that, and you'll see a screenshot comparison of that versus curl. And it's night and day. It's great. Well, the last thing I've got is, speaking of command lines and hard to pronounce packages, it's pip dep tree.

There's a little utility that you can do it with pip install. I think it's pip dep tree altogether. As in pip dependency tree, but just P-I-P-D-E-P-T-R-E-E, right? Yes. And it is a godsend for me. Like for this podcast, I'm trying out stuff all the time, trying out new packages. And also for right now,

I'm working on the plugin chapter in the PyTest book, and I'm installing a lot of stuff. And I am using virtual environments, but I still don't really want to throw them away all the time. So I want to clean them out. But if you just do a pip list, often I see a whole bunch of stuff that I don't remember installing, and it's because of all the dependencies and this pip dep tree just shows all of the things you've installed and what depends on what uh when i look up and don't know what arrow is or where it came from pip dep tree shows me that oh i installed cookie cutter and cookie cutter installed ginger too and ginger too installed arrow I know. Yeah, that's very cool, right?

Yeah, and it's nice. I like it. It's kind of, I wish that was just, it should just be an option in pip list, I think. Yeah, it really should be part of pip, shouldn't it? But it's not, and so we have piped up tree, and I think that's cool. You can reverse it as well.

You can say, okay, this thing, what depends upon this? And it'll say, well, these three packages through some sort of transitive closure of their dependency graph these are the things that you that that you need this to be here for or you can do it the other way and you can say what is installed this right like or what does this thing depend upon which is pretty cool so you can view it from either direction oh cool i didn. I didn't know that. Yeah, there's a dash R for reverse. So hit it with the dash R. Cool. Okay, so final thing we have for today is a real testament to Python 3,

to modern Python, to asynchrony. You know, we've been hitting this async away, the power of asynchrony a couple of times. So I want to come back with a few comments from what people have talked about, but I also want to feature an article. And this is a really great article by the folks at Signet by AI, which is an AI platform that uses Python. So basically, the title of what we're going to talk about is Not Your Father's Python, Amazing Python Frameworks. They sort of went through what they had been thinking about when they created this company

and said, look, we all know Python and we like Python, but it's super important that we can do crazy amounts of data processing. Their product and infrastructure has to handle hundreds of thousands of events per second. And, you know, they've been hearing the drumbeat that, you know, you can't scale with Python, you need to switch to Go, et cetera, et cetera, et cetera. And they said, all right, well, let's have a look and let's see how this is going to work out. They evaluated Go and what the good and the bad of it was.

They evaluated Python and said, let's look not at traditional Python, like the way, the sort of synchronous style of programming, but there's a number of really powerful async frameworks that we've covered, I think, at least two out of three of them. So there's UV loop, which is pretty awesome. There's Sanic, and there's Gepronto. Okay, so Sanic and Gepronto, these are the web things that we've talked about tons. And they're built on async IO, just like this UV loop is, but UV loop is actually a reimplementationplementation in cython so the

compiled version of python that's more than twice as fast as what's built into python itself interesting right so like maybe maybe we should just like bring that feature into python itself in some way to make asyncio twice as fast so they said let's let's look at this and evaluate and decide if this scalability thing's going to work all All right. And they said, we all know about the GIL. Is this a real problem? So they ran some comparisons and did some work. And it turns out like they've got some graphs of UV loop and other frameworks just like blowing away things like Node.js in terms of performance, keeping up with, I think, Go.

And some use cases faster, some use slower, but really very, very high performance. And so after this really detailed write-up with numbers and everything, graphs and analysis, they said, look, the future of Python is here. Overall, it looks like fast asynchronous Python might be here to stay. Now that async IO really seems to be the default way that people are willing to work in Python and async and await has really caught on because of the non-blocking network and disk IO is usually the problem. It turns out the GIL probably doesn't really get in the way of speed that much for most use cases.

It's cool. Isn't that cool? So they said, look, it's working out great for us, Python 3, and we've got the scalability we need. No problem. And we're happy we didn't abandon it, because traditionally it hadn't been fast enough. So somehow I'm missing this, which they looked at Gepronto and Sanic and UV loop. Are they deciding on anything here?

I don't know which one they decided upon. I think UV loop is a little more established. UV loop is actually the foundation for Gepronto and Sanic. So there's a bit of a mixing, right? Like Gepronto and Sanic are extending these inserts. Pretty cool. There's a nice comment, which I linked in the show notes for this section. And there's somebody in there saying, hey, we went through the same basic thinking,

and here's how it worked out for us. And they said, we're also doing this async python 3 thing which is cool on twitter we got a message from sasha kurda and he said basically hey michael hey brian i have this example where i was doing a bunch of http client stuff and we talked remember we talked about aio http the client side stuff how much faster that can make it and he said that's cool. I was doing some scraping and whatnot. And my particular project went from eight minutes, over eight minutes doing requests to less than 45 seconds using the async and await stuff with AIO HTTP,

basically the same code. He was blown away. Yeah, that's really cool. And I'm glad that he shared that. Yeah, I am too too and of course you drew the correct conclusion from this conversation that look at the what is that like 10 time increase in productivity you get by listening to Python Bytes Yes, definitely

Alright You can save your company money too by listening to us. Absolutely, alright Well, that's it for this week's news. You got anything finally you want to share personally? Nope. Nope. Just plugging away at the book.

Same here. Plugging away at the courses. So thank you everyone for supporting all of our work, not just this podcast, but Brian's other podcasts, his book, my courses, my other podcasts. It's great to be doing this for everyone. So thank you. And thank you, Michael. Yep.

See you later. Thank you for listening to Python Bytes follow the show on Twitter via at Python Bytes that's Python Bytes as in B-Y-T-E-S and get the full show notes at PythonBytes.fm if you have a news item you want featured just visit PythonBytes.fm and send it our way

we're always on the lookout for sharing something cool on behalf of myself and Brian Auchin this is Michael Kennedy always on the lookout for sharing something cool. On behalf of myself and Brian Ocken, this is Michael Kennedy. Thank you for listening and sharing this podcast with your friends and colleagues.