10 top talks of PyCon 2017 reviewed

00:00 Even if you got to attend PyCon, there were just too many great talks to go and attend them all.

00:05 Luckily, our friends at the PSF were on top of publishing the videos online for the whole world

00:11 to watch for free. On this episode, we'll meet up with Brett Slacken and replay his path through

00:17 PyCon. We talk about his top 10 favorite sessions from PyCon 2017. This is Talk Python to Me,

00:24 episode 116, recorded May 31, 2017.

00:28 Welcome to Talk Python to Me, a weekly podcast on Python, the language, the libraries, the

00:57 ecosystem, and the personalities. This is your host, Michael Kennedy. Follow me on Twitter

01:02 where I'm @mkennedy. Keep up with the show and listen to past episodes at talkpython.fm

01:07 and follow the show on Twitter via at Talk Python.

01:10 This episode is brought to you by Rollbar and CodeChip. Be sure to check out what they're

01:15 offering during their segments. It really helps support the show.

01:17 Brett, welcome back to Talk Python.

01:21 Thanks for having me.

01:21 Yeah, it's always a pleasure. We had a really nice time last, almost two years ago on episode

01:27 25. And now we're back to talk about PyCon.

01:30 Yeah, it's been a long time. I can't believe it's been that long. A lot of good episodes

01:33 between.

01:34 Yeah, thanks. It really has been a long time. So we talked a little bit before PyCon about

01:40 another show together. And you had this great idea of like, hey, we're both going to PyCon. Let's kind

01:44 of do a like a PyCon roundup and go through the talks mostly that you went to because I was,

01:50 you know, happily stuck in my booth talking to people. So I didn't get to that many talks. But

01:55 nonetheless, they're all on YouTube. So everyone listening can watch it even if they didn't go

01:59 to PyCon, right?

02:00 Yeah, definitely. And that's, you know, PyCon is a great conference for that reason is that on the

02:04 second day while you're there, they're already uploading talks from the first day.

02:07 So you can even watch some of the talks you missed yesterday. So you can talk to other

02:11 people about those talks while you're still at the conference, which is just really amazing that

02:15 they yeah, yeah, it's really amazing how quickly they come up and the quality, because going there

02:21 really is a bit of a paradox of choice.

02:22 Oh, yeah. And they actually set it up to be that way. Like they'll put all of the best talks,

02:26 quote unquote, best from the speakers that are, you know, most well known for the quality of their

02:30 talks, they put them at the same time. So you can't possibly go to all of the best,

02:34 quote unquote, best talks, you have to go and try different things out and see ones from new

02:40 speakers with different kind of fields of discipline and stuff like that. So it's, that's a big part of

02:45 the fun of being there. And they're able to do that because they know they're all recorded. So people

02:48 don't feel like they're missing out.

02:49 Yeah, they really do a nice job. So I definitely am looking forward to talking about these eight or

02:55 nine talks that we've picked out to discuss. Yeah. But before we do, maybe you know, it's been almost

02:59 two years, since you've been on the show, maybe tell people what you do day to day with Python and

03:05 things like that. Yeah, sounds good. So I'm a software engineer, still working at Google, I work on a

03:09 product called Google surveys. It's a research platform to answer questions, kind of market research and

03:14 survey statistics, we can predict elections and that kind of stuff. And we use a lot of Python to do that.

03:19 So it's hundreds of 1000s lines of Python, everything from Django looking code on the front

03:25 end down to NumPy and statistical functions. And we also use a lot of JavaScript and go and other

03:31 things for other pieces of the system. But overall, it's the majority of our code is in Python. And

03:35 yeah, that sounds like a fun project to work on. Yeah, it's been great. It's I've been working on it for

03:39 many years now. And it just keeps growing. And it's been amazing to see Python grow from you know,

03:44 my first commit was, you know, 2000 lines of Python and to have that grow by 100 or 200

03:49 times. It's been really remarkable that the language kept working.

03:52 It really does grow and stretch pretty well. It's awesome. We'll even talk about some examples

03:57 in some of these talks, like for example, with Instagram, right?

04:00 Yes, exactly.

04:01 So also maybe catch us up on your book. I originally got to know you through

04:05 Effective Python, the book that you wrote a little bit before we had you on the show. And I really liked

04:10 it. So it's still selling. Are you working on new books? Anything like this?

04:14 Yeah, great question. So it's, it ended up getting translated into a bunch of languages. It's doing well.

04:19 translated into Chinese, both traditional and simplified, German, Polish, Korean, Portuguese.

04:25 So it's been crazy to see Japanese also, versions of the book all over the place in the translations

04:33 of the word of, you know, the words Effective Python and all these other languages. So it's been doing

04:37 really well. Weird tweets and other languages that I don't know and translate doesn't really capture

04:42 programming jargon very well. So that's interesting trying to find friends of mine who know these

04:46 languages to help me understand what people are saying. But do they like the book or what?

04:51 Yeah, because it's like dry humor or like a joke about the cover not having a snake on it. You know,

04:57 there's like stuff that it's really hard to get through trans automated translation, right?

05:01 Yeah, absolutely.

05:01 But yeah, so I think I'm looking forward to, you know, everyone's watching the Python death clock of

05:06 Python, two, seven death clock of 2020. And so it'll be interesting to see. I think if you know,

05:11 if there's another if it's good to have another edition of the book in time for that, because so

05:16 much is changing. And I think we'll talk about that today. But no plans yet. I think it's still

05:20 material still really good and is up to date.

05:22 Yeah, excellent. So people want to check that out. That was episode 25 from a couple years ago.

05:26 All right. So yeah, let's let's talk about the talks.

05:30 Yeah, you went to PyCon. I went to PyCon. I didn't get a chance to go to that many talks. And honestly,

05:35 I find the hallway track to be really quite, quite valuable. You make these connections,

05:41 and you can talk to people there that, you know, those aren't recorded. And those won't be,

05:46 you can't relive those, right?

05:48 Yeah, definitely. And I think they're actually are recording the lightning talks now. But that was,

05:51 you know, I think if you went to the conference and just did lightning talks and hallway track,

05:55 you'd probably have a really good time.

05:56 Yeah, the other place that I spent a lot of time was in the open sessions.

05:59 Yeah, that's awesome. Yeah, I didn't get to go to any of those this time.

06:01 Yeah, yeah. And those are still not recorded as far as I know.

06:04 No, they're not.

06:04 It wasn't obvious if they were.

06:06 Yeah.

06:06 All right, cool. But let's focus on the talks that you went to. And I did go to some of them,

06:12 and then also went back and watched the others. All right. So the very, very first talk at PyCon,

06:18 the opening keynote was by Jake Vanderplass.

06:22 Yeah, and he's a longtime PyCon speaker. I mean, he's been there for many years. And I don't know if

06:27 you've seen his other talks before, but he's, you know, he's done tons of them. And he's up at

06:32 University of Washington. He's actually an astronomer. That's his job, which is just crazy

06:37 that that's someone gets to do that professionally.

06:39 So amazing, right?

06:40 Yeah. So yeah, I feel very inadequate whenever I hear him like talking about what he does day to

06:45 day and the science he does. It's like pretty awesome.

06:47 Yeah. A lot of the stuff that they do with Python and astronomy is really fascinating. And what struck

06:54 me about this talk, there were a couple of things. And maybe I'll set the stage before I touch on some

07:00 of the astronomy stuff.

07:00 Sure.

07:01 was basically Jake's theme. I think it was a great way to kick off the conference. It was that

07:07 the people that you are sitting among these 3000 people and everyone else in the community,

07:12 we're all here for Python, but we don't all use Python the same way. And we don't all have the same,

07:20 the same jobs, the same type of challenges and so on. So for example, if I sat down to write like a well

07:25 structured 50 Python file web application that talks to a database, I'll have one way of thinking and

07:33 working with Python. If I have astronomy data, and I want to just explore it dynamically, say in

07:40 IPython notebooks or Jupyter or whatever, that's an entirely different way of working with it. And

