Python Bytes - #8 Python gets Grumpy, avoiding burnout, Postman for API testing and more

Episode Date: January 10, 2017

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

This is Python Bytes, Python headlines and news delivered directly to your earbuds. It's episode 8, recorded January 10th, 2017. This is your host, Michael Kennedy, along here with my co-host, Brian Ocken. Hey Brian, what's up man? It's going really good. Yeah, glad to hear it, glad to hear it. I kind of feel like everybody's still kind of getting going after the winter break. I know, you know, we're both in Portland and we've been like,

our world has been covered in ice repeatedly recently. So it's been a bit of a strange start, but there's still Python news to talk about. Yeah, there is. I'm going to start with, actually, there was a Pi Bay 2016. I actually don't remember when that happened. It was sometime in the fall. I want to bring up one video, which is from Jessica McKellar titled Breaking the Rules from the talk it sounds like it was pre-election but so at least it was in the fall but yeah the video came up in December I was listening to it and was kind of blown away so Jessica was the director of the Python software foundation for several years and she's been involved with lots of stuff like the Boston Python User Group. And she's the diversity chair for PyCon. I guess she's an engineering director at Dropbox, which just sounds cool. But anyway, this was a keynote speech or a talk, and she was talking about of her work at with Python was not really about

Python but about studying systems and here's some cool quotes learning how to program changes the way you think about debug and interact with the world and you learn a set of rules on how to build software and then you learn that you can change the rules and programmers master a system that they know they can change and these sorts of uh comments that she talks about i i guess i knew but i didn't really ever think about it before and she takes it and uh she realizes that as programmers we often take it for granted that we if we were using a tool that we want to make better we can just go in and make it better it It's an open source thing. And, um, and that this should carry over to the rest of your life. She takes the idea and, um, applies it to politics and voting and,

uh, and stuff. I guess she, uh, ran a polling station by herself and her husband did a different one, which actually is pretty cool, but it's, it's neat to hear some, somebody firsthand say, it's not that hard to get it done. But I was, I like the idea of thinking about how the programmer mindset and how you can change the system that you're working in. And I think more people should apply that to their workplace a little bit. Um, that I've, I've hear about people that are unhappy at their job and they like a cubicle farm or something and they get out and do an entrepreneurial thing. And that's great for some people. But for others, I think maybe it's better to look at the system and realize that you're part of it and try to make it better yourself. Picture yourself in your manager's

shoes or your manager's manager. Wouldn't you want to hear from all of the employees if there's something that could happen to make it a better place? Yeah, I think it's a great message. I think I really like Jessica's work, and I actually had her on Talk Python on episode 30, and she's done so much for diversity and the way the Python community actually is today.

Like 10 years ago, it was very different than today. One of the things that she brought up in that talk was that, I think she said five years ago, but not, let's say a handful of years ago, the number of women speakers at PyCon was like 1%. And now it's like in the 30s, maybe low 40s percent. It's, you know, traumatically different. And there's a lot of changes like that that she was central in. So I think she does a great bunch of work. In that video, that was one of the questions is how did she do that? And the answer is awesome.

She just emailed a lot of people and asked them to submit talks. Yeah. And sometimes, you know, you just gotta ask, right? And you want the world to be a different way. Sometimes you just have to ask or take the first step or whatever it is, right? Like I think two ideas that sort of come to mind as you said that.

One is there's a quote that goes something like this from Steve Jobs. Like the world around you was made by people no smarter than you and you can change it. And once you realize that, like you can't just accept the world the way it is, you see that you can change it and you kind of must, right? And the other is, I really liked the notion of once you learned a program, you control the system as much as it controls you and you can change it. And you start to apply that thought to the greater world. And I think that's really something valuable that people that are on this learn to code, teach kids to code mission

don't get, but would be a powerful benefit to students and just everyone. And it's another reason to teach everybody to help more and more people to code. We don't have to generate an entire generation of programmers, but a generation that actually understood how computers work would be good. It wouldn't be bad. Yeah, I definitely think the world needs more creators, fewer consumers, but not necessarily more programmers, right? You know, people say that I'm a pretty happy guy, pretty optimistic guy, maybe to a fault sometimes. But usually people don't say I'm grumpy. But today I'm feeling a little grumpy. Actually, I'm feeling grumpy also.

