#116: 10 top talks of PyCon 2017 reviewed Transcript

00:00 Michael Kennedy: Even if you got to attend PyCon, there were just too many great talks to go and attend them all. Luckily, our friends at the PSF were on top of publishing the videos online for the whole world to watch for free. On this episode, we'll meet up with Brett Slatkin and replay his path through PyCon. We talk about his top 10 favorite sessions from PyCon 2017. This is Talk Python To Me, episode 116, recorded May 31, 2017. Welcome to Talk Python To Me, a weekly podcast on Python, the language, the libraries, the ecosystem and the personalities. This is your host, Michael Kennedy. Follow me on Twitter where I'm @MKennedy, keep up with the show and listen to past episodes at talkpython.fm and follow the show on Twitter via @talkpython. This episode is brought to you by Rollbar and Codeship. Be sure to check out what they're offering during their segments. It really helps support the show. Brett, welcome back to Talk Python.

01:21 Brett Slatkin: Thanks for havin' me.

01:22 Michael Kennedy: Yeah, it's always a pleasure. We had a really nice time last, almost two years ago on episode 25, and now we're back to talk about PyCon.

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

01:34 Michael Kennedy: Yeah, thanks, it really has been a long time. So we talked a little bit before PyCon about doing another show together and you had this great idea of like, hey, we're both going to PyCon. Let's do like a PyCon roundup and go through the talks mostly that you went to 'cause I was happily stuck in my booth talking to people so I didn't get to that many talks, but nonetheless, they're all on YouTube, so everyone listening can watch it even if they didn't go to PyCon, right?

02:00 Brett Slatkin: Yeah, definitely, and that's, you know, PyCon's a great conference for that reason is that on the second day we were there, they were already uploading talks from the first day, so you can even watch some of the talks you missed yesterday so that you can talk to other people about those talks while you're still at the conference, which is just really amazing that...

02:15 Michael Kennedy: Yeah, it's really amazing how quickly they come up and the quality, because going there really is a bit of a paradox of choice.

02:22 Brett Slatkin: Oh, yeah, and they actually set it up to be that way, like they'll put all of the best talks, quote unquote best from the speakers that are most well-known for the quality of their talks, they put them at the same time so you can't possibly go to all of the best, quote unquote best talks. You have to go and try different things out and see ones from new speakers with different fields of discipline, stuff like that, so that's a big part of the fun of being there and they're able to do that because they know they're all recorded so people don't feel like they're missing out.

02:50 Michael Kennedy: Yeah, they really do a nice job. So I'm definitely looking forward to talking about these eight or nine talks that we've picked out to discuss.

02:56 Brett Slatkin: Yeah.

02:58 Michael Kennedy: But before we do, maybe, you know, it's been almost two years since you've been on the show, maybe tell people what you do day to day with Python and things like that.

03:05 Brett Slatkin: Yeah, sounds good. So I'm a software engineer, still working at Google. I work on a product called Google Surveys. It's a research platform to answer questions, it's kind of market research and survey statistics. We can predict elections and that kind of stuff, and we use a lot of Python to do that. So it's hundreds of thousands of lines of Python, everything from Django-looking code on the front end down to NumPy and statistical functions and we also use a lot of JavaScript and Go and other things for other pieces of the system, but overall, the majority of our code is in Python.

03:36 Michael Kennedy: That sounds like a fun project to work on.

03:38 Brett Slatkin: Yeah, it's been great, I've been workin' on it for many years now, and it just keeps growing and it's been amazing to see Python grow from, you know, my first commit was 2000 lines of Python and to have that grow by 100 or 200 times, it's been really remarkable that the language kept working.

03:53 Michael Kennedy: It really does grow and stretch pretty well, it's awesome. We'll even talk about some examples in some of these talks.

03:59 Brett Slatkin: Definitely.

03:59 Michael Kennedy: For example, with Instagram, right?

04:00 Brett Slatkin: Yeah, yes, exactly.

04:01 Michael Kennedy: So also, maybe catch us up on your book. I originally got to know you through Effective Python, the book that you wrote a little bit before we had you on the show. I really liked it, so it's still selling or are you working on new books, anything like this?

04:14 Brett Slatkin: Yeah, a great question. So it ended up getting translated into a bunch of languages, it's doing well. It got translated into Chinese, both traditional and simplified, German, Polish, Korean, Portuguese, so it's been crazy to see, Japanese also, versions of the book all over the place and translations of the words, effective python, in all these other languages, so it's been doing really well, weird Tweets in other languages that I don't know and Translate doesn't really capture programming jargon very well, so it's interesting trying to find friends of mine who know these languages to help me understand what people are saying, but...

04:49 Michael Kennedy: Yeah, do the like the book or what? I can't tell.

04:52 Brett Slatkin: Yeah, 'cause it's like dry humor or like a joke about the cover not having a snake on it, like stuff that's really hard to get through automated translation, right.

05:01 Michael Kennedy: Yeah, yeah, absolutely.

05:02 Brett Slatkin: So I think I'm looking forward to, you know, everyone's watching the Python death clock, the Python 2.7 death clock of 2020 and so it'll be interesting to see, I think, if there's another, if it's good to have another edition of the book in time for that because so much is changing and people talk about that today. But no plans yet, I think it's still, the material's still good and it's up-to-date.

05:22 Michael Kennedy: Yeah, excellent. So if people wanna check that out, that was episode 25 from a couple years ago. All right, so, yeah, let's talk about the talks.

05:30 Brett Slatkin: Yeah.

05:30 Michael Kennedy: You went to PyCon, I went to PyCon. I didn't get a chance to go to that many talks and, honestly, I find the hallway track to be really quite, quite valuable. You make these connections and you can talk to people there that, you know, those aren't recorded and those won't be, you can't relive those, right?

05:48 Brett Slatkin: Yeah, definitely, and I think they actually are recording the lightning talks now, but that was, I think, if you went to the conference and just did lightning talks and hallway track, you'd probably have a really good time.

05:56 Michael Kennedy: Yeah, the other place that I would spend a lot of time was in the open sessions.

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

06:01 Michael Kennedy: Yeah, yeah, those are still not recorded, as far as I know, it wasn't obvious. It wasn't obvious if they were. All right, cool, but let's focus on the talks that you went to, and I did go to some of them, and then also went back and watched the others. So the very, very first talk at PyCon, the opening keynote was by Jake Vanderplas.

06:23 Brett Slatkin: Yeah, and he's a long-time PyCon speaker. I mean, he's been there many years and I don't know if you've seen his other talks before, but he's done tons of 'em and he's up at the University of Washington. He's actually an astronomer, that's his job which is just crazy that someone gets to do that professionally.

06:40 Michael Kennedy: So amazing, right?

06:41 Brett Slatkin: Yeah, I feel very inadequate whenever I hear him talking about what he does day to day and the science he does, it's like pretty awesome.