07:45 these different ways of working are an opportunity to learn more and catch Python from a different

07:50 perspective.

07:51 Yeah, exactly. And he called it, I think, the mosaic of Python, which I really,

07:55 I really liked the analogy there. And that's a big part of what's great about going to Python,

07:59 or even just watching the talks from it is, you have these people from just very different disciplines

08:04 with very different backgrounds, talking about these subjects. So yeah, he really emphasized that

08:08 very well.

08:09 Yeah, I thought that was a great, great opening message. And it was like, okay, I see that the

08:14 people I'm talking to, maybe they really do have not just a different way of working, but a really good

08:20 reason to not work the same way that I do. And so I think it kind of opened my eyes a little bit to

08:24 appreciating the differences.

08:26 Yeah, definitely. And then he walked us through like all of the tools that he uses, or he knows

08:32 of in the scientific community, kind of went, walked through like, you know, where they came from. And

08:37 it was really interesting to me, because he, the way he actually showed it was in kind of these

08:42 concentric circles of dependencies, you know, where at the core, you know, is Python itself, and then

08:47 something like NumPy, which is really like a fundamental tool for numerical computation and Python.

08:52 But I didn't even realize how many additional layers on top of that there are, you know, in terms

08:57 of machine learning or data processing or things specific to astronomy. And, you know, he basically

09:02 went off the page with how many concentric circles there are.

09:06 Yeah. Yeah.

09:07 Here's Python. Here's a bunch of scientific stuff that you may have heard of. Here's a bunch of,

09:12 you know, higher level scientific stuff that builds on top of that. Here's all the amazing

09:16 things that they're doing at in astronomy on top of that. Oh, and by the way, here's all all of these

09:23 amazing satellites that are coming online, that you basically work with them through Python, which is

09:30 really, really amazing.

09:31 Yeah, that was crazy. Because yeah, like the a bunch of different telescopes he showed,

09:35 and then he like went to the GitHub page where the code is actually completely open source,

09:39 mostly written in Python, and you can actually go in and fix bugs. And that was another thing he was

09:44 basically saying, you know, in there is that and so is I think Katie Huff and her keynote later,

09:49 but, you know, you can go in there and you can you can contribute to these satellites, you know,

09:53 which is crazy. So it's all done in the open, the kind of this open science approach to,

09:57 you know, astronomy that hadn't really been there in the past.

10:00 Yeah, that was another super interesting theme of this talk was how we've seen how successful open

10:06 source has been. And the challenges as science becomes more technology of how do we make science

10:13 reproducible. So let's try to follow a kind of a similar path with open science as we do with open

10:19 source.

10:19 Yeah, definitely. And I think that that's, there's this graph he had, I think he might have tweeted the

10:23 graph last year at some point, but just the graph of like, number of astronomy,

10:27 publications, you know, in academic journals that are using Python, how it's just taking off. And so

10:33 it seems like this is really interesting effect that the open source approach of the Python community

10:38 has had on astronomy in particular, and is starting to have more generally where people are publishing

10:44 their code, their methods, their data, putting them out there so that all the results are reproducible,

10:50 easy to verify, you can't p hack the results so that you're getting fake discoveries and stuff like

10:55 that.

10:56 Yeah, I thought it was really great. And the graph that you're talking about, I mean, it really looked

11:00 like an example of an explosive growth startup out of some sort of growth hack story. But yeah,

11:08 no, this is the number of things using Python now, right?

11:11 Yeah, it makes you think that we just learned how to get into space, or we just invented the telescope,

11:15 because it's just taken off. It's bizarre. So it's really great. And science is very computational

11:20 now, where maybe in the past, it was more about labs or film processing or something like that. It

11:27 seems like data processing is how science is done. And that came across really strongly as well.

11:31 Yeah, it definitely did. One final thing that he covered that I thought was interesting that kind

11:36 of is related to that was, people traditionally had learned in the sciences, some very focused language,

11:43 like there's some language, I don't remember the name of it, that is like, here's how you do astronomy

11:47 programming, you know, IDL or something like that. Yeah, yeah, I believe it was IDL. That's right.

11:51 And he's like, that's really great. You can get astronomy job with that. But if all these people

11:55 now are grad students learning Python, like if for some reason, they don't decide to pursue

12:00 astronomy, they have a super marketable thing that they've learned as part of it, right?

12:05 Yeah, definitely. Yeah, it's much better. And then also people can contribute back to astronomy in a

12:11 way that so it goes both ways. It's two way street, you know, right, like maybe we're programmers,

12:15 we can program really well, but we don't, we're not astronomers, but we might want to like hobbyist

12:19 in it a little bit. And we can actually help out on structuring code or performance or something,

12:24 even if we're not astronomers, right? So you're right, like, I would never go contribute to an

12:28 IDL program. No, no way. Yeah, it's not gonna happen. Yeah. All right. So going from the sciences

12:33 and the sort of mosaic, let's kind of go back to maybe more traditional computer science,

12:39 like large software development house with Dropbox, right? Yeah. This is the talk on

12:44 mypy and static typing with I think Yuka and David from Dropbox, which is also where Guido works.

12:51 Yeah. And this project, mypy is something that's like Guido's main focus right now. He said when I

12:55 interviewed him, what is that like a couple months ago? Oh, great. Yeah. And the things I mean,

13:00 there's a bunch of things I didn't know here and a couple points that I thought were really

13:03 interesting. But the first one is they just, you know, oh, okay, Dropbox has 5 million lines of

13:07 Python. Wow, that's a lot. That's, that's cool. They just tell you that. And then 700,000 lines of that

13:13 are typed now, which is a lot of code. And so they're actually running the type checker at build

13:19 time. They do it as part, almost like part of their continuous integration process where

13:24 you can't commit to upstream until you've run the type checker and verified that it's clean.

13:30 So it's and then they, they actually said that it's helping engineers at Dropbox move faster,

13:36 get more done, do larger scale refactorings. So I think the proof that typing was a good idea,

13:43 Guido is basically helping realize that and kind of test it out and make sure that that this is

13:48 worthwhile. So any naysayers will be like, well, okay, this is not just an academic exercise in

13:53 typing. Like we actually have practical use cases, a very large practical code base. And we've shown it's

13:58 valuable. Yeah, they had a pretty interesting example of just like a three lines of code or

14:03 maybe four lines of code, like really, really simple function. It's like, you have no idea what

14:07 this does. It's entirely simple. And but it's it's kind of similar versions, but not identical versions

14:13 exist in a lot of places in 5 million lines of code, which one is this? And how do you know you're not

14:18 breaking it? Right? Yeah, definitely. I thought that was pretty interesting. And they also went through a lot

14:24 of the ways in which you might approach this problem, right? You might put some sort of like, comment in your

14:32 code, to say, here's what the types are. But then they talked about all the various trade offs on that, right?

14:37 Yeah, definitely. And I think it's also interesting, because right now, you know, in the landscape outside of Python,

14:42 you have things like TypeScript, which is the language from Microsoft, and Google's working on it, related to Angular,

14:48 the web framework. And then on the Facebook side with react, which is a great framework for for JavaScript

14:54 UIs, they have something called flow, which is also a type checker. So there's a parallel here where

15:00 in flow, you know, you do all the type annotation, a lot of it with comments. And then with TypeScript,

15:06 you do it in line with the special kind of syntax looks a lot like Python, actually. And then Google's

15:11 old closure compiler for JavaScript also had type annotations and comments. And then in Python to seven,

15:16 you can get all of the functionality of mypy and typing also do by doing it through comments. So

15:20 it's kind of like this thing where it's like, well, we didn't plan to have this in the language. So we

15:24 had to figure out a way to shoehorn it in using comments, that it's a common theme. But now Python

15:30 three, six, and even since three, three has all the different parts of support that you really need in

15:35 order to add types everywhere that you'd want. Yeah, and I don't see it being used that often. But I find it,

15:42 I find it really a valuable thing on the boundaries of parts of my program, like, like,