Yeah. And grumpy, this time grumpy is good. I think grumpy is good. Grumpy is interesting. So the guys at YouTube, a particular guy named Dylan Trotter wrote a blog post on the Google blog, tech blog. I don't remember exactly which one, but it's in the links, called Grumpy is a Python on Go interpreter or runtime. So at grumpy.io, there it redirects to the GitHub repository. They've built this thing, and it was released really recently, like three weeks ago. And what it is, is it's a transpiler. It takes Python, legacy Python, sadly, so CPython 2.7, and it compiles it or transpiles it into Go code, which is then compiled and run on top of the Go runtime.

So there's a couple of interesting things. It's one, there is no interpreter. Two, it executes purely as Go. So all the features, and I really think the reason they're doing this is the concurrency story around Go and maybe even a migration story. We'll see about that.

But there's a lot of interesting things that they can do if they can get Python to run on top of Go. So one of the things that also caught my attention about this is this seems to have really taken people, captured their enthusiasm. Because it's on GitHub. They announced it a few weeks ago. And it already has 6,000 stars. Right?

For a project that's a few weeks old with 6,000 stars, that's pretty amazing. So I'm actually having Dylan on TalkPython to me on episode 95, which I think comes out next week. So look for a bigger story there. So is that one that's already recorded? No, I'm going to talk to him Thursday. So what's, do you know what the, what the reasoning, I mean, like I get why you'd want go for Python stuff, but why is, is the language go not enough and the Python language easier to write in or?

Well, I believe, I don't know. There's certain things that they can't talk about or don't want to talk about. So I don't want to read too much into it for them, but go as big at Google YouTube right now, the front end for YouTube is written in CPython two seven. So I would speculate that they're thinking of how do they not stay on python 2.7 yeah okay yeah pretty interesting you know another thing that would make me grumpy not in the python way but really grumpy is when i'm given a huge project like you know tens of thousands or hundreds of thousands of lines of code and they said here look through this and understand this code base and i look at some method or some set of classes and i'm like i don't understand what effect this has.

It seems to do nothing in this code and yet here it is. And I'll tweak it and play with it and it doesn't even seem to have any effect. And then I realized that code is never called. Yeah, hopefully it'd be cool if there was a way to say you could find some dead code and... You mean like if there was like a creature that could like soar through the sky and then would find these bodies and like consume them and they would be gone? Something like that?

Yeah, yeah. Or maybe we could have like a cheesy segue bot. But anyway. Exactly. There's an article by Dougal Matthews called Finding Dead Code with Vulture. And Vulture is a Python tool that you can install with just pip install Vulture. And it's really easy to use. I downloaded it, applied it to some code I was working on. And you actually can just point it to a directory and it looks at all the Python code there.

And tells you, I'm sure it analyzes stuff and does call trees and whatnot. I don't know how it works, but it like tells, gives you a list of all the functions and variables and lines of code that are not used. It was just really fast and really easy to use. I liked it in the comment from Dougal. There's some people that use really aggressive unit testing and TDD strategies, which makes it such that every function is going to have a test for it. But what if that internal function isn't used by anything else? Well, there's a way you can take your unit tests and exclude them from the vulture, which is kind of neat. I was thinking about,

you know, the comparison. Normally, I would find this sort of stuff by using flake eight. But like the example you gave, you wouldn't want to try to convert you get fix all the uh like the pep8 errors and things just to find dead code so this might be a good use case for that and also there's there are some people that don't like uh static analyzers like uh flake or whatever the other the other comment it was um that coverage, if you're running coverage over your code with your tests, that should tell you the parts of the code aren't used also. However, your test suite's got to be fairly complete in order for you to really be sure that that's true. So anyway. Yeah, it's tough to do it with coverage and testing, I think, because like you alluded to, there might be some function