06:47 Michael Kennedy: Yeah, a lot of the stuff that they do with Python in astronomy is really fascinating and what struck me about this talk, there were a couple of things, and maybe I'll set the stage before I touch on some of the astronomy stuff, was basically, Jake's theme, I think it was a great way to kick off the conference. It was that the people that you are sitting among, these 3,000 people and everyone else in the community, we're all here for Python, but we don't all use Python the same way and we don't all have the same jobs, the same type of challenges and so on. So, for example, if I sat down to write like a well-structured, 50 Python file web application that talks to a database, I'll have one way of thinking and working with Python. If I have astronomy data and I want to just explore it dynamically, say, in iPython Notebooks or Jupyter, whatever, that's an entirely different way of working with it. And these different ways of working are an opportunity to learn more and catch Python from a different perspective.

07:51 Brett Slatkin: Yeah, exactly, and he called it, I think, the mosaic of Python, which I really like the analogy there. And that's a big part of what's great about going to PyCon is watchin' the talks from, that is, you have these people from just very different disciplines with very different backgrounds, talkin' about these subjects, so yeah, he really emphasized that very well.

08:09 Michael Kennedy: Yeah, I think that was a great opening message that was like, okay, I see that the people I'm talking to, maybe they really do have not just a different way of working, but a really good reason to not work the same way that I do. So I think it opened my eyes a little bit to appreciating the differences.

08:27 Brett Slatkin: Yeah, definitely. And then he walked us through all of the tools that he uses or he knows of in the scientific community, kind of walked through where they came from and it was really interesting to me because the way he actually showed it was in kind of these concentric circles of dependencies, you know, that were, at the core was Python itself, and then something like NumPy, which is really like a fundamental tool for numerical computation in Python, but I didn't even realize how many additional layers on top of that there are in terms of machine learning or data processing or things specific to astronomy and he basically went off the page with how many concentric circles there are.

09:06 Michael Kennedy: Yeah, yeah, here's Python, here's a bunch of scientific stuff that you may have heard of, here's a bunch of, you know, higher-level scientific stuff that builds on top of that, here's all the amazing things that they're doing in astronomy on top of that, oh, and by the way, here's all of these amazing satellites that are coming online that you basically work with them through Python, which is really, really amazing.

09:31 Brett Slatkin: Yeah, that was crazy because, yeah, like a bunch of different telescopes he showed and he went to the GitHub page where the code is actually completely open source, most of it in Python, and you can actually go in and fix bugs. That was one other thing he was basically saying in there was that, and so was, I think, Katie Huff in her keynote later, but you can go in there and you can contribute to these satellites, which is crazy. So it's all done in the open in this open science approach to astronomy that hadn't really been there in the past.

10:01 Michael Kennedy: Yeah, that was another super-interesting theme of this talk was how we've seen how successful open source has been and the challenges as science becomes more technology of how do we make science reproducible, so let's try to follow a similar path with open science as we do with open source.

10:19 Brett Slatkin: Yeah, definitely, and I think that there's this graph he'd, I think he may have Tweeted the graph last year at some point, but just the graph of the number of astronomy publications in academic journals that are using Python, how it's just taking off and so it seems like this really interesting effect that the open source approach of the Python community has had on astronomy, in particular, and is starting to have more generally, where people are publishing their code, their methods, their data, putting them out there so that all the results are reproducible, easy to verify, you can't phack the results so you're getting fake discoveries and stuff like that.

10:56 Michael Kennedy: Yeah, I thought that was really great and the graph that you're talking about, it really looked like an example of an explosive-growth startup out of some sort of growth-hacking story, but it was no, this is the number of things using Python now, right?

11:11 Brett Slatkin: Yeah, and it makes you think that we've just learned how to get into space or we just invented the telescope, 'cause it's just taken off. It's bizarre, so, but it's really great. Science is very computational now, where maybe in the past, it was more about labs or film processing or something like that, it seems like data processing is how science is done and that came across really strongly, as well.

11:32 Michael Kennedy: Yeah, it definitely did. One final thing that he covered that I thought was interesting and that kind of is related to that was people traditionally had learned, in the sciences, some very focused language, like there's some language, I don't remember the name of it, but it's like here's how you do astronomy programming.

11:48 Brett Slatkin: IDL, or something like that?

11:49 Michael Kennedy: Yeah, yeah, I think it was IDL, that's right, and he's like, that's really great, you can get an astronomy job with that, but if all these people now are grad students learning Python, if for some reason they don't decide to pursue astronomy, they have a super-marketable thing that they have learned as part of it, right?

12:06 Brett Slatkin: Yeah, definitely, yeah, it's much better and it also, people can contribute back to astronomy in a way that, so it goes both ways, it's a two-way street, you know.

12:13 Michael Kennedy: Like maybe we're programmers and we can program really well, but we're not astronomers, but we might wanna, like, hobbyist in it a little bit, and we can actually help out on structuring code, performance, or something, even if we're not astronomers, right? So you're right, I'd never go contribute to an IDL program, ever.

12:29 Brett Slatkin: No, no way, yeah, it's not gonna happen.

12:31 Michael Kennedy: So going from the sciences and this sort of mosaic, let's kind of go back to maybe more traditional computer science, like a large software development house with Dropbox, right?

12:42 Brett Slatkin: Yeah, this is the talk on mypy and static typing with, I think, Jukka and David from Dropbox, which is also where Guido works.

12:51 Michael Kennedy: Yeah, and this project on mypy is like Guido's main focus right now, he said when I interviewed him, when was that, like a couple of months ago.

12:58 Brett Slatkin: Oh, great, yeah. There's a bunch of things that I didn't know here, and a couple points I thought were real interesting, but the first one was, just, oh, okay, Dropbox has five million lines of Python. Wow, that's a lot, that's cool they just tell you that. And then 700,000 lines of that are typed now, which is a lot of code. And so they're actually running the type checker at build time, they do it as part of their continuous integration process where you can't commit to upstream until you've run the type checker and verify that it's clean. So they actually said that it's helping engineers at Dropbox move faster, get more done, do larger-scale refactoring. So I think the proof that typing was a good idea, good as it was basically helping realize that and kind of test it out and make sure that this is worthwhile so that any naysayers will be like, well, okay, this is not just an academic exercise in typing, like we actually have practical use cases of a very large proactical code base and we've shown it's valuable.

13:59 Michael Kennedy: Yeah, they had a pretty interesting example of, just like a, three lines of code or some, maybe four lines of code, like a really, really simple function and it's like you have no idea what this does. It's entirely simple, but it's kind of similar versions but not identical versions exist in a lot of places in that five million lines of code. Which one is this and how do you know you're not breaking it, right?

14:19 Brett Slatkin: Yeah, definitely.

14:20 Michael Kennedy: I thought that was pretty interesting and they also went through a lot of the ways in which you might approach this problem. You might put some sort of comment in your code to say here's what the types are, but then they talked about all the various trade offs on that, right?

