Python Bytes - #78 Setting Expectations for Open Source Participation

Episode Date: May 18, 2018

Topics covered in this episode: The Forgotten Optional else in Python Loops libraries.io The other (great) benefit of Python type annotations Setting Expectations for Open Source Participation ngrok Extras Joke See the full show notes for this episode on the website at pythonbytes.fm/78

Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds. This is episode 78, recorded May 17th, 2018. I'm Michael Kennedy. And I'm Brian Harkin. And we have a special guest with us here, don't we, Brian? Yeah. Yeah, hey, Kojo. Hello, hello. Yeah, we have Kojo Iturisa here on the show. Thank you for coming and joining us.

No problem. Thank you for having me. Yeah, it's really great. All three of us got to have a wonderful time at PyCon, didn't we? Yes, we did. Oh my goodness. So I'm totally going to recap on that first, but let's just say thanks to Datadog. This episode is brought to you by Datadog. Check them out at pythonbytes.fm slash Datadog. They were at PyCon, and so were all of us. In fact, Kojo, you and I, we kind of jumped into the deep end, like right at the beginning. I was sort of standing around outside and you walked in this room and, you know, just it was like, hey, we don't have enough people or enough room to give this welcome speech to all the newcomers. So you and I ended up giving the welcome speech, right, to a second group.

Yep, you and I and Trey Hunter ended up sort of as the impromptu hosts of that. Yeah, at first it was Trey Hunter. I mean, I saw you walking like, hey, you need to come up to the front and be part of this. So that was really awesome. Thanks for doing that with me. Brian, what was your favorite thing about PyCon? I guess seeing everybody that I only know from their little tiny circle icon on Twitter and being able to see them in person and chat.

I was actually often surprised because I didn't recognize somebody, even though I see their little picture all the time. Well, you know, how many tiny pixels? It's like a 64 by 64 sort of thing, right? Yeah. Yeah. Pretty funny. Pretty funny. So, Kojo, how about you? Favorite thing at PyCon? I think for me, my favorite thing about PyCon was maybe just getting a chance to get caught up with folks. Getting a chance to get caught up with folks, getting a chance to get caught up with people that I already know, then also getting a chance to meet new people. And I think the sort of the impromptu leading of the new attendee session was nice because it made it easier to meet new people. Yeah, that was really nice because the people felt more

comfortable coming up and speaking to you and me after that. I think my favorite thing was actually the live Python Bytes recording. That was fun, right, Brian? Oh, that was a blast. Yeah, it was really good. We need to do that every year. I think I'm definitely planning on doing that again every year. I'm thinking about trying to actually propose that.

It's like an official part, an official activity that is part of some of these conferences like PyCascades or maybe PyCon or something. But if nothing else, certainly the open session was awesome. And we'll talk more about that later. But let nothing else, certainly the open session was awesome. And we'll talk more about that later. But let's get to your first item, Brian. Somebody forgot an else statement. Is that what happened? Yeah, well, there's more else statements in Python that you might not know about. Like,

I read this and I'm like, oh, yeah, I forgot about these. Anyway, so both for I mean, you can use else clauses for if statements. Everybody knows that. But for and while loops also have if statement or else clauses. They're while and for loops or loops. And if they complete all the way through, then the else clause gets run. And there's a little article to describe that that we've linked to called the forgotten optional else in Python loops. But I wanted to highlight it because often I forget about it. The thinking around this is if you're using a loop to

search for something or search for different things, and you want to bail out if you find something, one of the ways is to mark a flag to say, hey, I found this thing. But you don't need a flag if you take advantage of the else clause so i just wanted to highlight that and remind everybody yeah so both the for and while loops and these definitely seemed a little bit funky to me when i when i learned about it and like wait the while loop has an else clause my mind is melting kojo have you did you interact with these have you ever used an else clause on a loop on a form i don't know that i have actually yeah i always look at them and wonder wonder why they're there i mean it's pretty cool to know about them i feel like this is um one of those things that you could get asked in a job interview

right like oh what is the else clause do you like wait there's an else clause how interesting so this is i would say this is one of the less used part major pieces of syntax in the language for sure i would definitely since i know a lot of people don't know about them, if I was going to use one, I'd probably add a comment there to say, hey, if we don't find the things, then we do this stuff. It's interesting. It's definitely like one of these sort of Pythonic things that is not necessarily obvious, right? It's kind of like self-contradictory in that sense. Yeah. Yeah.

Pretty interesting. All right. Kojo, you found some pretty cool stuff with some libraries and dependencies, right? Tell us about those. I got exposed to this, really, I think on the last day of PyCon. There's a website called libraries.io.