15:48 here's this whole data access layer. And I'm not going to go and like fill out the whole data access

15:51 layer with type hints. But maybe on the external functions that are being used by the rest of the

15:57 app, like just as you cross that boundary, I find it a really helpful thing some of the time.

16:02 Yeah, definitely. And I think like with the code base, I've been working in, you know, this 350,

16:06 400,000 line code base, you know, we've got a bunch of spaghetti in there that we really could,

16:10 it'd be better if we could refactor it out. And I think finding, kind of discovering the common

16:15 components in there and putting a boundary around them with a well defined interface that has typing

16:19 information would make the whole system much more stable and easier to understand, easier to test.

16:24 So I'm not against types. And I think that for core libraries or core functionality that a code base

16:30 relies on, it's really valuable. And I liked that they had a really gradual way of adopting it. It's

16:35 not some big bang thing where you need to go in and start writing types from day one, or you have to

16:41 freeze your whole code base, switch everything to types and then unfreeze it, you can actually go from

16:46 a leaf node up to a root node in terms of the file interdependencies, one file at a time,

16:51 and it all works as expected. It's like a depth first conversion.

16:55 Yeah, yeah, exactly. So, so I think that's really cool that they they've really thought

17:00 through that. And they've actually done it. And they explain the strategies for how they would do

17:03 it. And you're like, okay, run the script this way. Some best practices around checking in the script

17:08 you use to run my pie to make sure that you actually are running it consistently across all

17:12 developers workstations. But it was really cool how much progress they've made, even since the last

17:17 time I saw a talk on this. Yeah, it does really look quite nice.

17:21 There's two things I'm most excited about here. I mean, I think the first one is just structural

17:24 typing in Python. I think if you've used Go or TypeScript recently, the structural typing of the

17:31 interfaces, it's just so nice where you can say, oh, this is looks like a duck, quacks like a duck,

17:36 it's duck. And we can strictly enforce that it's a duck at compile time. It just feels so great. And

17:42 it's interesting because my pie doesn't do this. Like Python, you always think of it that way. You're

17:46 like, oh, if I can call dot open on it, then I can pass it to this function, right?

17:49 Right.

17:49 But the type system so far that they're implementing really looks like the Java type system.

17:54 So it's kind of odd because it's not really Pythonic yet, you know?

17:58 Yeah, that is really interesting because it's not like you're expressing like the thing that comes

18:02 here has to have these two functions in this field.

18:05 Right.

18:05 It's just, it has to literally be in this type hierarchy.

18:09 Exactly.

18:09 Yeah. Interesting.

18:10 Yeah. And so I think that it's not ready for prime time until that's like, I think people will have

18:16 trouble adopting it because they'll feel like it's a little clunky until that's done. But they said

18:21 they plan to do that, which is awesome. Yeah. So that is awesome. Yeah. And there's a pep.

18:25 Oh, what's the pep?

18:26 Oh, I haven't actually found it. They just mentioned there's a PEP for proto. They call it protocols.

18:29 Okay.

18:30 There's a PEP for my pie to support those. I couldn't, I haven't actually dug it up yet,

18:33 but I need to find it.

18:34 Right. Okay, cool. Yeah. If you're working in PyCharm, it will do that sometimes. Like you can

18:39 hit a button when you're at the call side of a function and it'll say there's no type hence here,

18:45 but you're going to need these three properties on whatever you pass. And it'll kind of like pop

18:49 that up. But yeah, it would be really cool if this supported, I didn't really even think about like,

18:54 okay, how, how sort of almost incongruent this way of specifying types is with the way that people

19:00 think of dynamic typing in Python. That's interesting.

19:03 Exactly. And there's one other repercussion of this that I think is extremely interesting,

19:07 which is, you know, in Python right now, like you're writing, let's say you're accessing a

19:10 dictionary and, you know, it's my dictionary, square bracket, the key, and then close square

19:15 bracket. And maybe you'll do that in a try except, and you'll catch the key error because you're

19:19 expecting that there might be a key error. Like the key may not be there. It's a common idiom.

19:23 You see people, oh, I expected this exception to happen. So I'm going to catch it right there.

19:27 Instead of checking if the key's there and then fetching it, I'm just going to go for it and then handle the exceptional case. In that way, like exceptions

19:34 are part of the interface for a lot of methods and functions. And you see that all over the place

19:37 in code. And it's not slower in Python. It's about the same speed as a function call. So this is like

19:41 something that people do all the time. In the type system of mypy, you can't specify the types of the

19:47 exceptions that come out of a function. And they have no plans to do it because typed exceptions in Java

19:52 were really a big problem.

19:54 Yeah. Yeah. They are challenging.

19:56 Very challenging. And C# didn't make that mistake, like doesn't have checked exceptions.

19:59 So I think what it means for Python programmers is that once three, six and mypy become more common,

20:05 I think that that idiom of raising an exception and expecting it to be caught is going to go away.

20:12 And I think people are going to do it more like go programming where you return like a tuple of

20:15 it's okay and here's the result or it's not okay and here's the error.

20:19 Yeah, sure, sure. Result comma error in some kind of tuple and you just look at one or the other. Yeah.

20:24 Yeah. And they support optional types in mypy so they can actually enforce typing on the variations,

20:29 which is really cool. Like they have kind of like what Swift can do. They can do that in mypy already.

20:34 So this talk to me was like a sneak peek of what Python will be written like in three years,

20:39 essentially.

20:40 That's a cool analysis.

20:41 Yeah.

20:41 What I was sort of seeing when I was looking at this was part of the overall trend towards Python 3.

20:47 Oh, yeah, definitely.

20:48 Yeah. And, you know, when Guido was on the show, I think he mentioned even that

20:52 this will provide some foundation for helping them move to Python 3 at Dropbox.

20:59 Oh, yeah.

20:59 They can reason more carefully about the code and decide if it's going to be a problem

21:03 at some sort of conversion.

21:05 Yeah, exactly. Yeah, I think that's definitely the case. And there are already 700,000 lines in.

21:09 So I think it was probably the first 100,000 that was the hard part. I'm looking forward to an update

21:14 once they, you know, say that they're totally done or whatever.

21:17 Yeah, it'll be pretty awesome.

21:18 Yeah.

21:19 Hey, everyone. Michael here. Let me take just a moment and thank one of our sponsors who makes

21:23 this show possible. This portion of Talk Python to Me has been brought to you by Rollbar.

21:27 One of the frustrating things about being a developer is dealing with errors.

21:31 Relying on users to report errors, digging through log files, trying to debug them,

21:36 or a million alerts just flooding your inbox and ruining your day.

21:38 With Rollbar's full stack error monitoring, you get the context, insight and control you need to

21:44 find and fix bugs faster. Adding the Rollbar Python SDK is just as easy as pip install Rollbar.

21:50 You can start tracking production errors and deployments in eight minutes or less.

21:54 Rollbar works with all the major languages and frameworks, including the Python ones like Django,

21:59 Flask, Pyramid, as well as Ruby, .NET, Node, iOS, and Android. You can integrate Rollbar into your

22:05 existing workflow. Send error alerts to Slack or HipChat or automatically create new JIRA issues,

22:10 pivotal tracker issues, and a lot more. They have a special offer for Talk Python To Me listeners.

22:15 Visit talkpython.fm/Rollbar, sign up and get the bootstrap plan free for 90 days.

22:20 That's 100,000 errors tracked for free. But you know, just between you and me,

22:24 I hope you don't encounter that many errors. Give Rollbar a try today. Just go to talkpython.fm

22:30 slash Rollbar. So let's talk about the gillectomy. Yeah. So this is Larry Hastings talk,

22:37 and he's been at it for a couple of years. And first of all, let me just like take a step back

22:43 and maybe tell us what the GIL is. And do you think the GIL is actually a problem for Python?

22:47 Wow. Okay. Okay. So the gill, yeah, the global interpreter lock, which is the part of the