14:37 Brett Slatkin: Yeah, definitely, and I think it's also interesting because right now, in the landscape outside of Python, you have things like TypeScript, which is the language for Microsoft, and Google's working on it related to Angular, the web framework, and then on the Facebook side with React, which is a great framework for Javascript UI's, they have something called Flow which is also a type checker, so there's a parallel here where in Flow, you do all the type annotation, a lot of it with comments, and with TypeScript, you do it in-line with the special, the syntax looks a lot like Python, actually, and then Google's old closure compiler for Javascript also had type annotations and comments. And then in Python 2.7, you can get all of the functionality of mypy and typing also by doing it through comments. So it's kind of like this thing where it's like, well, we didn't plan to have this in the language, so we had to figure out a way to shoehorn it in using comments, that it's a common theme, but now, Python 3.6 and even since 3.3 has all the different parts of support that you really need in order to add types everywhere that you'd want.

15:38 Michael Kennedy: Yeah, I don't see it being used that often, but I find it really a valuable thing on the boundaries of parts of my program, like here's this whole data access layer, and I'm not gonna go and fill out the whole data access layer with type hints, but maybe on the external functions that are being used by the rest of the app, just as you cross that boundary, I find it a really helpful thing some of the time.

16:02 Brett Slatkin: Yeah, definitely, and I think, like with the code base I've been working in, you know, this 350, 400,000 line code base, you know, we got a bunch of spaghetti in there that we really could, it would be better if we could refactor it out and, I think, finding, kind of discovering the common components in there and putting a boundary around them with a well-defined interface that has typing information would make the whole system much more stable and easier to understand, easier to test. So I'm not against types and I think that, for core libraries or core functionality that a code base relies on, it's really valuable. And I liked that they really had a really gradual way of adopting it, it's not some big bang thing where you need to go in and start writing types from day one or you have to freeze your whole code base, switch everything to types and then unfreeze it. You can actually go from a leaf node up to a root node in terms of the file and interdependencies one file at a time and it all works as expected.

16:53 Michael Kennedy: It's like a depth-first conversion.

16:55 Brett Slatkin: Yeah, yeah, exactly. So I think that's really cool that they really thought through that and they've actually done it and they explain the strategies for how they would do it, like okay, run the script this way, some best practices around checking in the script you used to run mypy to make sure that you actually are running it consistently across all developer's workstations, but it was really cool how much progress they've made, even since the last time I saw a talk on this.

17:18 Michael Kennedy: Yeah, yeah, it does really look quite nice.

17:21 Brett Slatkin: There's two things I'm most excited about here. I think the first one is just structural typing in Python, I think if you've used Go or TypeScript recently, the structural typing of the interfaces, it's just so nice where you can say, "Oh, this looks like a duck, quacks like a duck, it's a duck." and we can strictly enforce that it's a duck at compile time. It just feels so great and it's interesting because mypy doesn't do this. Like Python, you always think of it that way, like, Oh, if I can call .open on it, then I can pass it to this function, right?

17:49 Michael Kennedy: Right.

17:50 Brett Slatkin: But the type system, so far, that they're implementing really looks like the Java type system, so it's kind of odd because it's not really Pythonic yet, you know?

17:58 Michael Kennedy: Yeah, that is really interesting because it's not like you're expressing, like, the thing that comes here has to have these two functions in this field?

18:04 Brett Slatkin: Right.

18:05 Michael Kennedy: It just, it has to literally be in this type hierarchy or something.

18:09 Brett Slatkin: Exactly.

18:10 Michael Kennedy: Yeah, interesting.

18:11 Brett Slatkin: Yeah, and so I think that it's not ready for prime time until that's, like, I think people will have trouble adopting it because they'll feel like it's a little clunky until that's done. But they said they planned to do that, which is awesome.

18:21 Michael Kennedy: Oh, okay. That is awesome, okay.

18:25 Brett Slatkin: And there's a PEP.

18:26 Michael Kennedy: Oh, what's the PEP?

18:27 Brett Slatkin: Oh, I actually haven't found it, they just mentioned there's a PEP or proto, they call it protocols. There's a PEP for mypy to support those. I haven't actually dug it up yet, but I need to find it.

18:34 Michael Kennedy: Right, okay, cool. If you're working in PyCharm, it will do that sometimes, like you can hit a button when you're at the call site of a function and it will say there's no type hints here, but you're gonna need these three properties on whatever you pass.

18:48 Brett Slatkin: That's cool.

18:48 Michael Kennedy: And they kind of like pop that up, yeah. It would be really cool if this supported it. I didn't even really think about like, okay, how almost incongruent the way of specifying types is with the way that people think of dynamic typing in Python. That's interesting.

19:03 Brett Slatkin: Exactly, and there's one other repercussion of this that I think is extremely interesting which is, you know, Python right now, let's say you're accessing a dictionary and it's my dictionary, square bracket the key and then close square bracket, and maybe you'll do that in a try except and you'll catch the key error because you're expecting that there might be a key error, like the key might not be there. It's a common idiom, you'll see people, Oh, I expected this exception to happen so I'll catch it right there instead of checking if the key's there and fetching it, I'm just gonna go for it and then handle the exceptional case and that way, exceptions are part of the interface for a lot of methods and functions and you see that all over the place in code. And it's not slower in Python, it's about the same speed as a function call, so it's something that people do all the time. In the type system of mypy, you can't specify the types of the exceptions that come out of a function, and they have no plans to do it because typed exceptions in Java were really a big problem.

19:54 Michael Kennedy: Yeah, very challenging.

19:56 Brett Slatkin: Very challenging, and C# didn't make that mistake, like doesn't have checked exceptions. So I think what it means for Python programmers is that once 3.6 and mypy become more common, I think that that idiom of raising the exception and expecting it to be caught is gonna go away and I think people are gonna do it more like Go programming where you return like a tuple of it's okay and here's the results or it's not okay and here's the error.

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

20:24 Brett Slatkin: Yeah, and they support optional types in mypy so they can actually enforce typing on the variations, which is just really cool. Like, they have kind of like what Swift can do, they can do that in mypy already. So this talk, to me, was a sneak peak at what Python will be written like in three years, essentially.

20:40 Michael Kennedy: That's a cool analysis. What I was sorta seeing when I was looking at this was part of the overall trend towards Python 3.

20:47 Brett Slatkin: Yeah, definitely.

20:48 Michael Kennedy: And, you know, when Guido was on the show, I think he mentioned that this will provide some foundation for helping them move to Python 3 at Dropbox.

20:59 Brett Slatkin: Oh, yeah.

21:00 Michael Kennedy: They can reason more carefully about the code and decide if it's gonna be a problem at some sort of conversion.

21:05 Brett Slatkin: Yeah, exactly, yeah, I think that's definitely the case. They're already 700,000 lines in, so I think it was probably the first hundred thousand that was the hard part. I'm looking forward to an update on once they say that they're totally done or whatever.

21:17 Michael Kennedy: Yeah, that'll be pretty awesome.