And what it does is it lets you not only find different packages, so like PyPy will let you find a number of different packages, but what libraries.io does is it will let you find dependencies based on packages. So if you go to libraries.io and you search for a certain package, and then you can see what other packages that that package depends on.

And so it's an interesting way to sort of see, to find out, like if you're building a project, what things are you depending on? And then maybe what things are those things depending on that you might not have been aware of. And it will also point out like versions and that sort of thing. So you can drill down fairly deep into it. I think the person who introduced it to me was pointing out that, I can't remember the package now, but there's a certain package that depends on Twine, which is the packaging tool, but it depends on an older version of Twine. And so on version of Twine, is like, say, maybe like a year or so old.

And so you can find that kind of information. And so I thought that was interesting. And then along with that, libraries.io is run by a site that is called Tidelift that is looking to try to help

bring some financial support into open source software. I haven't had a chance to look into that in great detail, but it's interesting how the two are connected. That's pretty interesting. So it's almost like you can get consulting support agreements for a package that you might want to use.

It's kind of what it sounds like. Yeah, it seems that way. Like I said, I haven't had a chance to dig into it in a lot of detail. So I focus a little more on libraries.io. But I think with libraries.io, you can help determine, okay, well, what packages might I need or want consulting support on? So what are the packages that my project depends on heavily and at the same time might not be getting as much support as I might want? And so maybe I want to focus my support dollars on that particular package, just maybe two or three

levels down in the stack. Yeah. How interesting. So it says they give maintainers and core teams a platform and marketplace for building sustainable business around their project. I bet that resonates with a lot of folks who are out there listening to the show. I know there's been a lot of work done, a lot of people who have been looking into how do we make open source projects sustainable instead of just having to depend on volunteer work.

I think the most straightforward way that this has worked traditionally is either a very small amount of donations or consulting. If I work on, say, Flask, then maybe I could consult on help people out who are doing large Flask things. But this looks like a nicer sort of more formal arrangement so yeah i really hopefully that that takes off that'd be great for people i think one of the things i was just playing with it one of the fun things about libraries.io is to look up a if you're trying to use a use a new package that you haven't used before you new library you can look to see who else is using it. So you can maybe look at their source code and see how they're using it. It's true.

That's interesting. Oh, I see. Other projects, right? Like here's some library. Who else uses it? Oh, look, request uses it. So that must mean it's pretty stable or something like that. Or even just to look at code examples of how they're using it.

Yeah, very cool. That's a good find, Joe. Thanks. So either of you guys out there, are you using type annotations and type hints in your Python code? I am not, but I had a brief discussion about them when I was in Chicago a couple of weeks ago. So yeah. Okay. Brian. Yeah, I'm starting to. Yeah. I think it's interesting. Like I certainly don't go type crazy on the code that I write. There's some obvious benefits for like really large organizations. And there's a great article I want to link to called the other great benefit of Python type annotations. So they talk about things that are

fairly straightforward that, you know, it's like, we've had these type annotations for a while, but maybe it's a little unclear when to use them. So it's good if you have some big project, you want to somehow verify that things are working, right? So you can employ like static code analysis, right? With like MyPy or a lot of things. We've talked about some of the tooling previously, Brian, that you could run across your code and will like generate these

and then you can decide to incorporate them. One idea I really like is sort of a twist on an Uncle Bob quote, who's sort of a software architect guy, says cleaner code or the code that is self documented is really great. And traditionally, people said, well, we don't need a comment when you can use a function or a variable that's like well named. So maybe another way to look at it, another thing to say is like, we don't need a comment when you can specify to talk about the types when you could say specified type annotation. So instead of having a comment saying, hey, this variable is such and such, like a type annotation makes that sort of readability super, super easy. That's great. And then obviously, they're sort of optional, right?

This whole progressive typing, or gradual typing thing that they're doing is great. So you can add it won't break your code, but it also won't make it any faster right just use it where it's useful for you but this article says the final sort of straw that was like the massive benefit for this guy and i agree with him which is why i brought this in is around code completion yeah definitely right so like i've got some big application and i typically put this sort of stuff on the boundaries of one layer talking to another layer so So I have the web app, the web app consumes some sort of data access layer, logic layer that deals with services and data. Like if you annotate just the stuff that is like public from that, that data layer, it just flows through the rest of your application and makes it super, super obvious, which I think that's pretty nice.