22:51 CPython interpreter that locks the state machine state while your program is running so that

22:57 different threads don't trash each other. It's a key part of how CPython works, how CPython's virtual

23:03 machine works. And it has unintended consequences, which are that it prevents your Python program from

23:10 using multiple cores at the same time. So it limits the actual execution speed of Python,

23:16 vanilla Python.

23:17 Right. Basically only for computational stuff.

23:19 Only for computational stuff. Yeah.

23:21 When you are waiting on the OS, like for network or file, it releases the gill, right?

23:26 Yeah, it does. And so for IO bound applications, or memory bound applications, it's not a big deal. But for

23:33 CP bound stuff, especially servers where they're trying to be really high, like highly responsive,

23:38 that can be a problem. So yeah, to answer your question, is it a problem? Well, depends on who you ask.

23:42 Like, in the JavaScript community, v8 is not multi threaded in the same way. It's completely single core for similar reasons.

23:50 Which means node is in a similar situation, right?

23:53 Yeah.

23:53 But you don't really hear people complaining about that with node, because it's really all they can use.

23:58 And then things like Go are, you know, are highly concurrent, super fast. And so I think Python's limiting itself by not being able to use all CPUs out of the box. There are tools like multiprocessing, the multiprocessing module for Python that do let you take advantage of all CPUs. It's just, it's just hard to use if you don't know what you're doing.

24:15 I don't think it's that huge a problem. I think the thing that's sort of relieved the pressure is there, when you really are doing a lot of computation, often there's some library and some bit of it is in C, and it really does take advantage of it, like NumPy or something, right?

24:28 So yeah, the really intense cases seem to have already worked around it, and you just pip install a thing and you're okay.

24:35 Yeah, but even in those cases, like NumPy and other packages like this, it's like, you need to restructure your program to take advantage of it. And I think that's the burden. It's, this was working, why can't I just turn up the speed dial and have it go faster, or increase the concurrency, you know, where you can do that with some other languages or other constructs. So yeah, I think most people, it doesn't matter. But I think certain areas, it does. And so I'm happy that they're spending time on it. And Larry's been diving into it.

25:01 Yeah. Okay, so that brings us to the Gilectomy.

25:03 Yeah. So yeah, he's been talking about it for a couple years now. And he's, he's trying to remove the GIL or at least remove the, the overhead of the GIL. And it's been tried a few times. If you look back at his older talks, I think there's an attempt at it. The original attempt at it was by Greg Stein, who I actually used to work with at Google. And he had added multi course, multi threaded support to Python, I think version, maybe it's version one five or version two, way back when. And it was insanely slow. It was like, awful.

25:33 And so yeah, anyway, so Larry's got a very particular style of presenting, which is, which is funny and very intense. But yeah, he just right off the bat, he's like, yeah, you know, Python without the gill, you can take the GIL out very quickly. It's actually not too hard. The problem is that it's really slow. It's 19 times, the one with the gills 19 times faster than the one without it, right?

25:51 Exactly. So yeah, you can do this. But before you see any advantage, you're going to need like 32 cores and really highly concurrent algorithms.

25:58 Yeah, exactly. You know, Larry is the guy who knows this stuff. So it's been interesting, because he is taking, you know, everything he knows, every trick in the book, essentially, and applying them to this GIL problem.

26:12 Yeah, so he, you know, in this talk, he walked through a lot of those. And, you know, we can talk about a couple of those examples. It started off just seeming hopeless, like he has no chance. And the graphs he was showing was the amount of CPU time that it takes to run a bunch of benchmarks, or maybe the Fibonacci benchmark. And it just looked hopeless. And all of his work was hopeless.

26:28 And so about halfway through the talk, I'm like, Oh, man, this is like, he's like, totally failed on this attempt, you know, but well, I won't give away the end. Okay, because we can talk about the end in just a second. But there's a bunch of techniques, though, that he used. I don't know if you remember any.

26:42 Yeah, well, I think what was interesting about this was he did lay out a lot of the different techniques and things that he had tried over over time, and really pulled out a lot of the challenges and trade offs that you have to make. And so it's like, I want the Gilgon, I want to just like, take advantage of all the CPUs.

26:58 Well, here are the trade offs. And here's where things actually get slower. And so there was stuff around garbage collection and managing reference counting and consistency there, the different types of locking that he had used, and just some of the allocation stuff. And yeah, it was, it was interesting.

27:14 Yeah, and there's a lot of reference. That's exactly right. And there's a lot of references of things that I like need to look up after that, like, some two stage locking stuff, getting rid of like accelerating thread local variables. There's something about, there's a book called the garbage collection handbook that I like, I was like, Oh, wow, I've heard of that has an algorithm called buffered reference counting, which I guess was the was the way that they he was able to make it fast.

27:36 So it's just really interesting to see how much it takes to do it correctly. But how it's actually all very well known algorithms in computer science research, and there's papers on basically everything that he's trying to do. So he's not actually treading new ground, which is really encouraging, because it's just about applying it to the Python space. He's not inventing some new technology that needs to be proven, and might be full of bugs. He's like, Oh, no, this is in the handbook.

28:02 He also invented it independently. But he's like, Oh, no, this is this is actually a known technique that I'm using. So even when he did invent something, it just was like a reinvention of the thing that existed, right?

28:12 Yeah, like from the 1977 or whatever it was. Yeah, that's always how it is.

28:16 It's definitely how it is.

28:17 Yeah. But ultimately, the last graph he showed was that it's really close now. I'm shocked because I did not think it was going to be possible. And you know, he's within, I think, maybe two x or less of slowness.

28:30 Wow.

29:00 You know, you can imagine that Python two seven goes away, because Python three, three has no gill, and it's super fast, or Python three has no GIL and super fast. And people like, wow, why would I use Python two, and I could use Python three, and run a lot faster.

29:12 Yeah, so this is actually an interesting point. I don't believe the galectomy came from these origins. But, you know, the next thing that we're going to talk about, I think, more or less did. And Brett Cannon, and Dino Veland are working on you started working on this thing called pigeon pigeon pigeon pigeon pigeon pigeon pigeon pigeon pigeon.

29:30 Basically, there's a couple of folks in the core developer saying, what can we do to improve adoption of Python three?

29:36 Right.

29:37 What if we made it 50% faster, right? That alone, if nothing else happened, that alone would make a huge difference.

29:44 And I think actually, regardless of whether it's been faster or not, the last two years have made like a huge shift towards Python three.

29:52 Yeah.

29:53 But the next talk that we're going to talk about by Victor Stinner was really highlighting some of the performance improvements that he and some other folks have done on Python three.

30:03 Yeah, definitely.

30:03 I really like this talk.

30:05 And I thought, you know, Victor's a really solid member of the Python core developer community.

30:10 And I really like this talk because it was very scientific in its presentation.

30:14 It was like, okay, here's, here's how we did the measurements.

30:17 It started off just with that.

30:18 You know, this is like, right.

30:20 As you say, it like actually started out with the measurements we've been using are unreliable.

30:26 First thing before we even start this process is we have to fix the measurements, right?

30:29 Yeah.

30:30 Yeah.

30:30 You can't even trust the numbers we used in the past.

30:33 So speed.python.com, which has all the benchmarks on it is like not something we should have been judging ourselves by in the past.

30:40 Yeah.

30:40 So that was, that was great.

30:41 Right.

30:42 And part of that isn't even just like, hey, we were bad at like running this code, but modern CPU architectures have things like turbo boosting and the speed at which your processor might run at could vary by like two or three X depending on how it's trying to save energy at the time and all sorts of stuff.

30:58 Right.

30:58 Yeah.

30:58 And that came up, that actually came up in a few different talks, including the Gilectomy one, another one I went to where people are trying to benchmark things and there's no good way to like disable all of the magic features that are in modern Intel CPUs or even ARM CPUs.

31:13 And so I think that there's actually a module that they're putting together.

31:17 That's like the standard benchmarking module that turns off all of this stuff automatically.