21:18 Brett Slatkin: Yeah.

21:20 Michael Kennedy: Hey, everyone, Michael here. Let me take just a moment and thank one of our sponsors who makes this show possible. This portion of Talk Python To Me has been brought to you by Rollbar. One of the frustrating things about being a developer is dealing with errors, ugh. Relying on users to report errors, digging through log files, trying to debug them, or a million alerts just flooding your inbox and ruining your day. With Rollbar's full-stack error monitoring you get the context, insight, and control you need to find and fix bugs faster. Adding the Rollbar Python SDK is just as easy as pip install rollbar. You can start tracking production errors and deployments in eight minutes or less. Rollbar works with all the major languages and frameworks, including the Python ones like Django, Flask, Pyramid, as well as Ruby, .NET, Node, iOS and Android. You can integrate Rollbar into your existing workflow, send error letters to Slack or HipChat, or automatically create new JIRA issues, Pivotal Tracker issues, and a lot more. They have a special offer for Talk Python To Me listeners. Visit talkpython.fm/rollbar, sign up and get the bootstrap plan free for 90 days. That's 100,000 errors tracked for free. But, you know, just between you and me, I hope you don't encounter that many errors. Give Rollbar a try today. Just go to talkpython.fm/rollbar. So let's talk about the Gilectomy.

22:34 Brett Slatkin: Yeah.

22:36 Michael Kennedy: So this is Larry Hastings' talk, and he's been at it for a couple of years. And, first of all, let me just take a step back and maybe tell us what the GIL is and do you think the GIL is actually a problem for Python.

22:47 Brett Slatkin: Wow, okay, so it's the GIL, the Global Interpreter Lock, which is the part of the CPython interpreter that locks the state machine state while your program's running so that different threads don't trash each other. It's a key part of how CPython works, how CPython's virtual machine works, and it has unintended consequences which are that it prevents your Python program from using multiple cores at the same time. So it limits the actual execution speed of Python, vanilla Python.

23:17 Michael Kennedy: Right, basically only for computational stuff.

23:19 Brett Slatkin: Only for computational stuff, yeah.

23:22 Michael Kennedy: When you are waiting on the OS, like for a network or file, it releases the GIL, right?

23:27 Brett Slatkin: Yeah, it does and so for I/O bound applications or memory bound applications, it's not a big deal, but for CPU bound stuff, especially servers where they're tryin' to be really highly-responsive, that can be a problem. So yeah, to answer your question, is it a problem? Well, it depends on who you ask. In the JavaScript community, V8 is not multi-threaded in the same way, it's completely single core for similar reasons.

23:50 Michael Kennedy: Which means Node is in a similar situation,

23:51 Brett Slatkin: Yeah, Node, yeah.

23:52 Michael Kennedy: Right?

23:53 Brett Slatkin: Yup, but you don't really hear people complaining about that with Node because it's all they can use. And then things like Go are highly concurrent, super-fast. So I think Python's limiting itself by not being able to use all CPUs out of the box. There are tools like multi-processing, the multi-processing module in Python that do let you take advantage of all CPUs, but it's just hard to use if you don't know what you're doing.

24:15 Michael Kennedy: Yeah, I don't think it's that huge a problem. I think the thing that's sort of relieved the pressure is 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, yeah. And so the really intense cases seem to have already worked around it. You just pip install a thing and you're okay.

24:35 Brett Slatkin: Yeah, but even in those cases like Numba andother packages like this, you need to restructure your program around this to take advantage of it. And I think that's the burden, this was working, why can't I just turn up the speed dial and have it go faster, or you can increase the concurrency, you know, where you can do that with some other languages or other constructs. So, yeah, I think with 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 that Larry's been diving into it.

25:01 Michael Kennedy: Yeah, okay, so that brings us to the Gilectomy.

25:03 Brett Slatkin: Yeah, so he's been talkin' about it for a couple of years now, and he's trying to remove the GIL, or at least remove the overhead of the GIL and it's been tried a few times. If you look back at his older talks, I think there was 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-cores, multi-threaded support to Python, I think, version, maybe it's version 1.5 or version 2.0, way back when, and it was insanely slow. It was like awful. And so, yeah, I know, so Larry's got a very particular style of presenting which is funny and very intense, but, yeah, he, just right off the bat, he's like yeah, Python without the GIL, you can take the GIL out very quickly, it's actually not too hard, but the problem is that it's really slow. It's 19 times, the one with the GIL is 19 times faster than the one without it, right?

25:51 Michael Kennedy: Exactly, so yeah, you can do this, but before you see any advantage, you're gonna need, like 32 cores and really highly-concurrent algorithms.

25:58 Brett Slatkin: Yeah, exactly. You know, Larry is the guy who knows this stuff. So it's been interesting because he is taking everything he knows, every trick in the book, essentially, and applying them to this GIL problem. Yeah, so he, in his talk, he walked through a lot of those and we can talk about a couple of those examples. It started off just seeming hopeless, like he has no chance. In 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. And so about halfway through the talk, I'm like, "Oh, man, he's totally failed on this attempt," you know, but, well, I won't give away the end, it's just, well, okay, I guess 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 Michael Kennedy: Yeah, well, I think what was interesting about this was he didn't lay out a lot of the different techniques and things that he had tried 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 GIL gone, I wanna just like take advantage of all the CPUs," 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. Yeah, it was interesting.

27:14 Brett Slatkin: Yeah, and there's a lot of references, that's exactly right, there's a lot of references of things that I need to look up after that like some two-stage locking stuff, getting rid of accelerating thread local variables, there's something about, there's a book called The Garbage Collection Handbook that I'm like, oh, wow, never even heard of that. It has an algorithm called Buffered Reference Counting, which I guess was the way that he was able to make it fast. 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." He also invented that independently, but he's like, "Oh, no, this is actually a know technique that I'm using."

28:07 Michael Kennedy: Even when he did invent something, it was just like a reinvention of the thing that existed, right?

28:12 Brett Slatkin: Yeah, like from 1977 or whenever it was, 'cause that's always how it is.

28:16 Michael Kennedy: That's definitely how it is.

28:18 Brett Slatkin: But ultimately, the last graph he showed was that it's really close now. I'm shocked 'cause I did not think it was gonna be possible and he's within, I think, maybe 2X or less of slowness,

28:29 Michael Kennedy: Wow.

28:30 Brett Slatkin: So he's made it from 19 times slower, whatever it was, to within 2X, so I think it's just a matter of time now and the trade off is it costs a lot more CPU, but our machines have a lot more cores now and people are offloading more and more work onto secondary cores for doing garbage collection and bookkeeping tasks and, you know, the Go language, that's basically all it does for how it gets to be so fast, with such a low GC time, so I think that that's fine, so I'm just real excited. I think it's, you can imagine that Python 2.7 goes away because Python 3.3 has no GIL and it's superfast, or Python 3 has no GIL and it's superfast and people are like, "Wow, why would I use Python 2 when I could use Python 3 and run a lot faster?"