I was actually looking at an example of this last week of, for instance, like if you've got a class that's like a new data class that has type annotations, and you assign that to a variable, and then you try to access elements of the variable, like PyCharm can like help you, for instance, other editors as well, but PyCharm does those hints and will tell you the types of the different elements that you have access to. Right. Or if you were to return some object from a method, it might just have no completion because who knows what that could be. But if you annotate the return type, all of a sudden it like comes back to life. What editor do you use? Primarily Sublime, but my coworkers, I've had some coworkers use Sublime and some who use PyCharm. So I've started using PyCharm more

on the QA team where I work. And so the other QA person tends who use PyCharm. So I've started using PyCharm more on the QA team where I work. And so the other QA person tends to use, uses PyCharm. So I sort of go back and forth between the two, like on my personal machines, I've got Sublime and on my work machine, I've got both. And so I use them both in slightly different ways.

You're getting sucked into the PyCharm. Exactly. Orbit. And I remember, I've also good things about it. I also remember reading an article that you wrote about the benefits. I think the nine benefits of PyCharm. Yeah, that was quite a while ago.

That really lays it out, right? And this code completion to one of them and this type annotations makes that better, which I think is pretty awesome. So, yeah, I just wanted to throw that out there. Like, there's a whole sort of static code analysis stuff, but this code completion, pretty major. All right, before we get to the next one, let me tell you all about Datadog because they are major supporters of the show and they really are helping keep it going. So be sure to check them out. So it's a monitoring solution that provides deep visibility into distributed applications. So maybe you've got some microservices or got different Python applications and you want to see how the

database and the Python app and Linux itself are interacting, go check out Datadog. So just a few minutes, you can investigate some bottlenecks in your code, figure out where it's slow and make it better just reading a few dashboards. So pretty cool. So visualize your Python performance today, get started with a free trial of Datadog and they'll send you a cool Datadog t-shirt, which is awesome. So just go to pythonbytes.fm slash Datadog. they'll send you a cool Datadog t-shirt, which is awesome. So just go to pythonbytes.fm slash Datadog. Brian, when people create open source projects, they usually do it because it's something that they love, but then people start to depend on these projects and that can create some sort of animosity, right? There's a lot of burnout in the

open source space because of it, I think. we've we've seen a lot in the last couple of years of people, you know, even taking a month off or six months off to try to get away for some of it or dropping projects, trying to find other maintainers because maintenance is kind of a hard problem. This was something that was brought up. And you said that from Brett Cannon, i saw this talk uh sunday morning for the sunday morning keynote at pycon and uh you said that he also gave it at pike escades i don't know if it's exactly the same but this general message yes yeah so um the talk was called the setting expectations for open source participation but it really is uh it was a discussion about kindness and paying for open source with kindness. And he really talked about, he gave some examples of basically every communication you have with an open source project, even like a bug report.

You need to realize that you're taking somebody else's time out of their free time, the free time they could be spending on their own projects or with their family. And so be aware of that. And, and he gave some examples of some good interactions and some bad interactions, and then also some guidelines for how to communicate online. It was pretty good. I think the major, sort of the main takeaway was most of these interactions are you asking for a favor and it sometimes doesn't seem that way, right? Like, so if I go to a project and say, here's a pull request, it's super small, all it does is add this one feature, it's like 10 lines, you can just read that. And it's no problem. But if the person decides to accept that, right, they're not you, they are responsible now for

maintaining it, but also documenting it, potentially testing it, evolving it, right? There's just so many layers. It's like, hey, I did you such a nice favor. Here's a puppy. I got you a puppy. And then, you know, the person doesn't like it. It's like, why don't they like the puppy? I got him. That's so nice to give a puppy, right? But you're really giving this thing that you have to care for for a long time, even if it's something as helpful as actually here's a pull request. Yeah. You're asking for work for somebody else's work. And we forget about that because we're used to like products where we can like complain about the Apple laptop keyboards and it's just okay, but we probably ought to be nicer about that. But when you like even complain about or

tweet a negative thing about an open source project or have a bug, a bug report where it's just like, I needed this to do this thing and it's broken. You're really hitting somebody. This is somebody's like somebody's passion. Somebody's spent a lot of time on, and you're saying to them, this is garbage. So yes, do bug reports, but do it in, it's open source, it's volunteer effort. So do it kindly, do it like you were asking your mother to do it or something like that. And he presented it so well that I think this sort of topic needs to be talked about more, even within groups. I realized after listening to this and watching it that I think it will help me even interact with my own team at work when