31:22 I actually don't remember what the, what it was called.

31:23 It was like perf or performance or something.

31:25 I think Victor Stenner had worked on it.

31:27 Yeah.

31:27 Yeah.

31:28 So that's great.

31:28 So I think if you're doing any benchmarking of any kind, you know, it's worth picking that module up and using it for your purposes.

31:34 So you can make sure that you're actually comparing stable numbers over time.

31:37 Yeah.

31:37 So then he talked about, I didn't count him exactly, but just something like 10 major, major improvements on Python 3.5 and 3.6 where he focused.

31:47 Yeah.

31:47 And there's, I mean, there's so many of them.

31:49 It's getting into the weeds with some of the stuff, but one of the ones was, one thing is like, it's no longer actually called Python bytecode.

31:56 That was one I liked.

31:57 So Python doesn't have bytecode anymore.

31:59 It has something called word code because bytes only one byte where a word is like 16 bits or, you know, it's multiple bytes.

32:05 Yeah.

32:06 And so there's some inner loop in the CPython runtime that had an if statement, which is like, okay, is this bytecode, does it have any arguments?

32:13 Because if it does, then it's more than one byte.

32:16 And they just said, you know what, let's just get rid of that and just have it be two bytes always because memory performance on, you know, modern machines is good enough that we don't need to actually save space.

32:25 Yeah.

32:25 And they basically removed a conditional check in C eval.c, which is like the switch statement.

32:33 Yeah.

32:33 Yeah.

32:33 The hot loop.

32:34 Yeah.

32:34 That's the super hot loop.

32:35 And so simple things like that, like maybe we'll just throw in like a wasted byte when there's no arguments and that will actually make it a little bit less memory efficient, like tiny, but much faster.

32:47 Yeah.

32:48 Yeah.

32:48 Yeah.

32:48 Exactly.

32:49 And so it ends up like netting, I don't remember what the performance boost, but there's a bunch of these that improve benchmarks by, you know, 5%, 10%, 20%.

32:57 And that stuff really adds up.

32:58 So it's really, they've done a lot.

33:01 And so Python 3.6 is extremely fast compared to others.

33:04 It's amazing to see that that progress.

33:06 Yeah.

33:06 So I would definitely say, especially if you're on Python 2 still and you're like, is it really worth switching?

33:11 You know, I get this language feature.

33:13 Sure.

33:13 I can do double star to create dictionaries out of other dictionaries and whatever, but is that really worth it?

33:18 Like check out this optimization talk because there's a lot of stuff where it's like, and this is 40% faster and this is two times faster and this is 12% faster.

33:26 And it's just like, whoa.

33:27 Yeah, definitely.

33:28 And like the decimal module, for example, that one is actually just rewritten in C, but I think it was 40, 40 times faster.

33:33 Yeah.

33:33 40 times faster.

33:34 Which is like, I've used decimal all the time.

33:36 So that would be helpful for, you know, what I've done.

33:38 He also alluded to something that will be in Python 3.7.

33:40 He didn't really want to go into it yet because he says the results aren't perfect or fully proven.

33:45 But he did say that in Python 3.7 that method calls are going to be faster across the board.

33:51 And, you know, that's my biggest problem I would say with Python is that calling a function is really slow.

33:56 Yeah.

33:57 That's a really good point.

33:58 Like you are at odds with performance with structuring your code well.

34:03 Exactly.

34:03 And so especially with the optimizing code, you're like, well, this is really hard to understand.

34:08 So I'm going to split this into functions so I can like follow it.

34:10 And as soon as you start doing that in Python, like you're slowing your program down every single time.

34:15 And that's not a tradeoff you want to make.

34:17 You know, that's terrible.

34:18 And so anything you can do to make function calls faster, they already, he already talked about a few of those.

34:23 And he said there's more coming in 3.7.

34:24 So I just, I think it's maybe a, the beginning of this performance renaissance in Python.

34:28 Yeah.

34:29 That I'm really looking forward to the Gilectomy being part of that as well.

34:32 But just, you know, meat and potatoes optimization, which is what Victor's doing.

34:36 It's just really great to see.

34:37 Yeah.

34:37 Really, really amazing stuff.

34:39 And some of the stuff that struck me was like how simple the changes were, but how careful you have to be in making them because of the edge cases.

34:47 It's like, here's a simple optimization, but it took us two and a half years because it was incredibly difficult.

34:53 To get every edge case just right.

34:54 Yeah.

34:55 Yeah.

34:55 Totally.

34:55 Yeah.

34:56 And that's, that's why it's like a darker, you know, you really need to know what you're doing to optimize and you need really good tests.

35:01 I think the case you're talking about is they rewrote LRU cache algorithm.

35:04 And yeah, it took them like two.

35:05 Yes.

35:05 That was the one I think.

35:06 Yeah.

35:06 Two and a half years.

35:07 Yeah.

35:08 It's pretty, pretty crazy.

35:09 Yeah.

35:11 That's pretty amazing.

35:12 All right.

35:12 So one that I did not see, but you went to, maybe you can tell us about is the debugger one.

35:16 Yeah.

35:17 So this is by Elizaveta Shashkova from JetBrains, I think in St. Petersburg.

35:24 And this one was really cool.

35:25 So it's cool because there's this PEP called PEP 523 and it's a Python enhancement proposal.

35:32 And it's a, the purpose of the PEP is to give a pigeon, which you were just talking about,

35:38 which is a JIT compiler, a just in time compiler for Python to make Python faster.

35:43 That's what the PEP was for.

35:44 It added a bunch of hooks into the C, CPython runtime that lets you change the way that functions

35:51 and code are evaled.

35:52 Okay.

35:53 So you can plug in new stuff.

35:54 Yeah.

35:54 The big idea is like, let's not keep rewriting new runtimes.

35:58 Let's try to find a way that you can plug into the one that we all have without forcing everyone

36:03 to go, should I do PyPy?

36:04 Should I do JIT?

36:05 Should I do IronPython?

36:06 Like, forget this, right?

36:07 Yeah, exactly.

36:08 And so make it more extensible.

36:10 So that's really cool that that PEP was created and has been plugged into Python.

36:15 I think it might be 3.5 that it landed.

36:17 But what they didn't realize when they developed this PEP is it would enable new use cases.

36:22 And so Eliza, what she went through is how they actually leverage that same interface to

36:29 enable a debugger for Python that is as fast or almost as fast as just vanilla Python.

36:36 And so if you've ever run your Python code under a debugger, it's something like 30 times slower.

36:41 Oh, interesting.

36:42 And so it's really hard to actually simulate a lot of the problems you have.

36:45 Or if you have timing issues, especially where there's races, you just can't even reproduce

36:49 them because it's so slow.

36:50 Everything runs in the right order under the debugger.

36:53 And then once you run it normally, then it goes fast enough.

36:57 And then you get these data races again.

36:58 And then you can't.

36:59 Then you get the bugs.

37:00 Yeah.

37:00 Yeah.

37:01 Heisenbugs.

37:01 Heisenbugs.

37:02 Right.

37:02 And so they created this thing into JetBrains.

37:05 And I think it's I think the core of its open source, where it basically uses the PEP523

37:12 hooks that are meant to be for speedy eval.

37:14 And it'll actually rewrite the Python bytecode or wordcode in as it's coming through and insert

37:20 breakpoints into the bytecode, which makes it, you know, orders of magnitude faster because

37:25 the old Python debugger uses it's a set trace where you get a function call for every single

37:31 line of Python.

37:32 It's almost like a profiler.

37:33 Yeah, exactly.

37:34 And it's the slowest thing imaginable.

37:36 You know, it's first of all, you're calling a function, which is slow.

37:39 Right.

37:40 And then you do it for every single line, whether or not you want you care about that line.

37:44 So I love this talk because she walked through all the how the debuggers work, all the details

37:48 about why they're slow benchmarks are on that.

37:51 Then she explained her approach, how they do it, what it's good at, how it works.