29:12 Michael Kennedy: Yeah, and so this is actually an interesting point. I don't believe the Gilectomy 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 Viehland started workin' on this thing called Pyjion?

29:28 Brett Slatkin: Oh, Pyjion.

29:29 Michael Kennedy: Pyjion, yeah Pyjion. Basically there's a couple of folks in the core developers sayin' what can we do to improve adoption of Python 3? What if we made it 50% faster, right? That alone, if nothing else happened, that alone would make a huge difference. And I think actually, regardless of whether it's been faster or not, the last two years have made a huge shift towards Python 3. But the next talk that we're gonna talk about, by Victor Stinner, was really highlighting some of the performance improvements that he and some other folks have done on Python 3.

30:03 Brett Slatkin: Yeah, definitely, I really liked this talk and I thought Victor's a really solid member of the Python core developer community and I really liked this talk because it was very scientific in its presentation and it was like, okay, here's how we did the measurements. It started off just with that, this was like...

30:19 Michael Kennedy: I was gonna say, it was like, it actually started out with the measurements we've been using are unreliable. First thing before we even start this process is we have to fix the measurements, right?

30:29 Brett Slatkin: Yeah, you can't even trust the numbers we used in the past, 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. Yeah, so that was great.

30:42 Michael Kennedy: Right, and part of that wasn't even just like, hey, we were bad at running this code, but modern CPU architectures have things like turbo-boosting and the speed at which your processor might run at can vary by like 2 or 3X, depending on how it's trying to save energy at the time and all sorts of stuff, right?

30:58 Brett Slatkin: Yeah, and that actually came up in a few different talks, including the Gilectomy one, and another one I went to where people are trying to benchmark things and there's no good way to disable all of the magic features that are in modern Intel CPUs or even ARM CPUs and so I think that there's actually a module that they're putting together that's like the standard benchmarking module that turns off all of this stuff automatically. I actually don't remember what it was called.

31:23 Michael Kennedy: It was like Per for Performance or something. Victor Stinner had worked on it and he...

31:27 Brett Slatkin: Yeah, so that's great, do I think if you're doing any benchmarking of any kind, it's worth picking that module up and using it for your purposes so you can make sure that you're actually comparing stable numbers over time.

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

31:47 Brett Slatkin: Yeah, and there's so many of them, it's getting into the weeds with some of this stuff, but one of the ones was, one thing was like it's no longer actually called Python byte code, that was one I liked, so Python doesn't have byte code anymore, it has something called word code because a byte's only one byte where a word is like 16 bits or it's multiple bytes. And so there's some inner loop in the CPython runtime that had an if statement, which is like, okay, is this byte code, does it have any arguments 'cause if it does, then it's more than one byte 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 the modern machines is good enough that we don't need to actually save space.

32:25 Michael Kennedy: Yeah, they basically removed conditional check in C of L dot C, which is like the switch statement that went--

32:33 Brett Slatkin: The hot loop.

32:34 Michael Kennedy: Yeah, that's the super-hot loop. And so simple things like that, like maybe we'll just throw in a wasted byte when there's no argument and that will actually make it a little bit less memory-efficient, like tiny, but much faster 'cause you can skip some checks, right?

32:48 Brett Slatkin: Yeah, exactly, and so it ends up netting, I don't remember what the performance boost, but there's a bunch of these that improve benchmarks by 5%, 10%, 20%, and that stuff really adds up, so it's really, they've done a lot. So Python 3.6 is extremely fast compared to others. It's amazing to see that that progress.

33:06 Michael Kennedy: Yeah, so I would definitely say, especially if you're on Python 2 still and you're like, "Hmm, is it really worth switching, I get this language feature, sure, I can do double star to create dictionaries out other dictionaries and whatever, but is that really worth it?" Like, check out this optimization talk, 'cause 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, and it's just like, whoa.

33:27 Brett Slatkin: Yeah, definitely, like the Decimal module, for example, that one is actually rewritten in C, but I think it was 40 times faster--

33:32 Michael Kennedy: Yeah, 40 times faster.

33:34 Brett Slatkin: Which is like, I use Decimal all the time, so that would be helpful for what I've done. He also alluded to something that would be in Python 3.7. He didn't really wanna go into it yet, because he says the results aren't perfect or fully proven, but he did say that, in Python 3.7, that method calls are gonna be faster across the board and that's my biggest problem, I would say, with Python is that calling a function is really slow.

33:56 Michael Kennedy: Yeah, that's a really good point, like you are at odds with performance with structuring your code well.

34:03 Brett Slatkin: Exactly, and so, especially with the optimizing code, you're like well, this is really hard to understand, so I'm gonna split this into functions so I can follow it, and as soon as you start doin' that in Python, you're slowing your program down every single time. And that's not a trade off you wanna make, you know, that's terrible. And so anything you can do to make function calls faster, he already talked about a few of those and he said there's more coming in 3.7, so I think it's maybe the beginning of this performance renaissance in Python that I'm really looking forward to, the Gilectomy being part of that, as well, but just meat and potatoes optimization, which is what Victor is doin', it's just really great to see.

34:37 Michael Kennedy: Yeah, really, really amazing stuff 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. It's like here's a simple optimization, but it took us two and a half years because it was incredibly difficult to get every edge case just right.

34:54 Brett Slatkin: Yeah, yeah, it's just totally, yeah, and that's why it's like a dark art, you really need to know what you're doing to optimize and you really need good tests. I think the case you're talking about is they rewrote LRU cache algorithm, it took 'em like--

35:05 Michael Kennedy: Yeah, that was the one, I think, yeah.

35:07 Brett Slatkin: It's two and a half years, yeah, it's pretty crazy .

35:11 Michael Kennedy: Yeah, that's pretty amazing. All right, so one that I did not see but you went to, maybe you could tell us about is the debugger one.

35:16 Brett Slatkin: Yeah, so this is by Elizaveta Shashkova from JetBrains, I think, in Saint Petersburg. And this one was really cool, so it's cool because there's this PEP called PEP 523 and it's a Python enhancement proposal and the purpose of the PEP is to give Pyjion, which you were just talking about, which is a JIT compiler, a Just In Time compiler, for Python to make Python faster, that's what the PEP was for. It added a bunch of hooks into the CPython runtime that let's you change the way that functions and code are evaled, so you can plug in stuff.

35:54 Michael Kennedy: Yeah, the big idea is let's not keep rewriting new runtimes. Let's try to find a way that you can plug into the one that we all have without forcing everyone to go should I do PyPy, should I do Jython, should I do Iron Python? Ugh, forget this, right?

36:07 Brett Slatkin: Yeah, exactly, and so make it more extensible. So that's really cool that that PEP was created and has been plugged into Python, I think it might be 3.5 that it landed. But what they didn't realize when they developed this PEP is it would enable new use cases and so Eliza, what she went through is how they actually leveraged that same interface to enable a debugger for Python that is as fast or almost as fast as just vanilla Python. And so if you've ever run your Python code under a debugger, it's something like 30 times slower.