it isn't volunteer, it's people getting paid, but you still need to be respectful and considerate. It's still basically a zero-sum game for their time and energy. So by doing something, you were sort of taking a slice of that that maybe they didn't ask you to take, right? Yeah, yeah, for sure. Kojo, did you get to see this talk, either in Vancouver or at the conference? No, I saw there was a similar talk at PyCon Canada in Montreal, but I saw it in Vancouver. Yeah. So have you had any interactions with folks where you see people like giving up on open source projects or other folks being unkind? I've seen a little bit of that, maybe a little more than I would like. I have seen people sort of complaining about open source projects, maybe not meeting their standards or not being updated as quickly or as well as they would like.

I tend to be a little bit prickly about that kind of thing because I think, so I'm relatively new to software engineering and a lot of my exposure to software engineering practices have been through the open source community and through some of the larger open source projects. And so I have an understanding that a lot of these things that people depend on are being built by volunteers who are doing it in their spare time. And I've been fortunate enough to meet a number of these people. And so I know some of these people personally. And so I guess it sort of helps humanize it for me a little more. So I try to sort of push back on those things like, hey, you know what, how much did you pay for this? Or how much are you paying for this? And also, you know, you can, if you want a problem fixed, there's a well documented process for you to make a contribution

to help fix some of the problems for yourself. And if you're someone who's a more experienced developer, it's not that difficult for you to do. I think that's a really good point. I guess the thing is, don't take it out on people, just vote with your feet. If you see a project that has a hundred unresponded to PRs, maybe that's not a real healthy project and your choices are, don't be part of it or become a contributor, but don't abuse the person who's already overwhelmed and already has too much going on, right? Exactly. Yeah, yeah. All right. So what's your next pick, Kojo? My pick sort of ties into that, the idea of, you know, you've got these expectations for open source participation. My thing is sort of focusing on different Python

community events. And so, of course, you know, we all just came from PyCon. And one of the nice things about it, so there's PyCon itself, but then for me, one of the nice things about it was a chance to meet some of my, to get back together with some of my friends from the Python community. Of course, we started off with, you know, actually spending some time with you and with Trey to help sort of welcome the first-time attendees to PyCon, sort of welcoming them into more active participation in the Python community. Yeah, that was fun. So let me ask you really quick about that while you're on the topic. Give me three really quick things people should know to have like a better experience at PyCon or local ones, maybe. So I would say one, try to have some idea of why you're there. Like, why are you attending PyCon? Are you looking for a job? Are you looking to hire people? Are you looking to learn new things? Are you looking to meet new folks? That sort of thing.

And I think whether it's PyCon or your local Python meetup, it's sort of the same thing. Like, you know, what are you going for just to learn or just to meet other developers who work in Python, just like you do that kind of thing. I think that's sort of the big thing. And the other thing is to maybe with something like PyCon, try to manage your energy because there are a lot of people at PyCon. There's a lot going on. You probably won't be able to go to every talk. There's a temptation to try to consume as much information as you can. And then I think along with that managing your energy, something that we pointed out to people is to try to sort of –

something like PyCon, try to optimize for the human interactions, like the open spaces and sort of the hallway track, because the talks are awesome, but they're all going to be recorded. And then the videos will be available fairly quickly. But the people that you meet and the human interactions that you have, or the cool things that happen in the open spaces, those aren't going to be recorded. So one of the things that I did at PyCon, one of the open spaces I was in was hosted by Adafruit. And so we got to sit down with some of the circuit boards that were in our swag bags and, you know, write some code and make, make LEDs light up and that sort of thing and, and sit with people. And, and so that's the thing that's not, I can't watch a video of that later. I can't do that again later. So I actually had

that sort of direct interaction with people. So I think those would be sort of three things to help guide people. I really liked to manage the energy because I was done at the end. Brian, how about you? Wiped out at the end of PyCon? Very wiped out. Yeah. And I think that contributed to some of my, kind of my funk and tiredness in the last few days. I'm still feeling it as well. I'm still, it was totally worth it, but I am wiped out. All right. So the last one, I want to share a personal story with you because we find all these things on the internet and I think they worth it, but I am wiped out. All right. So the last one, I want to share a personal story with you because we find all these things on the internet and I think they're great. But like every now and then it's like, I just found this thing and it's so helped me with

this problem that I was running into. And I think it'll help a lot of people out there. So I want to tell everyone about Ngrok, N-G-R-O-K. And that is a free with a premium upgrade sort of thing, service that you can go and basically ignoring all firewalls and all sorts of stuff, expose basically local ports or local servers on your computer. So if I have say like a mobile device and I have an app running on the mobile device and I want to test the services, but I'm like developing it. Maybe I want to even debug like how that's working. I could actually open, I could run this ngrok command. It'll do an SSH tunnel that exposes, say my local dev port back to port 80 on the internet. Then I go to that URL