37:55 She even showed the disassembly of the Python bytecode and how they plug into it.

37:59 So it was really awesome.

38:01 Yeah, that's cool.

38:01 I'm definitely going to have to check this one out.

38:02 Yeah, I would.

38:03 And my favorite part about it is just like that PEP defined an interface that is generally

38:09 useful to people.

38:11 So it wasn't intended to be used for this purpose, but it was general enough that it could be.

38:17 And that's good design from my perspective.

38:20 Yeah, it's really nice that, you know, that wasn't even part of the plan, right?

38:25 But just this flexing and growing CPython actually made this other use case really good.

38:31 Yeah, definitely.

38:32 So I'm looking forward to using that debugger.

38:33 And I keep hearing great things about PyCharm.

38:35 And I've never actually used it for anything like day to day.

38:38 I poked around with it, but never built a whole program with it.

38:42 Yeah, I don't know if this is the same thing.

38:43 But when you debug something in PyCharm, if you just do that on like a brand new machine,

38:49 it'll say warning the debugger speedups are not built.

38:52 You basically have to run this compiler statement to like build something into your system.

38:58 Oh, yeah.

38:59 That might be the same thing.

39:00 Yeah.

39:00 I think that might be it actually.

39:01 Yeah.

39:02 So there's like a little output that it says, hey, you can make this much faster if you run this line once.

39:06 Gotcha.

39:06 Yeah, no, I didn't know about that.

39:08 This portion of Talk Python to Me is brought to you by CodeChip.

39:12 Try CodeChip Basic, a free, simple, out-of-the-box, continuous integration service in the cloud.

39:18 Thousands of customers use CodeChip Basic every day.

39:21 Its pre-installed CI dependencies make testing your software and deploying it work out-of-the-box.

39:26 The average setup time for CodeChip Basic is less than three minutes.

39:31 CodeChip Basic comes with a free plan that grants 100 builds per month, unlimited projects, and unlimited users.

39:38 Do you run an open source project?

39:40 Those are always free on CodeChip.

39:42 And they just improved their Python support.

39:44 So give CodeChip a try and visit talkpython.fm/CodeChip to learn more and sign up for free.

39:51 That's talkpython.fm/CodeChip.

39:54 So one of the things that I thought was really neat, you know, I think there's a lot of things touching on this.

40:00 It's like, hey, this Python 3 stuff is becoming really amazing.

40:03 And maybe the pinnacle of that was the Instagram keynote.

40:08 Yeah.

40:09 And this is a great talk.

40:10 It was kind of two parts.

40:11 I think Lisa Guo was the one who talked mostly about the actual transition.

40:17 But it was, yeah, how they moved from Python, you know, Python 2 to Python 3 while not having any downtime.

40:24 Oh, yeah.

40:25 I watched this talk and I thought, okay, there's almost no other company out there.

40:29 I mean, maybe a handful, but almost anyone else that says, well, we can't switch to Python 3 because we have a large code base.

40:36 We have a lot of users.

40:37 We've got to keep shipping.

40:38 Like what Instagram did was really quite incredible.

40:44 The first thing that I sort of thought, okay, this is going to get really interesting is they just have one branch that they develop from, right?

40:52 They don't just like, it's not like they said, well, let's just fork everything and go over there for six months and work on that.

40:58 Yeah, and that's a recipe for disaster, I think.

41:00 And I actually work in a monorepo with a single trunk as well.

41:04 I've been doing that for years, which is kind of odd for many people.

41:08 And it's a great way to develop, but it does make it challenging to do large refactorings like this where you're changing style all over the place.

41:16 I want to do it all at the same time without breaking people or making sure that commits keep flowing through.

41:21 So just in terms of process and collaboration with a large team of people, I don't remember how many engineers they have working there, but it's hard.

41:29 Yeah, but there are many, yeah, quite a few.

41:30 So their goals were, we're not going to branch.

41:33 We're going to take our existing code, which is Python 2.7 running Django 1.3, which is five versions out of date.

41:39 Yeah.

41:40 And we're going to move that to Python 3 and the latest version of Django.

41:44 I suspect that Django switching and Django 2 saying like, we're not going to support Python 2 anymore.

41:51 So we're just done.

41:52 They're like, we're kind of painting ourselves into permanently into a somewhat of an old version.

41:56 Let's see if we can like, you know, get back on track.

41:59 Yeah.

41:59 And that was the incentive there.

42:01 Yeah.

42:01 I thought that was, you know, there's been this push to get all the libraries into Python 3, which has really made a lot of progress over the last, let's say, five years.

42:07 And now it's, you know, it's almost there for all the major ones.

42:10 And this is example, this is an example of the dividends that that's paid off because now Python Django 2 is like, yeah, we're not going to support these older versions.

42:18 And then Instagram's like, well, we really like that open source project and we collaborate, you know, we work on that.

42:23 And so they're incentivized to move.

42:25 And she also mentioned that Python 3.6 is just faster, which is, so those are two proof points that this strategy that Python's had more recently, maybe they should have had earlier, that would have helped the transition to happen faster.

42:37 But this more recent strategy of performance in libraries is starting to actually be enough of a carrot and a stick to get people to start converting at a large scale.

42:47 Yeah, it's really, really interesting.

42:48 I totally agree with you.

42:49 So they said, we're going to try to continue to ship new features.

42:53 We're going to check into this one branch.

42:55 We're not going to branch it.

42:56 We're going to have a very careful rollout of Python 3.

43:02 I thought that was actually really interesting as well.

43:05 Both the test, how they did the testing by saying, we're going to slowly say, these are the tests that pass and we'll like eat our way back into all the tests until they basically all pass again.

43:16 And the way of staging the rollout as well was interesting.

43:20 And they were basically maintaining a Python 2 and 3 code base, like one that could run under either runtime at the same time.

43:26 So that's kind of how they started this and what gave them the ability to make those more tactical moves in production.

43:33 They ran the tests, all the tests under 3 and 2 using a whitelist or an exclusion list, inclusion and exclusion lists.

43:41 And then they basically just started moving test after test across and setting up some best practices and all that kind of stuff.

43:48 And yeah.

43:49 Yeah, I really like this, that it was very prescriptive.

43:51 These are the steps you need to take.

43:53 Do it this way, this way.

43:54 And then like it was really a roadmap, not just a, hey, look, we did it.

43:58 Yeah, definitely.

43:59 Like if you work somewhere and you want to be able to explain to your boss, like, oh, this is, this is what we need to do and how we need to do it.

44:05 Like this is just have them watch this video because it's really, definitely.

44:09 It's really convincing.

44:10 And it has a bunch of best practices for teams.

44:13 And it even has some like nuggets that are really valuable.

44:16 Like one I thought was really cool was they talked about they rely on memcache so heavily.

44:22 And there's this issue between version two and version three of memcache where, oh, sorry, version two and version three of Python where the pickle module becomes, it can poison the other version.

44:33 I don't know if you remember seeing this.

44:34 Right.

44:34 They're basically, yeah, they're basically incompatible with like their serialization format and various things.

44:39 Yeah.

44:39 Yeah.

44:39 So it was really interesting because I've actually had this problem in production many times.

44:44 Even if you don't change the version of Python, you can cause memcache poisoning where you have a pickle version of the object and you've somehow slightly changed the structure of the object.

44:52 And now if you have two different versions of your app accessing memcache at the same time, but they both have different definitions of the object, they'll actually start poisoning each other and you'll cause just total runtime failures.

45:04 And the only solution, even if you flush the cache, it doesn't work because the old version will start writing it stuff into the cache.

45:11 The new version will start writing it stuff.

45:13 So there's, once you get into this loop of death, it's like, there's nothing you can do.

45:17 It's really scary.

45:18 Yeah.

45:18 So they started, they started partitioning their memcache keys to make sure that they wouldn't interact.

45:23 I'm envisioning them putting like PY3 or PY2 in front of every key name or something.

45:29 Exactly.

45:30 And that's really an amazing best practice.