36:41 Michael Kennedy: Oh, interesting.

36:42 Brett Slatkin: And so it's like really hard to actually simulate a lot of the problems you have or if you have timing issues, especially where there's races, you just can't even reproduce them because it's so slow, everything runs in the right order under the debugger and then, once you run it normally, then it goes fast enough and you get these data races again and then you get the bugs.

37:00 Michael Kennedy: Yeah, yeah, heisenbugs.

37:01 Brett Slatkin: Heisenbugs, right. And so they created this thing in the JetBrains and I think it the core of it's open source where it basically uses the PEP 523 hooks that are meant to be for speedy eval and it'll actually rewrite the Python byte code or word code as it's coming through and insert break points into the byte code which makes it orders of magnitude faster because the old Python debugger uses, it's a set trace where you get a function call for every single line of Python.

37:32 Michael Kennedy: It's almost like a profiler.

37:34 Brett Slatkin: Yeah, exactly, and it's the slowest thing imaginable. It's, first of all, you're calling a function, which is slow, right? And then you do it for every single line, whether or not you care about that line. So I loved this talk because she walked through all of it, how the debuggers work, all the details about why they're slow, benchmarks are on that. Then, she explained her approach to how they do it, what it's good at, how it works. She even showed the disassembly of the Python byte code and how they plug into it. So it was really awesome.

38:00 Michael Kennedy: Yeah, that's cool. I'm definitely gonna have to check this one out.

38:02 Brett Slatkin: Yeah, I would, and my favorite part about it is just like that PEP defined an interface that is generally useful to people, so it wasn't intended to be used for this purpose, but it was general enough that it could be. And that's good design from my perspective.

38:20 Michael Kennedy: Yeah, it's really nice that that wasn't even part of the plan, right? But just this flexing and growing CPython, actually, made this other use case really good.

38:31 Brett Slatkin: Yeah, definitely, so I'm lookin' forward to using that debugger and I keep hearing great things about PyCharm and I've never actually used it for anything like day to day, I poked around with it, but never built a whole program with it.

38:42 Michael Kennedy: Yeah, I don't know if this is the same thing, but when you debug something in PyCharm, if you just do that on a brand new machine, it'll say warning, the debugger speed ups are not built, you basically have to run this compiler statement to like build something into your system--

38:58 Brett Slatkin: Oh, yeah, that might be the same thing, yeah.

39:00 Michael Kennedy: Yeah, I think that might be it, actually, so there's like a little output that it goes, hey, you could make this much faster if you run this line once.

39:06 Brett Slatkin: Gotcha, yeah, I didn't know about that.

39:09 Michael Kennedy: This portion of Talk Python To Me is brought to you by Codeship. Try Codeship Basic, a free, simple, out-of-the-box continuous integration service in the Cloud. Thousands of customers use Codeship Basic every day. Its preinstalled CI dependencies make testing your software and deploying it work out-of-the-box. The average setup time for Codeship Basic is less than three minutes. Codeship Basic comes with a free plan that grants 100 builds per month, unlimited projects, and unlimited users. Do you run an open source project? Those are always free on Codeship. And they just improved their Python support, so give Codeship a try and visit talkpython.fm/codeship to learn more and sign up for free. That's talkpython.fm/codeship. So one of the things that I thought was really neat, I think there's a lot of things touching on this, it's like, hey, this Python 3 stuff is becoming really amazing and maybe the pinnacle that was the Instagram keynote.

40:09 Brett Slatkin: Yeah, this is a great talk because it's kind of two parts, I think, Lisa Guo was the one who talked mostly about the actual, the transition, but it was how they moved from Python 2 to Python 3 while not having any downtime.

40:24 Michael Kennedy: Yeah, I watched the talk and I thought, okay, there's almost no other company out there, maybe a handful, but almost anyone else who says we can't switch to Python 3 because we have a large code base, we have a lot of users, we've gotta keep shipping, what Instagram did was really quite incredible. The first thing that I sort of thought, okay, this is gonna get really interesting, is they just have one branch that they develop from, right? They don't just, it's not like they said let's just fork everything and go over there for six months and work on that.

40:58 Brett Slatkin: Yeah, and that's a recipe for disaster, I think, and I actually work in a mono repo with a single trunk as well, I've been doin' that for years, which is kind of odd for many people, 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. I wouldn't do it all at the same time without breaking people or making sure that commits keep flowing through. So just in terms of process and collaboration with a large team of people, I don't remember how many engineers they have workin' there, but it's hard.

41:29 Michael Kennedy: Yeah, there are quite a few. So they're goals were we're not going to branch, we're gonna take our existing code which is Python 2.7 running Django 1.3, which is five versions out of date, and we're going to move that to Python 3 and the latest version of Django. I suspect that Django switching, Django 2 saying we're not gonna support Python 2 anymore that, so we're just done. They're like we're kind of painting ourselves into permanently into somewhat of an old version, let's see if we can get back on track.

41:59 Brett Slatkin: Yeah, and that was the incentive there. Yeah, I thought that was, there's been this push to get all the libraries onto Python 3, which has really made a lot of progress over the last, let's say, five years, and now it's almost there for all the major ones and this is an example of the dividends that that's paid off because now Python, Django 2 is like we're not gonna support these older versions and then Instagram's like we really like that open source project and we collaborated and we worked on that and so they're incentivized to move, and she also mentioned that Python 3.6 is just faster, so those are two proof points that this strategy that Python's had more recently, maybe they should've had earlier, that would have helped the transition to happen faster, but this more recent strategy of performance libraries is starting to actually be enough of a carrot and a stick to get people to start converting at a larger scale.

42:47 Michael Kennedy: Yeah, it's really, really interesting. I totally agree with you. So they said we're going to try to continue to ship new features, we're going to check into this one branch, we're not gonna branch it, we're going to have a very careful rollout of Python 3. I thought that was actually really interesting, as well, both how they did the testing by saying we're going to slowly say these are the tests that passed and we'll like eat our way back into all the tests until they basically all pass again, and the way of staging the rollout, as well, was interesting.

43:20 Brett Slatkin: And they're basically maintaining a Python 2 and 3 code base, like one that could run either runtime at the same time. So that's how they started this and what gave them the ability to make those more tactical moves in production is they ran the tests, all the tests, under 3 and 2 using a white list or an exclusion list, inclusion and exclusion list, and then they basically started moving test after test across and setting up some best practices and that kind of stuff.

43:48 Michael Kennedy: Yeah, I really liked this that it was very prescriptive. These are the steps which you need to take. Do it this way, this way, and then, like it was really a roadmap, not just a "Hey, look, we did it."

43:58 Brett Slatkin: Yeah, I definitely like, if you work somewhere and you wanna be able to explain to your boss, oh, this is what we need to do and how we need to do it, just have them watch this video because it's really--