that is never called, but you might have written a test about it. So then it kind of looks like it's live again, right? And the thing where I find this to be really insidious is I'm looking at some function and I realize if I take it away, this other function depends on it. And if I were to take that away, another function, and then maybe like three or four or five function calls back in this chain, these are all kind of dependent on each other, but nobody ever calls the first one. And so it's really hard to tell, like to follow all those chains and determine like actually this whole branch of code

that you're trying to deal with, just forget it. It's gone. You have source control. Delete it. Yeah. That's pretty cool. I like it. Yeah.

Yeah. They did warn about false positives, Just forget it. It's gone. You have source control. Delete it. Yeah, that's pretty cool. I like it. Yeah, yeah. They did warn about false positives, saying something wasn't used when actually it was. So be a little careful. Like, you know, systems that use conventions like, you know, Pyramid or Django or something, right? You map a route to a thing and it doesn't look like you ever called that thing. But obviously it's called by, you know, a URL, right just be aware be aware of those sorts of things but yeah it looks really cool speaking of tools that are cool you know i i don't get much meaningful mail these days but i do like this thing called postman yeah postman at i think it's at getpostman.com, is a cross-platform GUI app that lets you test and visualize and play with APIs.

I love my APIs. Yeah, so I've actually been doing some things that required me to write some APIs lately. And I'm like, you know, obviously I could go into the dev tools in my browser or I could write some, you know, some command line thing to test them. But this is really nice you can like create you know here's how I call this function as an authenticated user with this data and you could actually save that in this UI and you can even create them and share them across teams integrate these into continuous integration for like testing deployments or or more like integration tests of your whole system it's really

cool it's free. It's cross-platform. It's not written in Python, unfortunately, but it's still a really cool system. Question about that. When you say API, is that you're referring to like a REST API or some other web API?

Yeah, yeah. It says APIs, but I should maybe make it really clear. Those are services like HTTP services, SOAP services, things like that. Okay, great. Yeah, yeah. Not like APIs like pip install this package and then call this function.

Yeah, well, you know, when I'm testing or running on developing a new API, sometimes just it's tiring and I kind of get burned out on it. Yeah, you know, you and I have been programming for a long time and I, I don't know about you, but I've certainly gone through a period or two where I'm just like, uh, more of this. And it usually depends a little bit on the project. It's not really the programming. It's kind of like all the other stuff, you know, nitpicking at your time and energy. And so Kenneth writes, I'm going to going with writes, not reads until I hear otherwise. Kenneth writes, does a bunch of great work. He's the for humans guys. We talked about Maya last time, right? Yeah. Last episode we talked about Maya and he's of course the author of requests.

But he wrote this article called the reality of developer burnout. And I really, I'm glad he did it. I had heard that he was, I don't remember last year or something, suffering from just like burnout of being the main support person for an open source project. Yeah. And he's not the only one. Like, gosh, I can't remember the guy's name, but he's in Lawrence, Kansas. He's one of the founders of Django. Also just got totally burnout and had to just step back. And I remember there was like a half-hour conference presentation that was kind of like a goodbye or something to that effect, if I'm remembering it correctly. But yeah, there's

plenty of stories of people getting not just requests, but like angry email for stuff they're doing for free, right? Open source projects and so on. Definitely. And I think I'm not a, I don't maintain a large open source project, but the definitely maintain tools within our company. And, and I think a lot of people can relate to some of the things that Kenneth talks about in burnout in this article, but I think he has some decent advice. Some of the advice he gave was to just keep producing just keep, um, keep producing, but possibly not at the same speed, but, uh, stop consuming so much on your social networks. Uh, he, he like disconnected from Twitter for a while. He didn't quite pull a four 10 gone, right. But, but like, just stop following people, stop looking at it, um, so much. And, uh, and then he also

talked about delegating more, trying to, it is a community, so try to get other people of the community to take over a lot of the roles that he had within the request community. And then also generate other hobbies. Don't do all of your free time just doing coding. There should be some non-programming hobbies. I thought it was a great article. And I was poking around trying to get links for the show notes, and I came across, when I was looking at the Maya, the GitHub page on Maya, and it said, say thanks to Kenneth.