45:32 It seems so obvious when you hear about it, but like, I think that that's something that, you know, even if you're just doing rollouts of deployments or, you know, you have new Docker images that are holding your app in them, that's actually a great strategy.

45:43 Just to reduce the amount of incompatibilities between the runtime, the, you know, runtime versions you have going on.

45:48 Right.

45:49 Maybe even like your app version or something, right?

45:51 It could even be, be that much, but it could be your code change, not Python's internal change.

45:56 Yeah.

45:56 That's, that's what I'm trying to say.

45:57 Yeah.

45:58 Between your own code versions, you know, your commit hash, you could use as a, as a prefix.

46:02 I think that's a really cool best practice.

46:04 Yeah.

46:04 Cool.

46:04 Yeah.

46:05 So I really liked this.

46:06 And in the end, they, I guess I could talk about the rollout really quick.

46:11 That was interesting.

46:11 They said, okay, first thing we're going to do is we're just going to run the tests on Python three as well.

46:17 And we'll start to slowly work that up.

46:18 And then we're going to switch all the dev environments to run Python three, but still ship to do continuous integration and ship to Python two.

46:27 And then once we get all the dev environments working and we stop hitting bugs, we're going to switch to just the employees of Facebook.

46:34 And then 0.1% of the users and then like 20%.

46:37 And then, and so they, they had this really structured rollout and they said, but by the time we got done with the internal use cases, we were like, there's barely anything left to do.

46:45 Yeah, definitely.

46:46 So that's, that's just really conservative.

46:48 Well done.

46:50 And I'd say just, you know, you have to have everyone on board though, that it takes time.

46:53 It's going to take a lot of resources.

46:55 You need to dedicate a team is not doing anything else.

46:57 And yeah, so I, I, I think it's a model that we should all follow.

47:01 Yep.

47:02 And in the end they said, look, there's these different parts of our code.

47:05 We run Python and Django and micro WSGI.

47:07 We run our async stuff like notifications and celery.

47:11 And we got a 40% performance improvement in, in celery, in the async area.

47:16 And we got a 12% performance memory speed improvement in the, the web front end, which there's like something you could take to your, your company, to your executives and say, look how much we're paying for all of these servers we got to maintain.

47:31 Right.

47:32 Look how much better it'll be.

47:33 Yeah.

47:33 I mean, it just, it just translated straight to like a financial savings and number of machine capacity, you know, that you could get out of it.

47:39 And that's, that's another just amazing kind of convincing argument.

47:43 So it's just, you know, you have speed and you have efficiency and then you have the cost savings.

47:48 So it's, it's great.

47:48 Yep.

47:49 It's great.

47:49 So we started this whole discussion of, by thinking of satellites that look out into space.

47:54 But the next one you went to is about satellites looking in towards the world.

47:58 Yeah.

47:59 So this is a, this is by Catherine Scott and she, she wrote the book on open CB for Python.

48:04 She's been in Python community for a while doing a lot of stuff like robots and computer vision.

48:09 And I think she recently joined a company called planet, which is a satellite imagery company that lets you buy satellite imagery and also let you get access to it for free under a bunch of circumstances.

48:21 And that was a big part of the pitch of this talk was kind of showing you that, that API and for academic research and all these other purposes, how you get access to it.

48:30 So it's more accessible than I've ever knew that you could, you know, you can say like, Hey, this lat lawn, like, can you give me every image of it, you know, for the last number of years?

48:40 And they can actually, you can actually pull that up through an API now, which is just totally bonkers.

48:44 You know, that's really cool.

48:45 And you could actually see how it changes over time, maybe.

48:47 Yeah. And, you know, and, and for her, you know, she mentioned it was, it was kind of like an aside, but for her, it was also like something that she thought was politically important or, you know, deforestation of the rainforest and like all these other kinds of things like that.

48:58 She thought it was useful for, but also just like plain old science, understanding ecology and urban analysis, but urban environments from space and just all kinds of GIS kind of use cases.

49:09 So it was really cool to see her work, work through a bunch of those, those examples.

49:13 Oh yeah. That sounds, that sounds really interesting.

49:16 Another one controlling things or even more so was the factory automation one, right?

49:21 Who I think actually they used to work together, Catherine and Jonas, I don't actually know that, but he works at Tempo Automation, which is a pick and place robot company in San Francisco.

49:30 And so they do a lot of crazy things, factories.

49:32 I love this talk.

49:34 It was really fun because he had a live demo for the entire thing.

49:37 And I'm pretty sure that the video captures some of that.

49:41 I don't know if you remember seeing that, but he had this conveyor belt contraption set up there and had a conveyor belt and had two pusher pads and he had some gum, like chewing gum.

49:50 And he's like, we're going to build a robot that will sort this gum into bubble gum and, you know, and spearmint gum based on the color of the package and a barcode.

49:58 Oh, that's cool.

49:59 Yeah.

50:00 And so then he walks you through.

50:02 Okay.

50:02 In Python, there's actually a PI serial library that will interface with a serial port and the serial port is a micro scanner for barcode.

50:08 And, and so he just like walked you through just from the beginning, like, okay, here's how you can scan a barcode.

50:14 Here's how you can actuate a little paddle, like in a pinball machine.

50:18 Here's how you can turn on a conveyor belt.

50:20 There's all this stuff I never, I know it's in there.

50:23 I've seen stuff on TV or whatever about factories and conveyor belts and factories, but he just went through like how it all actually works together.

50:31 And you can do it all from Python.

50:33 There's great libraries for it.

50:35 And it seemed really easy.

50:36 So it's like, that's one of the best talks where you're like, oh, I could totally do this, you know?

50:40 Yeah.

50:40 Made it entirely accessible, right?

50:42 Yeah.

50:42 Totally accessible.

50:43 Excellent.

50:43 Yeah.

50:44 That's great.

50:44 Yeah.

50:45 I really think the internet of things and these little devices, we're just at the beginning.

50:49 There'll be really cool stuff we can do with it.

50:50 Yeah, definitely.

50:51 And I think it also makes you realize that the internet of things, you know, we talk about it mostly for consumers and the little devices in our houses.

50:59 But in the factory, these devices are actually much more impactful.

51:03 And so you have sensors on control, you know, on conveyor belts or factory floors or the actual, like, not the supply chain, but the Henry Ford thing that's escaping me right now.

51:13 Assembly line?

51:13 Assembly line.

51:14 Thank you.

51:14 Yeah.

51:15 And so I think, you know, he just showed all of the things you need in order to do that.

51:19 So it's awesome that it's available over the internet, but it's also really scary because you're like, wow, if someone got access to that thing over the internet, they could, you know, cause a conveyor belt.

51:27 Like, yeah, I love Lucy style to be like running at a million miles an hour.

51:30 Yeah.

51:31 So I thought that was pretty funny just seeing into that as well.

51:35 Yeah.

51:36 That's neat.

51:36 Yeah.

51:37 All right.

51:37 The last one I thought was really pretty inspiring by Marietta.

51:41 Yeah.

51:42 Called Dial M for Mentor.

51:43 Right.

51:44 She's the first female Python core developer who's landed a commit into Python, you know, 20 some odd years after Python started.

51:51 So it's just really great that the Python community has been able to, we had a couple years ago, Hey, we need to really diversify the people who are committing to the core, sent out the call.

52:02 They tried to mentor people.

52:03 And he repeatedly said that we need to have more different types of people committing to Python.

52:07 And so she is, she is the first committer, female committer to Python and to the core.

52:14 To me, this talk was a lot about the kind of journey of mentorship of what it takes to, to, to, to make a contribution like that for someone where it might seem really scary.

52:22 Yeah, absolutely.

52:23 I mean, really the part where she talks about being a core developer, that's not until like the last five minutes.

52:28 It's until then is like, here's all the ways that I was frustrated becoming a developer.

52:33 Here's all the ways I got stuck.

52:35 And I felt inadequate and I felt like this was not for me and how I either kept myself going or I got help from someone.