44:08 Michael Kennedy: It's really convincing.

44:09 Brett Slatkin: Definitely, it's really convincing and it has a bunch of best practices for teams and it even has some nuggets that are really valuable, like one I thought was really cool was they talked about they rely on Memcache so heavily and there's this issue between version 2 and version 2 of memcache where, I'm sorry, version 2 and version 3 of Python where the pickle module becomes, it can poison the other version. I don't know if you remember seeing this.

44:34 Michael Kennedy: Right, they're basically incompatible with the serialization format and various things.

44:39 Brett Slatkin: Yeah, so it was real interesting because I've actually had this problem in production many times. 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 somehow slightly change the structure of the object 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 and the only solution, even if you flush the cache, it doesn't work because the old version will start writing it's stuff into the cache, the the new version will start writing it's stuff, so there's no, once you get into this loop of death, it's like there's nothing you can do. It's really scary.

45:18 Michael Kennedy: Yeah, so they started partitioning their Memcache keys to make sure that they wouldn't interact. I'm envisioning them putting PY3 or PY2 in front of every key name or something.

45:29 Brett Slatkin: Exactly, and that's really an amazing best practice. It seems so obvious when you hear about it, but I think that that's something that, even if you're just doing rollouts or deployments, or you have new docker images that are holding your app in them, that's actually a great strategy just to reduce the amount of incompatibilities between the runtime, the runtime versions you have goin' on.

45:49 Michael Kennedy: Maybe even like your app version or something, right, it can even be that much, because it could be your code change, not Python's internal change that--

45:56 Brett Slatkin: Yeah, that's what I'm tryin' to say, between your own code versions and your commit, hash could use as a prefix, I think that's a really cool best practice.

46:04 Michael Kennedy: Yeah, cool. So I really liked this and in the end, I guess I can talk about the rollout really quick, that was interesting. Okay, the first thing we're gonna do is we're just gonna run the tests on Python 3 as well and we'll start to slowly work that up and then we're gonna switch all the dev environments to run Python 3, but still do continuous integration to ship to Python 2, and then once we get all the dev environments working and we stop hitting bugs, we're gonna switch to just the employees of Facebook. And then .1% of the, isn't it 20%, and then, so they had this really structured rollout and they said by the time we got done with the internal use cases, there was barely anything left to do.

46:46 Brett Slatkin: Yeah, definitely. So that's just really conservative, well-done, and I'd say you have to everyone on board, though, but it takes time, it's gonna take a lot of resources, you need a dedicated team who's not doing anything else. And, yeah, so I think it's a model that we should all follow.

47:02 Michael Kennedy: Yep, and in the end, they said, look, there's these different parts of our code, we run Python and Django and mWSGI. We run our async stuff, our notifications in Celery, and we got a 40% performance improvement--

47:14 Brett Slatkin: Oh, right.

47:14 Michael Kennedy: In Celery, in the async area, and we got a 12% performance memory speed improvement in the web front end, which, there is something you could take to your company, to your executive and say, "Look how much we're paying for all these servers we gotta maintain, look at how much better it'll be..."

47:33 Brett Slatkin: Yeah, just translated it straight to a financial savings in number of machine capacity that you could get out of it. That's just another amazing, convincing argument that's just, you have speed, you have efficiency, and then you have the cost savings, so it's great.

47:48 Michael Kennedy: Yup, it's great. So we started this whole discussion by thinking of satellites that look out into space, but the next one you went to is about satellites looking in towards the world.

47:58 Brett Slatkin: Yeah, so this is by Katherine Scott. She wrote the book on OpenCV for Python, she's been in the Python community for a while doing a lot of stuff like robots and computer vision and I think she recently joined a company called Planet, which is a satellite imagery company that let's you buy satellite imagery and also let's you get access to it for free under a bunch of circumstances. 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. So it's more accessible than I ever knew, you know, you can say, hey, this lat-long, can you give me every image of it for the last number of years and you can actually pull that up through an API now, which is just totally bonkers, you know.

48:44 Michael Kennedy: Oh, that's really cool. You can actually see how it changes over time, maybe.

48:47 Brett Slatkin: Yeah, and you know, for her, she mentioned that, it was kind of like an aside, but for her, it was also something that she thought was politically important to her, you know, deforestation of the rain forests and like all these other kinds of things like that. 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. So it was really cool to see her work through a bunch of those examples.

49:13 Michael Kennedy: Oh, yeah, that sounds really interesting. Another one controlling things, even more so, was the factory automation one, right?

49:21 Brett Slatkin: Well I think, actually, they used to work together, Katherine and Jonas. I don't actually know that, but he works at Tempo Automation, which is a pick-in-place robot company in San Francisco and so they do a lot of crazy things with factories. I loved this talk. It was really fun because he had a live demo of the entire thing, and I'm pretty sure that the video captures some of that, I don't know if you remember seein' that, but he had this conveyor belt contraption set up there and it had a conveyor belt and it had two pusher pads and you had some gum, like chewing gum, and he's like, We're gonna build a robot that will sort this gum into bubble gum and spearmint gum, based on the color of the package and a barcode.

49:58 Michael Kennedy: Oh, that's cool.

49:59 Brett Slatkin: Yeah, and so then he walks you through, okay, in Python, there's actually a pySerial library that will interface with a serial port and the serial port is a microscanner for barcode, and so he just like walked you through, just from the beginning, okay, here's how you can scan a barcode, here's how you can actuate a little paddle in like a pinball machine, here's how you can turn on a conveyor belt, and there's all this stuff, I know it's in there, I've seen stuff on TV or whatever about factories and conveyor belts in factories, but he just went through how it all actually works together and you can do it all from Python. He has great libraries for it. And it seemed really easy, so it's like it's one of the best talks, where like I could totally do this, you know.

50:40 Michael Kennedy: Yeah, made it entirely accessible, right?

50:42 Brett Slatkin: Yeah, totally accessible.

50:43 Michael Kennedy: Excellent.

50:44 Brett Slatkin: Yeah.

50:44 Michael Kennedy: That's great, yeah. I really think the Internet of Things and these little devices, we're just at the beginning. There'll be really cool stuff we can do with it.

50:51 Brett Slatkin: Yeah, definitely. And I think it also makes you realize that the Internet of Things, we talk about it mostly for consumers and the little devices in our houses, but in the factory, these devices are actually much more impactful. And so you have sensors 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 Michael Kennedy: Assembly line?

51:14 Brett Slatkin: Assembly line, thank you, yeah. He just showed all the things you need in order to do that. It's awesome, 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 like I Love Lucy-style to be running at a million miles an hour,

51:30 Michael Kennedy: Zzzzzzzz.

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

51:35 Michael Kennedy: Yeah. The last one I thought was pretty inspiring by Mariatta called Dial M for Mentor.