And I had never seen this before, but apparently there's a saythanks.io that's a Kenneth project that it just sends a little thank you note to the person that set it up. So I thought that was a cool project. Yeah, yeah, that's really awesome. So for our final one, our final topic brings us snapping back to the future, away from Grumpy and Python 2.7, back to current Python. Yeah, and hopefully you're not burnt out on template languages. No, I'm still a big fan of server-side templated web applications.

And one of the real popular ones is Jinja, Jinja 2 by Armin Roeniger. And he's the guy behind Flask. And he just released Jinja 2.9. This is really cool. And thanks to Hugh Blanford for sending us a note to say, here's a cool thing you should talk about on Python Bytes. So here we go. And one of the things that was stood out both to Hugh and to myself was the deep integration with Python 3.6 and the asynchronous concurrency story around that. Armin says, while Ginger 2 supported Python 3 years ago, it never really fully embraced the Python 3 features because they wanted to make it basically lowest common denominator, so it'd work

on Python 2 as well. But now they say that it actually supports async generators, which fully support the async and await keywords. So it means if you pass some kind of generator that is an async generator to the template, and it's going to like loop over them, it will await it as it does that, which is fantastic. That's just so cool to see async and await and the concurrency flow all the way to the HTML. So where would this like affect it? When does the template engine end up doing coroutines? Well, yeah. So the template engine runs after your view method,

your action method runs and you pass back the model. But the thing is the model itself could have a collection that is a generator. And normally you would just loop over it, right? the model. But the thing is, the model itself could have a collection that is a generator. And normally you would just loop over it, right? So I've got like some kind of set of results. And maybe that came from a database query or computing it from a service, who knows. And you're going to like do a for loop over it and generate a bunch of, you know, 10, 100, whatever little sub HTML pieces in your template. Well, even if that was asynchronous, it wouldn't treat it that way. It would just call it before.

So now it can call, it can do this in an awaitable way. So my understanding is that if each one of those steps has to go to file or network or something, or it's like a database query, and it's sort of flowing through as you pull the items out of the generator, it will free up the thread to go do other web requests while that part is running, whereas before it would. Oh, that's very cool. I like it. Yeah, it's quite slick.

Another week in the Python world, and we have a bunch of cool stuff. So if you're using Jinja, get the new version. If you're feeling burnt out, check out Kenneth Wright's things. If you're doing APIs, check out Postman, bring out the vultures on that legacy code and check out Grumpy as well. Lots of cool things. And system programming as a larger concept with Jessica. These are good things to check out. What's going on with you, Michael? Do you have any news you want to share? Oh, I don't really have too much news. I'm just working like crazy on a couple of projects. Some stuff going on with you, Michael? Do you have any news you want to share? Oh, I don't really have too much news. I'm just working like crazy on a couple of projects.

Some stuff that I'm doing got me interested in Postman. I'm doing a bunch of API stuff right now for a project that I'm working on, but nothing I'm ready to talk about. How about you? How's the book? It's getting closer and closer to a— we're now targeting hopefully a beta release for pycon but i am i have a handful of people i'm going to try to uh to to get a hold of to to be

beta readers and um not just not beta readers but uh technical uh consults um to technical editors to just read through it um i think it's a couple of week thing, but if anybody's listening and feel that they really want to contribute to making sure I don't make any PyTest mistakes, yeah, hit me up and I'll put you on the list. Yeah, that sounds great. Get early access to the book. And are you giving them credit? Do they get like a little thanks to? Oh yeah, definitely. And it's all handled through Pragmatic. So there's a limited number of people. So I don't know how many people they'll pick, but I want to give them a bunch of names. Excellent. Well, glad to hear it's still moving. Yep. Thanks. All right. Thanks for sharing your stories with me. And it was great to chat with you and with everyone.

Oh, yeah. Thank you. Yep. Bye. Talk to you next week. 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 Ocken, this is Michael Kennedy. Thank you for listening and sharing this podcast with your friends and colleagues.