52:42 And, you know, on the core developer side, I think Guido actually was her mentor to help her make her way through to actually, you know, getting stuff working.

52:52 Yeah.

52:53 At the code level in CPython, which is cool.

52:55 Yeah.

52:55 It's cool.

52:56 And I think that she explained a lot of her fears and the common kind of issues that people have when they're like need mentorship, but are too afraid to ask for it or have a hard time finding it.

53:05 And so it's a good wake up call for, I think people just in general, but in the Python community, especially to realize that we need to structure mentorship better and have a more active approach to how we do it.

53:16 And I've heard, you know, DjangoCon actually has a mentorship program for talks there where they will pair people who have never given a talk, but have thought about it with people who have given many talks to try to help them, you know, work through their slides.

53:28 Practice.

53:29 Yeah.

53:30 And I don't know if they're actually doing this for PyCon itself yet, but they do it for DjangoCon.

53:34 And I think that's an awesome model.

53:35 And I really hope that they, they should just do that for all of the regional PyCons and all of the, you know, all of those kind of meetup groups, just because that's, that's how you build confidence in young people or, or, or people who are approaching Python from different backgrounds.

53:49 And I think that's really critical.

53:50 So I think that her talk is a great way to kind of focus on what this meant, what these mentors should be doing and what, you know, how they need to make people feel comfortable seeking out mentorship.

54:01 Yeah. I think if you're in your first five years of programming, this will be really helpful for you looking for mentorship and finding your way and feeling confident.

54:11 And I think if you've been programmed for a really long time, this will help remind you what it's like for people coming into the modern environment and maybe how you can help.

54:20 Yeah, definitely. And I've been on both sides of that, you know, I remember like needing mentorship way back when, and I also, and now I do mentor people, but I, I would mentor more if I had a better way of connecting to people who need it.

54:31 You know, and there's a couple of ways she calls out that people can do that, which is great for people to volunteer.

54:36 And I hope that more kind of come up in the Python community so that the mentor, the, the people doing the mentoring also more of them volunteer and really make a point of taking the time to do it.

54:46 Yeah. It was a great talk. So let's leave it with that, huh?

54:49 Yeah.

54:50 For the ones that we went to, maybe I can ask you real quick, just, are there some other ones you're like, this is on my to watch list, but I didn't make it to it.

54:57 Yeah. Raymond Hettinger always has a talk, not always, but usually, and it's always great. And so he had one on dictionaries that I didn't get to see, but I heard was awesome.

55:05 Yeah. I don't know if it was this particular talk, but one of his talks was basically sold out. Like they closed the door and said, you can't come in. Like we're at the limit for fire code in this room.

55:14 Yeah. That's usually what happens fire code. Yes. I was like, if people are new to Python, I'm like, well, you should probably go to this talk and get there like early. Yes. I, and I don't go to the, I'll watch that talk later, you know?

55:23 And then Brandon Rhodes, who was the chair of the conference. He also had a talk on dictionaries as well. I think it was different enough from the other ones. I'm looking forward to watching that one. He's a great speaker.

55:33 Yeah. That's, that's really good. And the last one was just Brett Cannon. He had a talk on what's new in Python three, six. It's just like an, a summary. And so you can read that online. If you just Google like what's new in Python three, six, you'll find it. But you know, hearing someone give the talk is a lot more interesting than reading through the notes. So I would definitely check that out.

55:49 I agree with you on that. I've read what it was in there and when it all came out, then I watched his talk and really the, this is here is what you get from reading the peps, but it's like, this is here. And this is the implication of what this being here means and whatnot. I think you just get a lot more appreciation for it.

56:06 Yeah. I agree.

56:07 All right. Excellent. So that was really, you know, it was fun, fun pike on, right?

56:12 Oh, it was great. Yeah. And next year it's in Cleveland. I think the next two years it's in Cleveland, Ohio. So that's going to be totally different. Change the scene.

56:18 Yeah. And I'm looking, looking forward to that and some great talks. So yeah, I'm looking forward to next year. And, and in the meantime, there's a bunch of regional Pycons coming, you know, Python conferences coming up. So that's another thing to just check out. Like if you, if you can't travel to one of these other places, you'd be surprised how many local Pycons there are across the United States and really across the world. So it's, it's worth checking those out.

56:37 Yeah, absolutely. I think they just announced PyCon Canada. And then there's also PyCascades, which is going to be in February. I think these are the PyCascades is brand new. And actually Marietta, the last person we spoke about,

56:48 was part of the organizer for that. Right. Yeah. Yeah. I think, I think it's for all the Pacific Northwest kind of area. Yeah. So definitely get out to one of these Pycons or multiple ones. If you're, if this sounds interesting to you, it's really a great time. Even if you don't go to the talks. Yeah, I agree. All right. Final two questions, Brett. Okay. If you're going to write the Python code, what editor do you use?

57:07 I'm still using Sublime Text. I'm on version three now. Yep. That's, it's still, still my, still my thing. And if I'm in a terminal, I still use Emacs. So that's my, I'm on that side of the debate.

57:17 All right. Very cool. And a notable PyPI package.

57:20 Wow. Recently, it's going to be what I can't live without. Right. I think it's been my go-to still. Yeah. If I'm doing web development, I'm going to install Flask every time, basically. So without a doubt. But I think if I'm actually just trying to do processing, it's, it's NumPy, which it's still the best thing that happened to Python.

57:40 All right. Yeah, for sure. It's very cool. I'll throw one more in there with mypy, just from the static typing talk.

57:47 I haven't used it enough to install it every time, but I think that's a great, that's actually something I should shoot for is that being my go-to.

57:53 Yeah. Yeah. That's very cool. Yeah. All right. So you actually have a playlist of this, right?

57:57 Oh, wow. I do. Yeah. I could share that. That's a good idea.

58:00 Yeah. If it's already, I'll just put it in the show notes. Sounds good.

58:02 And just subscribe to it and just go through. They can basically replay PyCon through your attendance.

58:08 Sounds good. Yeah. I think I'll add a couple more in there too. I think the lightning talks are worth checking out and, but that's great. Yeah, we should do that.

58:14 All right. Awesome. Brett, thanks for being on the show. It was excellent to talk with you.

58:17 Yeah. Thanks so much for having me. I had a really good time.

58:20 You bet. Bye.

58:20 This has been another episode of Talk Python to Me.

58:25 Today's guest has been Brett Slatkin, and this episode has been brought to you by Rollbar and Codeship.

58:31 Rollbar takes the pain out of errors.

58:34 They give you the context and insight you need to quickly locate and fix errors that might have gone unnoticed until your users complain, of course.

58:42 As Talk Python to Me listeners, track a ridiculous number of errors for free at rollbar.com slash Talk Python to Me.

58:49 Do you have software? Would you like to know if it has bugs before you deploy it?

58:54 Then jump over to talkpython.fm/Codeship and set up a free Codeship Basic account, Ship Tested Software.

59:01 Are you or your colleagues trying to learn Python?

59:04 Well, be sure to visit training.talkpython.fm.

59:07 We now have year-long course bundles and a couple of new classes released just this week.

59:13 Have a look around. I'm sure you'll find a class you'll enjoy.

59:16 Be sure to subscribe to the show.

59:18 Open your favorite podcatcher and search for Python.

59:20 We should be right at the top.

59:21 You can also find the iTunes feed at /itunes, Google Play feed at /play, and direct RSS feed at /rss on talkpython.fm.

59:31 Our theme music is Developers, Developers, Developers by Corey Smith, who goes by Smix.

59:36 Corey just recently started selling his tracks on iTunes, so I recommend you check it out at talkpython.fm/music.

59:43 You can browse his tracks he has for sale on iTunes and listen to the full-length version of the theme song.

59:48 This is your host, Michael Kennedy.

59:50 Thanks so much for listening. I really appreciate it.

59:52 Smix, let's get out of here.

59:55 Stay tuned. I'll see you next time.

01:00:16 Don't believe Thank you.