51:43 Brett Slatkin: Right, she's the first female Python core developer who's landed a commit in Python 20 some-odd years after Python started and so it's just really great that the Python community has been able to, we just had, a couple of years ago, hey, we really need to diversify the people who are committing to the core, sent out the call, tried to mentor people and he repeatedly said that we need to have more different types of people committing to Python, and so she is the first female committer to Python and to the core. To me, this talk was a lot about the kind of journey of mentorship, what it takes to make a contribution like that for someone, where it might seem really scary.

52:22 Michael Kennedy: Yeah, absolutely. Really, the part where she talks about being a core developer, that's not until like the last five minutes. Up til then, it's like here's all the ways that I was frustrated becoming a developer, here's all the ways I got stuck 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. And on the core developer side, I think Guido actually was her mentor to help her make her way through to actually getting stuff working at the code level in CPython, which is pretty cool.

52:55 Brett Slatkin: Yeah, yeah, it's cool, and I think that she explained a lot of her fears and the common issues that people have when they need mentorship but are too afraid to ask for it or have a hard time finding it. And so it's a good wake-up call for 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. And I've heard 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 work through their slides, practice, yeah, I don't know if they're actually doing this for PyCon itself yet, but they do it for DjangoCon and I think that's an awesome model and I really hope that they, they should just do that for all of the regional PyCons and all of those kind of meet-up groups just because that's how you build confidence in young people or people who are approaching Python from different backgrounds, and I think that's really critical. So I think that her talk is a great way to kind of focus on what these mentors should be doing and how they need to make people feel comfortable seeking out mentorship.

54:01 Michael Kennedy: Yeah, I think if you're in your first five years of programming, this will be really helpful for you, looking for a mentorship and finding your way and feeling confident. And I think if you've been a programmer 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 Brett Slatkin: Yeah, definitely, and I've been on both sides of that. You know, I remember needing mentorship way back when, and I also, and now I do mentor people but I would mentor more if I had a better way of connecting to people who need it, and there's a couple of ways she calls out that people can do that, which is great for people that volunteer and I hope that more come up in the Python community so that the people doing the mentoring, also, more of them volunteer and really make a point of taking the time to do it.

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

54:49 Brett Slatkin: Yeah.

54:50 Michael Kennedy: For the ones that we went to, maybe I can ask you, really 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 Brett Slatkin: 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:06 Michael Kennedy: 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, we're at the limit for fire code in this room.

55:14 Brett Slatkin: Yeah, that's usually what happens, fire code. Yeah, so it's like if people are new to PyCon, I'm like, well, you should probably go to this talk and get there early. Yeah, and I don't go, I'll watch that talk later, you know. And then Brandon Rhodes, who is the chair of the conference, he also had a talk on dictionaries, as well. I think it was different enough from the other one, so I'm looking forward to watching that one. He's a great speaker.

55:33 Michael Kennedy: Yeah, that's really good.

55:34 Brett Slatkin: And the last one is Brett Cannon, he had a talk on what's new in Python 3.6, it's just like a summary, and so you can read that online if you just Google like what's new Python 3.6, you'll find it, but hearing someone give the talk is a lot more interesting than reading through the notes, so I would definitely check that out.

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

56:07 Brett Slatkin: Yeah, I agree.

56:07 Michael Kennedy: All right, excellent. It was a fun PyCon, right?

56:12 Brett Slatkin: 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 a totally different change of scene.

56:18 Michael Kennedy: Yeah, it'll be fun.

56:20 Brett Slatkin: And I'm lookin' forward to that and great talks, so I'm looking forward to next year, and in the meantime, there's a bunch of regional PyCon conferences coming up, so that's another, just check out, 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 worth checking those out.

56:37 Michael Kennedy: Yeah, absolutely. I think they just announced PyCon Canada and then there's also PyCascades, which is gonna be in February, I think. The PyCascades is brand new. Actually Marietta, the last person we spoke about, was part of the organizer for that.

56:50 Brett Slatkin: Right, yeah, yeah, I think it's for all the Pacific Northwest kind of area.

56:53 Michael Kennedy: Yeah, so definitely get out to one of these PyCons, or multiple ones if this sounds interesting to you.

57:00 Brett Slatkin: Definitely.

57:00 Michael Kennedy: It's really a great time, even if you don't go to the talks.

57:02 Brett Slatkin: I agree.

57:03 Michael Kennedy: All right, final two questions, Brett.

57:04 Brett Slatkin: Okay.

57:05 Michael Kennedy: If you're gonna write the Python code, what editor do you use?

57:07 Brett Slatkin: I'm still usin' Sublime Text. I'm on version three now. Yep, that's still my thing, and if I'm at a terminal, I still use Emacs, so I'm on that side of the debate.

57:17 Michael Kennedy: All right, very cool. And notable PyPI package?

57:20 Brett Slatkin: Wow, recently, it's gonna be what I can't live without, right? I think it's been my go-to, still, yeah, from doing web development, I'm gonna install Flask every time basically, so without a doubt. But I think if I'm actually just trying to do processing, it's NumPy, which it's still the best thing to tap into Python.

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

57:47 Brett Slatkin: Yeah, 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 Michael Kennedy: Yeah, yeah, that's very cool. All right, so you actually have a playlist of this, right?

57:58 Brett Slatkin: Oh, wow, I do, yeah. I could share that. That's a good idea.

58:00 Michael Kennedy: Yeah, if it's all right with you, I'll just put it in the show notes

58:02 Brett Slatkin: Sounds good.

58:03 Michael Kennedy: And people can just subscribe to it and just go through. They can basically replay PyCon through your attendance.

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

58:15 Michael Kennedy: All right, awesome. Brett, thanks for being on the show. It was excellent to talk with you.

58:17 Brett Slatkin: Yeah, thanks so much for having me. I had a really good time.

58:20 Michael Kennedy: You bet, bye. This has been another episode of Talk Python To Me. Today's guest has been Brett Slatkin, and this episode has been brought to you by Rollbar and Codeship. Rollbar takes the pain out of errors. 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. As Talk Python To Me listeners, track a ridiculous number of errors for free at rollbar.com/talkpythontome. Do you have software? Would you like to know if it has bugs before you deploy it? Then jump over to talkpython.fm/codeship and set up a free Codeship Basic account, ship tested software. Are you or your colleagues trying to learn Python? Well be sure to visit training.talkpython.fm. We now have year-long course bundles and a couple of new classes released just this week. Have a look around. I'm sure you'll find a class you'll enjoy. Be sure to subscribe to this show. Open your favorite podcatcher and search for Python. We should be right at the top. You can also find the iTunes feed at /itunes, Google playfeed at /play, and direct RSS feed at /rss on talkpython.fm. Our theme music is Developers, Developers, Developers by Corey Smith, who goes by Smix. Corey just recently started selling his tracks on iTunes, so I recommend you check it out at talkpython.fm/music. You can browse his tracks he has for sale on iTunes and listen to the full-length version of the theme song. This is your host, Michael Kennedy. Thanks so much for listening. I really appreciate it. Smix, let's get out of here.