and hit something on my phone app maybe. And it like, I can step through it in PyCharm on my local machine. I think that is pretty darn awesome. Or if you want to make, say, give access to your Raspberry Pi so you can get into it and call operations on it, test your chatbot. The reason I was using it is I'm building a set of applications, like proper compiled applications that are offline for my courses. So people can basically have offline access to the videos and like sync up their account and then not depend

upon being on the web or on the internet. Right. So that's what I've been doing since I got back from PyCon. It's building that. And I had been deploying stuff out to the internet and I'd connect to it and test it like, ah, that service isn't quite working. And I was getting a little painful. I'm like, why am I doing this? Because one is on the Windows machine, one is on my Mac, and it was easier to just do that, right? It wasn't on the same machine. And so I'm like, I'm just going to fire up ngrok. And then I can actually do the same thing I showed you about.

I can actually step through as the Windows app is interacting with the service that ultimately makes its way back over HTTPS onto my local machine. Isn't that cool? Yeah, that's very cool. I got exposed to ngrok by a coworker and I hadn't seen it before. And I was like, oh, well, that's, you know, that's pretty awesome.

Yeah, the thing that I think is most useful is so often like I work in the web world, right? So traditionally I had maybe made some changes to the web app and then we might have like a scrum meeting or like a quick sync up meeting. Like, hey, how's everybody doing? And I'm not ready to publish what I've done to the internet, to staging and mess everyone else up,

but I would still like to show people and let them interact with it. Instead of just doing like a screen share, you can go, well, just go to this URL and you can run it on my machine, which is incredible for a quick iteration of design and development. I just saw an interesting application for Angrok.

Maybe like the weekend right before PyCon, some friends who run a group here in town called Girls Coding Club, they were doing a sort of a tutorial session. And so you've got people sort of learning how to build basic web applications. I think they were using Rails, but then you can use Ngrok

and then expose that to the wider internet so that other people in the class can sort of can see each other's applications or you can send a link to a friend or what have you. So it's also really good for tutorials. Yeah. That is awesome. Yeah. Right.

For classes. Right. So I've got a Slack channel for that group. Everybody could ingrock their stuff and throw it in. Say, hey, mine's at, you know, random address.ingrock.io. Click on and have a look. And you could like without having to like reconfigure that on different people's servers. I love it.

And there's like a totally reasonable free tier, which is pretty awesome. All right. Well, that's it for our items this week. I just have a few extra things I want to share. Brian, anything else you want to throw out there? I did on the plane coming back from PyCon. I finally finished editing the interview with Trey Hunter. So soon there will be a test and code podcast with interview with Trey Hunter. So soon there will be a, a test and code podcast with interview with Trey Hunter.

So that should be out soon. I saw that you're, you're starting to publish a little more frequently, which is great. Thank you. Yeah. I'm glad you're doing that. So one of our listeners out there,

Steven, Steven Howell. Hello, Steven was kind enough to actually be live streaming our live. Well, semi-live in in-audience recording of Python Bytes last week. That's pretty cool, right, Brian? That is neat. Have you watched it?

No. Well, I watched some of it. So he actually took the video, and it starts a little bit a ways in, but he put it up on the internet on YouTube. So if you guys were listening to the live episode last week, and you're like, well, what was that actually like? Well, click the link at the bottom, and you'll be able to watch a pretty high quality version of it actually. So that's pretty cool. And then, you know, another thing I'd like to come back to just really quick is remember when we talked about how easy it is to have a system D daemon as a Python application to basically implement a system D daemon in Python. We talked about that in episode 54. Oh yeah, totally.

No, I don't remember that. But so it turns out you basically have like six or seven lines of configuration and then just an app with like a wild true loop. It's insane. And that's all you have to do to create like a system start run forever sort of application in Python. And it's really beautiful. So I recently used that technique from episode 54 to build a

global series of video servers throughout the world to do like geolocated video serving for all my courses to make that really much nicer. So added one in Japan, Sao Paulo and Mumbai this week. So that's that'll make it a little better for people out there listening. But it's also a cool application of what we talked about in episode 54. Nice. Very interesting. Yeah, very interesting. Incredibly simple.

I think more people probably would want to do it if they knew how easy it was. All right, guys. Well, that's all I got. Thank you, Kojo, for being here. And Brian, thank you as always for making the show happen. Thank you. Thank you for inviting me. Yep.

You bet. Bye, guys. 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. Thank you for listening and sharing this podcast with your friends and colleagues.