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 Okken.
And we have a special guest with us here, don't we, Brian?
Yeah.
Yeah, hey, Kojo.
Hello, hello.
Yeah, we have Kojo Iterisa 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/Datadog.
They were at PyCon. And so we're all we, 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 were, you walked in this room and, you know, just, it was like, hey, we don't have enough people to,
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 host of that.
Yeah. At first it was Trey Hunter.
I mean, I saw you walking.
I'm 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.
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 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 intenti 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'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.
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 are 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 learned about it.
I'm like, wait, the while loop has an else clause?
My mind is melting.
Kojo, did you interact with these?
Have you ever used an else clause on a loop?
On a for loop?
I don't know that I have, actually.
Yeah, I always look at them and wonder why they're there.
I mean, it's pretty cool to know about them.
I feel like this is one of those things that you could get asked in a job interview, right?
Like, oh, what does the else clause do?
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 them, 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 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 a version of Twine that's, 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 the 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 new package that you haven't used before, 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 typends 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.
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.
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.
It 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 specify 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 and 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 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 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.
Yeah.
What editor do you use?
Primarily Sublime, but my coworkers, I've got some coworkers who 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 to use PyCharm.
So I sort of go back and forth between the two, like on my personal machines, I've got Sublime and then 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 benefit, I think what the nine benefits of PyCharm.
So.
Yeah, that was quite a while.
That really lays it out.
Right.
And this code completion to one of them and these 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, 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 you're 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/Datadog.
Brian, when people create open source projects, like 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.
Definitely.
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 from 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 Sunday morning for the Sunday morning keynote at PyCon.
And you said that he also gave it at PyCascades.
I don't know if it's exactly the same, but this general message, yes.
Yeah.
So the talk was called Setting Expectations for Open Source Participation.
But it really is a discussion about kindness and paying for open source with kindness.
And he really talked about some, 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 with their, on their own projects or with their family.
And so be aware of that.
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 them.
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.
It's 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 OK.
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 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 even within groups.
Like I realized after watching, 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, you know, maybe they didn't ask you to take.
Right.
Yeah.
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, you know, I know some of these people personally.
And so, yeah, 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 is 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 100 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, say, 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 – it's 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 write some code and make LEDs light up and that sort of thing and sit with people.
And so that's the thing that's – 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 like 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're great.
But like every now and then, it's like I just found this thing, and it 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 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.
I'm like, oh, that service isn't quite working.
And it was getting a little painful.
I'm like, why am I doing this?
Because one is on the Windows machine and one is on my Mac, and it was easier to just do that, right?
Instead of – 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 told 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 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 Ngrok.
Maybe like the weekend right before PyCon, some friends who run a group here in town called Girls Coding Club, they were doing 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 – so 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, for – right, for classes, right?
So I've got a Slack channel for that group.
Everybody could Ngrok their stuff and throw it in.
Say, hey, mine's at, you know, randomaddress.ngrok.io.
Click on it 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 that should be out soon.
I saw that 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, Stephen, Stephen Howell.
Hello, Stephen.
Was kind enough to actually be live streaming our live, well, semi-live, 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 of 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 systemd daemon as a Python application?
To basically implement a systemd daemon in Python?
We talked about that in episode 54.
Oh, yeah, totally.
No, I don't remember that.
So it turns out you basically have like six or seven lines of configuration and then just an app with like a while 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'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 Okken, this is Michael Kennedy.
Thank you for listening and sharing this podcast with your friends and colleagues.