WEBVTT 00:00:00.001 --> 00:00:05.780 The Python Language Summit is a yearly gathering of about 40 to 50 developers from CPython and other 00:00:05.780 --> 00:00:10.580 Python implementations and related projects. The summit is typically held on the first day of PyCon. 00:00:10.580 --> 00:00:15.900 Many of the decisions driving Python forward are made at this summit. On this episode, 00:00:15.900 --> 00:00:21.640 you'll meet Marietta Wijaya, Lucas Lenga, and Brett Cannon, three well-known core devs, 00:00:21.640 --> 00:00:26.100 to walk us through the major topics covered in this year's summit. This is Talk Python To Me, 00:00:26.100 --> 00:00:30.060 episode 179, recorded September 26, 2018. 00:00:30.060 --> 00:00:49.380 Welcome to Talk Python To Me, a weekly podcast on Python, the language, the libraries, the ecosystem, 00:00:49.380 --> 00:00:54.140 and the personalities. This is your host, Michael Kennedy. Follow me on Twitter, where I'm at 00:00:54.140 --> 00:00:58.480 M. Kennedy. Keep up with the show and listen to past episodes at talkpython.fm, 00:00:58.480 --> 00:01:04.420 and follow the show on Twitter via at Talk Python. This episode is sponsored by Linode and Rollbar. 00:01:04.420 --> 00:01:08.180 Please check out what they're offering during their segments. It really helps support the show. 00:01:08.180 --> 00:01:11.680 Marietta, Brett, Lucas, welcome to Talk Python. 00:01:11.680 --> 00:01:12.100 Hello. 00:01:12.100 --> 00:01:12.600 Hi. 00:01:12.600 --> 00:01:13.400 Thanks for having us. 00:01:13.400 --> 00:01:17.500 Yeah, it's great to have Brett and Lucas have you guys back. And Marietta, 00:01:17.500 --> 00:01:20.260 welcome to the show for your first time. I'm excited to have you here. 00:01:20.260 --> 00:01:23.560 Thank you. Yeah, I'm excited to be invited here. Thank you. 00:01:23.560 --> 00:01:29.420 Absolutely. So we're going to talk about the Python Language Summit, which I think is 00:01:29.420 --> 00:01:34.900 not that well known and really, really important. And so I'm really excited to talk about that show. 00:01:34.900 --> 00:01:38.140 But I want to give you all a chance to just introduce yourself for folks who maybe didn't 00:01:38.140 --> 00:01:42.280 listen to some of the other shows or don't know you. So Marietta, let's start with you. Just, 00:01:42.280 --> 00:01:46.180 you know, who are you? And what do you do day to day real quick? 00:01:46.180 --> 00:01:52.180 Yeah, my name is Marietta. I work at Zapier, building integrations for various apps. I work 00:01:52.180 --> 00:01:58.060 in the partner engagement team. So basically, we're building more tools for our partners. 00:01:58.060 --> 00:01:58.400 Nice. 00:01:58.400 --> 00:02:04.040 For CPython, I build lots of bots, lots of automations as well. So, yeah. 00:02:04.040 --> 00:02:05.420 And you're on the core developer team, right? 00:02:05.420 --> 00:02:06.080 Yeah. 00:02:06.080 --> 00:02:07.580 You're one of the core developers? Very nice. 00:02:07.580 --> 00:02:08.060 Yeah. 00:02:08.060 --> 00:02:08.480 Lucas? 00:02:08.720 --> 00:02:14.720 Hello, I'm Lukasz. I work at Facebook on the Python theme there. So we make sure to 00:02:14.720 --> 00:02:21.120 be using the latest and greatest that is available in a safe way and in a way that sort of enables 00:02:21.120 --> 00:02:27.160 us to use Python in our increasing scale and whatnot. I am contributing to Python, but you 00:02:27.160 --> 00:02:32.600 probably don't know this. But what you do know is that I am the creator of black. So this is what 00:02:32.600 --> 00:02:38.820 sort of everybody, I don't know, for some reason always knows about me, but not the other things. 00:02:38.820 --> 00:02:44.620 I do write peps from time to time. In fact, I'm working on one right now. But you'll probably also 00:02:44.620 --> 00:02:49.380 not know about this because that PEP is very boring. It's just about how we're going to make decisions 00:02:49.380 --> 00:02:51.880 in the future. We'll see if it gets selected. 00:02:51.880 --> 00:02:54.780 I think that's actually a pretty big topic, actually. 00:02:55.060 --> 00:03:00.360 Oh, yeah, it is. There's a few sort of, I don't want to say competing, but well, they are competing 00:03:00.360 --> 00:03:07.680 in a sense. There are a few possible models of governance that we can end up with. And the one 00:03:07.680 --> 00:03:15.580 that I'm working on is revolving around the community. It's assuming that there is not going to be another 00:03:15.580 --> 00:03:22.420 benevolent dictator and there's not going to be a very small council or triumvirate or however you call 00:03:22.420 --> 00:03:28.140 it. We're going to sort of look up to the best, like C++ standard comedy. Ah, no, kidding. Well, 00:03:28.140 --> 00:03:34.120 there's other projects that actually use this model like Rust, like ECMAScript and whatnot. 00:03:34.120 --> 00:03:42.140 And Python actually is enough. Well, it's mature enough that in my view, this model would actually 00:03:42.140 --> 00:03:49.300 ensure that we are addressing the interests of the widest sort of number of our users that way. 00:03:49.300 --> 00:03:53.640 Yeah, I think I read the PEP that you're working on and that's really great. I like the 00:03:53.640 --> 00:03:57.240 sort of exploration of the other options that are out there. It's really cool. 00:03:57.240 --> 00:03:57.540 Cool. 00:03:57.540 --> 00:03:59.520 You're also the release manager for 3.8, right? 00:03:59.520 --> 00:04:05.880 Yes, I am. So far, it's going to look at as the most interesting release because it has a very, 00:04:05.880 --> 00:04:12.000 very controversial PEP implemented in it. And at the same time, a rather boring release because now we 00:04:12.000 --> 00:04:16.540 cannot make any other decisions. So there's probably not going to be any more sort of fundamental 00:04:16.540 --> 00:04:17.480 features in it. 00:04:17.480 --> 00:04:20.700 It's quite ironic, isn't it? All right. Very, very cool. Brett, how about yourself? 00:04:20.700 --> 00:04:26.120 Yeah. So my name is Brett Cannon. I work at Microsoft as the dev lead on the Python extension 00:04:26.120 --> 00:04:30.380 for Visual Studio Code. In terms of my Python contributions, I've been a core developer 00:04:30.380 --> 00:04:38.220 since April 2003. So I think that's over 15 years at this point. Unlike both Wukash and Marietta, 00:04:38.220 --> 00:04:40.160 I am not writing a governance PEP. 00:04:40.860 --> 00:04:43.720 Although your name has been thrown around and related to that I've heard. 00:04:43.720 --> 00:04:47.500 Yes, that's true. But yeah, another reason why I'm not writing a governance PEP. 00:04:47.500 --> 00:04:52.920 Perfect. So Brett, why don't you kick us off with our main topic and just tell people what 00:04:52.920 --> 00:04:56.200 is this language summit that you guys have every year? 00:04:56.200 --> 00:05:04.080 Yeah. So basically, we came to a realization at PyCon, what feels like eons ago, that we didn't 00:05:04.080 --> 00:05:11.960 really ever have a chance to sit around as a development team and talk things out. And some 00:05:11.960 --> 00:05:17.060 people would think the sprints were that option. And they were, honestly, early on. But what happened 00:05:17.060 --> 00:05:22.020 was, is as Python's popularity grew and PyCon's own popularity grew, we had more and more people 00:05:22.020 --> 00:05:26.260 coming to us during the sprint saying, hey, I want to get started and contribute. Can you help me out? 00:05:26.340 --> 00:05:32.160 And basically, it's made it such that the sprints at various conferences are not a place for us to 00:05:32.160 --> 00:05:38.320 actually get work done, per se, as a team. So in order to make sure that happened, we carved out a 00:05:38.320 --> 00:05:43.680 day. It always happens at PyCon US during the first day of tutorials, where we get together in a room 00:05:43.680 --> 00:05:49.720 all day long and basically discuss things. Originally, it was kind of a round table-y kind of thing. It's 00:05:49.720 --> 00:05:55.320 slowly grown into a more structured. People come in with a presentation, typically with a question, 00:05:55.320 --> 00:06:01.600 or some specific reason why they're coming to talk about it and present to the room of core developers. 00:06:01.600 --> 00:06:06.340 And basically, it's just a good way for us to kind of hash out or have discussions about where we see 00:06:06.340 --> 00:06:10.480 things going. If we need a decision made, it's easier to make a decision in the room versus trying to do it 00:06:10.480 --> 00:06:17.640 over the mailing list, etc., etc. And I think it's been useful. Lukash and Marietta can answer that since 00:06:17.640 --> 00:06:22.360 they've been doing it far, as long as I think they've been core devs, and they're going to be leading it 00:06:22.360 --> 00:06:26.640 starting next year. So they can have more insight on how they see it going forward. 00:06:26.640 --> 00:06:30.580 Yeah. Sounds good. Do you guys want to add a little bit to what Brett said about the language summit? 00:06:30.580 --> 00:06:32.940 Sorry, you said you guys. You mean you all, right? 00:06:32.940 --> 00:06:33.320 Yes. 00:06:33.320 --> 00:06:38.540 Lukash, perhaps you can say more just because I've only been to two language summits. 00:06:38.540 --> 00:06:46.080 Yeah. So there's several language summits. In fact, we don't always do the European one at 00:06:46.080 --> 00:06:55.420 Europython. The one in the US at PyCon US is, as far as I can tell, an annual event, like as far as I remember. 00:06:55.420 --> 00:07:06.320 So the first one that I actually witnessed was either in 2008 or in 2009 at Europython. So I had a totally different 00:07:06.320 --> 00:07:29.100 sort of view of what that means because the European one was run by Michael Ford, who had a really sort of, you know, like, well, I don't want to use the word, but it was a really happy, hippie approach to like, you know, let's just come on in and, you know, discuss things as we go. 00:07:29.100 --> 00:07:37.920 Oh, you know, everything sort of organically grew, like, you know, people overflew with sort of ranty comments, but it was a very lively conversation. 00:07:37.920 --> 00:07:48.080 The language summits in the US on PyCon US have to be structured a little bit more because there's just way more of us in the room. 00:07:48.660 --> 00:08:10.460 So there is an agenda, there are talks, as Brett said, and whatnot. What I found, like, really amazing about this is that people who are really some of the most active contributors and some of the most senior contributors to Python and related projects are there in the room. So it's, it's something that even if you want it, you just can't buy. 00:08:10.460 --> 00:08:17.260 Yeah, it seems like such an amazing gathering of people. So do you have to be a core developer to attend? Or can anyone attend these? 00:08:17.260 --> 00:08:29.480 So, so far, at PyCon US, like, the rule has been as follows, like, if you are a core developer of CPython or any other alternative runtime, you are automatically in. 00:08:29.480 --> 00:08:38.880 If you are interested and you're in town that day, you can just sort of respond to the invitation and there's going to be a spot for you. 00:08:39.140 --> 00:08:45.420 There's also a few other ways in which you are, you can be present at the summit. 00:08:45.420 --> 00:08:53.980 If you are invited by a core developer to talk about a subject that is of interest to us, then obviously, you can get in. 00:08:53.980 --> 00:09:03.300 Or if you are a member of a project that is written in Python of some, like, notability, right? 00:09:03.400 --> 00:09:10.160 Like, historically, we've had people from the Twisted project, we've had people from the Mercurial project and whatnot. 00:09:10.160 --> 00:09:12.760 Sometimes the scientific stack and whatnot. 00:09:12.760 --> 00:09:19.640 So, definitely, there's some form of deliberate exclusivity to the event. 00:09:19.640 --> 00:09:33.740 But the point of it is mostly that we really have very little time in which we can actually see each other face to face and discuss things that are just way easier to be discussed when you see that other person. 00:09:34.100 --> 00:09:44.120 So, we don't want this to devolve into sort of bike shedding or, you know, like, story of my life sort of event for any random, you know, attendee of PyCon. 00:09:44.120 --> 00:09:45.300 Yeah, that makes a lot of sense. 00:09:45.300 --> 00:09:53.580 Because this is for you all to get together and really be productive and move the language and the runtimes forward, which I think is great. 00:09:54.000 --> 00:09:58.220 I guess the way I'd like to do this is let's just go through some of the various sessions. 00:09:58.220 --> 00:09:59.440 There were quite a few sessions. 00:09:59.440 --> 00:10:08.960 And there's a really nice write-up, actually, on lwn.net, which I'll link to the main write-up and then all the sub-articles about the sessions. 00:10:08.960 --> 00:10:11.140 And maybe we can just start there. 00:10:11.140 --> 00:10:14.900 So, I'm not sure which one of you is most familiar with each session. 00:10:14.900 --> 00:10:16.560 So, I'll let you all jump in. 00:10:16.980 --> 00:10:22.360 So, the first one I want to talk about, there was something with regard to sub-interpreters in Python. 00:10:22.360 --> 00:10:25.860 And I thought the whole concept of a sub-interpreter was pretty interesting. 00:10:25.860 --> 00:10:27.420 And what was the story this time? 00:10:27.420 --> 00:10:28.220 I can take that. 00:10:28.220 --> 00:10:31.620 So, that was presented by Eric Snow, teammate of mine on the Python extension. 00:10:31.620 --> 00:10:42.920 And basically, Eric was kind of giving a status update of what he's trying to do, which is basically CPython itself currently has the concept of sub-interpreters. 00:10:43.400 --> 00:10:48.760 It's used in the Apache web server, actually, for, I believe, ModPython. 00:10:48.760 --> 00:10:51.320 I don't think – I'm not sure if ModWiz uses it. 00:10:51.320 --> 00:10:57.640 But basically, it's a basic way to run multiple interpreters in a single process. 00:10:57.640 --> 00:10:59.480 But it's never really been built out. 00:10:59.480 --> 00:11:10.820 And so, Eric viewed this as a potential opportunity to deal with a concurrency model by trying to make sub-interpreters a first-class citizen of CPython itself. 00:11:11.400 --> 00:11:29.980 So, the idea is basically you will potentially eventually have a module in the Sard library that will allow you to actually create other sub-interpreters in the process, send data across to the sub-interpreters to then be worked on, send results back, and basically give you kind of a message passing style of concurrency. 00:11:30.120 --> 00:11:37.440 Is it a little bit like multi-processing but not as heavyweight in the sense that you don't share the data structures as much? 00:11:37.440 --> 00:11:37.900 Correct. 00:11:37.900 --> 00:11:39.720 Yeah, exactly. 00:11:39.720 --> 00:11:54.880 And a lot of Eric's work has been actually trying to tease out a lot of the global state that Sun's built over the Earth by accident and trying to compartmentalize them better so that it's very obvious what is connected to a specific interpreter. 00:11:54.880 --> 00:12:02.600 So, regardless of where the sub-interpreter work goes, it's been nice to kind of clean up that code to help centralize all the data structures and such. 00:12:02.860 --> 00:12:04.120 Yeah, that's really interesting. 00:12:04.120 --> 00:12:09.080 One of my first thoughts when I saw this, I mean, you were talking about in terms of concurrency, which is really interesting. 00:12:09.080 --> 00:12:11.780 My first thought went to compatibility, right? 00:12:11.780 --> 00:12:18.880 Could we take something that runs in Python 2 and somehow get it to stay closer to other code? 00:12:18.880 --> 00:12:20.320 Or is there any thought of that? 00:12:20.320 --> 00:12:21.720 Or is it more of a concurrency thing? 00:12:21.720 --> 00:12:24.160 It is very much a concurrency thing from our perspective. 00:12:24.160 --> 00:12:30.440 You Dropbox just did a blog post yesterday about how they transitioned from Python 2 to Python 3. 00:12:30.440 --> 00:12:36.820 And it sounds like they somewhat went down that road in their custom Python version of CPython. 00:12:37.380 --> 00:12:41.400 So, it sounds like it'd be definitely a potential way of doing it. 00:12:41.400 --> 00:12:52.740 But I think from Eric's perspective, with Python 2 hitting EOL January 1st, 2020, the amount of time he still has to put in it to make it work isn't going to be worth his while to look into that. 00:12:52.740 --> 00:12:55.740 But I'm sure someone could potentially make that work with a lot of effort. 00:12:55.740 --> 00:12:57.620 We don't want to encourage that behavior, do we? 00:12:57.620 --> 00:12:58.020 No. 00:12:58.020 --> 00:13:02.880 This portion of Talk Python To Me is brought to you by Linode. 00:13:02.880 --> 00:13:06.800 Are you looking for bulletproof hosting that's fast, simple, and incredibly affordable? 00:13:06.800 --> 00:13:11.740 Look past that bookstore and check out Linode at talkpython.fm/Linode. 00:13:11.740 --> 00:13:13.660 That's L-I-N-O-D-E. 00:13:13.660 --> 00:13:18.120 Plans start at just $5 a month for a dedicated server with a gig of RAM. 00:13:18.120 --> 00:13:20.660 They have 10 data centers across the globe. 00:13:20.660 --> 00:13:23.160 So, no matter where you are, there's a data center near you. 00:13:23.800 --> 00:13:38.500 Whether you want to run your Python web app, host a private Git server, or file server, you'll get native SSDs on all the machines, a newly upgraded 200 gigabit network, 24-7 friendly support, even on holidays, and a seven-day money-back guarantee. 00:13:38.500 --> 00:13:40.840 Do you need a little help with your infrastructure? 00:13:40.840 --> 00:13:47.080 They even offer professional services to help you get started with architecture, migrations, and more. 00:13:47.080 --> 00:13:50.180 Get a dedicated server for free for the next four months. 00:13:50.180 --> 00:13:53.000 Just visit talkpython.fm/Linode. 00:13:53.000 --> 00:14:00.340 How about the next session that you all covered was modifying the Python object model. 00:14:00.340 --> 00:14:04.860 This one came from someone outside of the core developer team, right? 00:14:04.860 --> 00:14:08.460 That is somebody that I actually invited to the Language Summit. 00:14:08.460 --> 00:14:20.060 It's Carl Shapiro, who works currently with Instagram on making Python sort of handle the next billion users for the social network. 00:14:20.060 --> 00:14:24.780 We've seen some tremendous growth over the years on Instagram. 00:14:24.780 --> 00:14:31.800 We are extremely grateful to have this runtime and be able to run the social network on it. 00:14:31.800 --> 00:14:40.600 In fact, in the year where we switched from Python 2 to Python 3, we've seen some crazy feature growth and user growth at the same time. 00:14:40.940 --> 00:14:45.660 And we actually switched the runtime version, like, you know, just sort of all in parallel. 00:14:45.660 --> 00:14:46.960 So that was pretty amazing. 00:14:46.960 --> 00:14:53.100 Yeah, I think that whole transformation is really a case study in how large organizations should do it. 00:14:53.100 --> 00:14:54.300 You guys did an awesome job there. 00:14:54.300 --> 00:14:54.680 Yeah. 00:14:54.740 --> 00:14:56.240 So this was a massive project. 00:14:56.240 --> 00:14:59.080 There's a bike on 20, what is it? 00:14:59.080 --> 00:14:59.860 17? 00:14:59.860 --> 00:15:01.000 I think it was 17, yeah. 00:15:01.000 --> 00:15:02.080 I think, yeah. 00:15:02.080 --> 00:15:03.620 Like a keynote about this. 00:15:03.620 --> 00:15:05.020 So I highly recommend it. 00:15:05.020 --> 00:15:06.720 It was a fun journey. 00:15:06.720 --> 00:15:15.040 However, like since then, like we've been seeing that like we are paying some of the price for things that we don't have to pay the price for. 00:15:15.540 --> 00:15:23.440 But at Instagram scale, like, you know, we're running many, many servers with the Django processes that actually serve users. 00:15:23.440 --> 00:15:30.360 So we observe that some of the things that the CPython interpreter is doing can be optimized the way. 00:15:30.360 --> 00:15:38.360 Or rather, we can change the interpreter in a way where those things can be sometimes pre-computed before runtime. 00:15:38.360 --> 00:15:43.840 Like they can be done like circa compile time, if you know what I mean, like for Python, right? 00:15:43.900 --> 00:15:49.920 Like obviously we are running like out of BYC files, which are, you know, created by the interpreter. 00:15:49.920 --> 00:15:56.160 So whatever we can do there, like, you know, instead of every time that we start up the process would be nice. 00:15:56.160 --> 00:16:08.680 In particular, Carl has a lot of background on various implementations of virtual machines for dynamic run time, dynamic like languages. 00:16:08.680 --> 00:16:12.440 Like for example, I don't know, like R2VM Dart and whatnot. 00:16:13.040 --> 00:16:19.940 So he has plenty of experience to know like where we could actually find pieces that we can optimize. 00:16:19.940 --> 00:16:34.200 And in particular, he presented ways in which, for example, we could use an observed fact that most objects in Python don't actually change their shape during runtime. 00:16:34.520 --> 00:16:54.480 So what that means in regular language is that when you're creating an instance at runtime in Python, Python doesn't have any expectation currently whether this instance is going to grow or, you know, remove attributes later on in the lifecycle of the object. 00:16:54.480 --> 00:17:02.420 It's very dynamically sort of built in the sense that you can just change those things as you go. 00:17:02.420 --> 00:17:04.400 You can add things not only to the objects. 00:17:04.400 --> 00:17:09.940 You can add things and remove things from the classes themselves, you know, like freely, like whenever you want. 00:17:09.940 --> 00:17:20.420 But in practice, what is happening is that a large majority of objects have all their state created and they're done their init methods. 00:17:20.420 --> 00:17:20.720 Right. 00:17:20.720 --> 00:17:25.520 You could almost use something like slots and like lock them down and make them more efficient. 00:17:25.520 --> 00:17:27.660 But people don't do that. 00:17:27.660 --> 00:17:29.740 They're not even actually recommended to do that, right? 00:17:29.840 --> 00:17:35.760 Yeah, so slots, in fact, is a very sort of implementation of what we would be after. 00:17:35.760 --> 00:17:43.880 What we would be after is more akin to the concept of hidden classes in JavaScript that V8 and a bunch of other runtimes implement. 00:17:43.880 --> 00:17:56.240 What that means is instead of storing your attributes on the object as a hash table, right, like in the sense that you can just add things and remove things, 00:17:56.400 --> 00:18:05.920 but then the cost of retrieving every attribute is rather high, what you can do is you can understand what the shape of the object, 00:18:05.920 --> 00:18:10.400 the shape meaning efficient data structure in memory so that it's no longer a hash table. 00:18:10.400 --> 00:18:20.540 It's simply consecutive array that you can just index, which has, you know, very nice property of, you know, having way faster access at runtime. 00:18:20.540 --> 00:18:24.940 And in fact, we experimented with stuff like this at Instagram. 00:18:24.940 --> 00:18:29.800 That actually did win us some nice, you know, improvements in performance. 00:18:29.800 --> 00:18:35.900 So that change was suggested as something that could be, in fact, implemented in a future version of Python. 00:18:35.900 --> 00:18:37.140 That's super interesting. 00:18:37.140 --> 00:18:43.080 Do you think some of these changes are going to make it into the Python, into the Python runtime, into CPython in the future? 00:18:43.080 --> 00:18:48.400 So definitely we need to be careful about, like, keeping Python what it is, right? 00:18:48.400 --> 00:18:54.220 So we don't want to become a bit more performant, but way less dynamic. 00:18:54.220 --> 00:18:59.400 Like, Python's entire success is built around the fact that it's very hackable, right? 00:18:59.400 --> 00:19:02.320 Like, you can change things as you go at runtime. 00:19:02.680 --> 00:19:09.340 And a lot of our day-to-day work is actually built on top of that frame of mind. 00:19:09.340 --> 00:19:13.740 Like, for example, like, if you're mocking things in Python, right? 00:19:13.740 --> 00:19:15.740 Like, during your unit test and whatnot. 00:19:15.740 --> 00:19:18.360 Like, this is a very dynamic feature. 00:19:18.360 --> 00:19:23.980 So, like, taking stuff like this away could potentially hurt, you know, our users. 00:19:23.980 --> 00:19:25.580 So we don't want to do that. 00:19:25.580 --> 00:19:25.940 Right. 00:19:25.940 --> 00:19:33.540 A 10% increase in performance is not worth the loss of unit testing capabilities or massive re-architectures. 00:19:33.540 --> 00:19:34.040 Absolutely. 00:19:34.040 --> 00:19:41.480 So what we want to do instead is for the kinds of things that don't sacrifice user-visible functionality, 00:19:41.480 --> 00:19:46.240 we want to have optimizations that actually let us do things faster. 00:19:46.240 --> 00:19:47.360 Do, like, do less work. 00:19:47.360 --> 00:19:49.700 If you can do less work, everybody wins. 00:19:50.040 --> 00:19:56.740 However, we also have another constraint in CPython that is maybe not always visible, 00:19:56.740 --> 00:20:06.880 which is that the runtime that we maintain has to be maintainable for the team that is actually in it for the long haul, right? 00:20:06.880 --> 00:20:13.180 So if you would drop a much more performant piece of runtime, you know, on our labs, 00:20:13.180 --> 00:20:17.700 we would thank you, but we would be also rather concerned about, 00:20:18.180 --> 00:20:20.780 what are we going to do with it now, you know? 00:20:20.780 --> 00:20:24.800 If this is a very brittle and complex piece of code, 00:20:24.800 --> 00:20:29.680 we need to take into account that we need to release the next version of Python 00:20:29.680 --> 00:20:31.480 and then the next version of Python, 00:20:31.480 --> 00:20:34.800 and there's going to be different platforms that we're going to have to run on. 00:20:34.800 --> 00:20:39.500 In fact, just today, I fixed a bug in black where people noticed that, 00:20:39.500 --> 00:20:41.800 oh, we cannot run on Android phones. 00:20:41.800 --> 00:20:44.020 You're like, I didn't test it on Android phones. 00:20:44.020 --> 00:20:49.000 I mean, seriously, like, are you formatting Python code on Android phones? 00:20:49.000 --> 00:20:52.900 Like, that didn't occur to me as an important feature, 00:20:52.900 --> 00:20:58.100 but people really have needs like this, and those needs change in time and whatnot. 00:20:58.100 --> 00:21:03.680 So the point I'm trying to make is that we do put a lot of weight 00:21:03.680 --> 00:21:08.500 to making sure that we understand the piece of software that we're maintaining, right? 00:21:08.940 --> 00:21:12.980 So there's definitely some compromise that we need to do there. 00:21:12.980 --> 00:21:17.020 We cannot bring in another million lines of code, you know, 00:21:17.020 --> 00:21:22.180 like from some benevolent contributor and then be left with maintaining that thing. 00:21:22.180 --> 00:21:22.720 So yes. 00:21:22.720 --> 00:21:25.920 This goes all back to Brett's thing about open source expectations 00:21:25.920 --> 00:21:28.400 and, you know, giving away puppies and things like that. 00:21:28.400 --> 00:21:28.760 Absolutely. 00:21:28.860 --> 00:21:32.080 But it sounds like there's some really interesting possible performance benefits. 00:21:32.080 --> 00:21:32.640 Yeah, that's cool. 00:21:32.640 --> 00:21:35.080 The next one up is the galectomy. 00:21:35.080 --> 00:21:36.880 Larry Hastings' galectomy. 00:21:36.880 --> 00:21:39.040 The attempt to remove the GIL. 00:21:39.040 --> 00:21:40.600 Marietta, you want to take this one? 00:21:40.600 --> 00:21:43.640 What I know is it doesn't seem like it's going to happen, 00:21:43.640 --> 00:21:47.840 but Larry had some issues with it. 00:21:47.840 --> 00:21:53.580 And I think he was looking to get inspiration from Carl's previous talk. 00:21:54.360 --> 00:21:58.620 But last time I checked from Larry, it doesn't seem like it's making any progress. 00:21:58.620 --> 00:22:03.040 Yeah, I think that's kind of the summary of this whole talk is like, 00:22:03.040 --> 00:22:06.040 I've been working on it, but it's not really going anywhere, right? 00:22:06.040 --> 00:22:08.640 I mean, the sub-interpreter thing that Brett mentioned, 00:22:08.640 --> 00:22:10.860 part of that attempt is to break free the GIL. 00:22:10.860 --> 00:22:12.300 We have multiprocessing. 00:22:12.300 --> 00:22:15.120 We have asyncIO, which is not really subject to the gill 00:22:15.120 --> 00:22:17.940 because of the way it works and things like that, 00:22:17.940 --> 00:22:20.100 at least if it's IO-bound, what you're awaiting. 00:22:20.800 --> 00:22:23.700 So I don't know, I'm not sure it's as necessary as it used to be, 00:22:23.700 --> 00:22:27.140 but it sounds like it didn't really go anywhere, right? 00:22:27.140 --> 00:22:27.600 No. 00:22:27.600 --> 00:22:31.220 That's too bad, but it's good to, I think it's a cool project 00:22:31.220 --> 00:22:34.280 and I really hope he makes progress, but it doesn't sound like it, right? 00:22:34.280 --> 00:22:34.700 Right. 00:22:34.700 --> 00:22:37.260 All right, so that was a pretty short update, but that's cool. 00:22:37.260 --> 00:22:39.220 Why don't you take the next one as well? 00:22:39.220 --> 00:22:41.380 Because did you actually do this presentation? 00:22:41.700 --> 00:22:47.340 Yes, so I proposed that we started using GitHub issues instead of Roundup, 00:22:47.340 --> 00:22:49.820 which is bugspython.org. 00:22:49.820 --> 00:22:55.100 So BPO bugspython.org is an instance of Roundup that we've been maintaining 00:22:55.100 --> 00:22:57.880 and it's been working for us, 00:22:57.880 --> 00:23:04.360 but I think our workflow could be better if we started using GitHub issues. 00:23:04.360 --> 00:23:09.720 Yeah, and Brett actually had helped drive the project to move CPython code. 00:23:10.200 --> 00:23:11.840 So the code is on GitHub already, 00:23:11.840 --> 00:23:14.460 but the issue tracking had been somewhere else, 00:23:14.460 --> 00:23:18.280 and so you were like, well, why not just in GitHub where it is, right? 00:23:18.280 --> 00:23:25.200 Exactly, and everything else on Python uses GitHub issue trackers except CPython, 00:23:25.200 --> 00:23:29.680 like our peps in GitHub, our dev guide workflow issues, 00:23:29.680 --> 00:23:32.440 everything is in GitHub already. 00:23:32.440 --> 00:23:40.020 So I think it's good to start to explore why don't we start using GitHub for CPython as well. 00:23:40.120 --> 00:23:41.000 I think it's a great idea. 00:23:41.000 --> 00:23:45.180 I think it's absolutely good thing that CPython code is on GitHub. 00:23:45.180 --> 00:23:47.740 I know it's just a source control system, 00:23:47.740 --> 00:23:54.740 but I think it opens up people's willingness to participate and interact with the code way more for being there. 00:23:54.740 --> 00:23:59.940 Yeah, and personally, I find it always odd that I have to jump from one interface to another, 00:23:59.940 --> 00:24:03.400 like looking at the issues in Roundup that looks very different, 00:24:03.600 --> 00:24:06.360 and then I have to go to GitHub to create my pull request. 00:24:06.360 --> 00:24:08.640 Like for me, it's distracting. 00:24:08.640 --> 00:24:09.520 Yeah. 00:24:09.520 --> 00:24:14.200 So I think it's one benefit that we get this unified experience, 00:24:14.200 --> 00:24:17.420 not having to jump from one place to another. 00:24:17.600 --> 00:24:21.500 And in fact, I've started writing a PEP for it, PEP 581. 00:24:21.500 --> 00:24:26.840 So that's our plan for starting using GitHub issues. 00:24:26.840 --> 00:24:32.980 And we've got to discuss more about this during the sprint a couple weeks ago. 00:24:32.980 --> 00:24:33.340 Yeah. 00:24:33.340 --> 00:24:42.340 Ezio actually went around and asked all other core developers who attended whether they would like to start using GitHub issues. 00:24:42.340 --> 00:24:50.280 And most people are okay, like plus zero, at least not totally opposing it. 00:24:50.460 --> 00:24:57.420 So I think we might, there's no decision yet because we don't have PDF to pronounce on this. 00:24:57.420 --> 00:24:59.880 Yeah, that's another session we're coming up on shortly. 00:24:59.880 --> 00:25:00.560 Yeah. 00:25:00.560 --> 00:25:03.340 Brett, since you were so involved in GitHub, what do you think about this? 00:25:03.340 --> 00:25:08.340 The main reason when we moved over to the Git repo, we didn't move the issues, was twofold. 00:25:08.340 --> 00:25:16.360 One was moving the repo over itself was a good amount of work just because we were moving from McEarrel to Git on top of hosting and all that. 00:25:17.000 --> 00:25:22.740 But also there were some initial knee-jerk pushback, like don't change too much underneath me. 00:25:22.740 --> 00:25:30.560 And so I basically just only had so much energy in the world because, I mean, the GitHub transition took two years. 00:25:30.560 --> 00:25:31.760 Like people don't realize this. 00:25:31.760 --> 00:25:34.560 It took about a year of discussion and a year of actually making it happen. 00:25:34.560 --> 00:25:38.100 So I can only imagine how much more time I would have added to do it. 00:25:38.100 --> 00:25:40.400 And how much potential pushback, right? 00:25:40.400 --> 00:25:41.100 Well, exactly. 00:25:41.100 --> 00:25:45.140 And I just only have so much time in the day to deal with pushback. 00:25:45.140 --> 00:25:48.540 And I got buy-in on the Git stuff, so I decided to not press my luck. 00:25:48.540 --> 00:25:53.500 I think there's definitely possibilities for having an improved workflow. 00:25:53.500 --> 00:26:00.740 Like a lot of the work Marietta has shown the team is possible using bots through Ms. Islington and the stuff she and I have done with Bedivere. 00:26:00.740 --> 00:26:05.040 Really show that a lot of workflows can get automated and made fairly cleanly. 00:26:05.040 --> 00:26:12.260 I do know there are some core developers, especially ones that have been around for quite a while, who are kind of attached around up in terms of certain feature sets. 00:26:12.720 --> 00:26:25.520 So my suspicion is if we can add the missing features that they have latched onto on Roundup and somehow mirror them as appropriate or find an alternative that gives them the same result that they're after. 00:26:25.520 --> 00:26:28.540 I think it's definitely a good idea. 00:26:28.540 --> 00:26:32.940 And in general, I'm for it because I live in GitHub already for work. 00:26:33.320 --> 00:26:35.740 And as Marietta said, everything else is over there already. 00:26:35.740 --> 00:26:39.100 So I'm definitely at least a plus zero to a plus one on this. 00:26:39.100 --> 00:26:39.740 Perfect. 00:26:39.740 --> 00:26:40.940 That sounds good. 00:26:40.940 --> 00:26:45.580 So, Lucas, the next one was shortening the Python release cycle. 00:26:45.580 --> 00:26:48.040 I suspect that might have had some input from you. 00:26:48.040 --> 00:26:48.860 Yeah, cool. 00:26:48.860 --> 00:26:49.620 Tell us about that one. 00:26:49.620 --> 00:26:56.020 I still do have this idea to attempt to talk about this on the next Language Summit. 00:26:56.120 --> 00:26:58.580 And maybe we're going to get somewhere there with it. 00:26:58.580 --> 00:27:09.780 But for now, I postponed it at least for 3.8 because currently there is nobody to work with on actually making a decision about it or not. 00:27:09.780 --> 00:27:10.020 Right. 00:27:11.100 --> 00:27:12.960 So what are we trying to decide? 00:27:12.960 --> 00:27:14.380 What was the idea about? 00:27:14.380 --> 00:27:19.720 Well, Python has a release schedule that is currently 18 months. 00:27:19.720 --> 00:27:20.040 Right. 00:27:20.040 --> 00:27:25.520 So every 18 months, every year and a half, we're going to get a new major release of Python. 00:27:25.520 --> 00:27:29.080 Like, you know, 3.7 was just out mid-year now. 00:27:29.080 --> 00:27:36.100 So, yeah, like, you know, add 18 months and you're going to get a new release of Python late next year. 00:27:36.100 --> 00:27:39.660 That'll be exactly when Python 2 goes out of support, right? 00:27:39.660 --> 00:27:40.160 Pretty much. 00:27:40.200 --> 00:27:41.840 Like, almost, yes. 00:27:41.840 --> 00:27:56.460 Like, I'm pushing this, like, a few weeks here and there so that we can, you know, have some more interesting, like, you know, cadence in terms of, you know, doing sprints during Python US and maybe having, like, our annual course sprints somewhere else. 00:27:56.460 --> 00:27:59.160 So we try to have those events productive. 00:27:59.160 --> 00:28:05.180 So, like, we're not super tight, like, to actually have, like, the release exactly every 18 months. 00:28:05.180 --> 00:28:07.000 Like, we always have some leeway. 00:28:07.200 --> 00:28:19.680 You know, for example, when we released Python 3.6, we had a course print at Facebook, which was just coinciding with the beta 1 release. 00:28:19.900 --> 00:28:33.600 So, like, we're not stabilizing the release. 00:28:33.600 --> 00:28:40.060 So, originally, that beta was supposed to happen, like, the week before the sprint. 00:28:40.060 --> 00:28:45.400 But that would make the sprint very, very boring and rather sad, you know? 00:28:45.520 --> 00:29:05.220 So, I talked with Ned, who is the release manager for 3.6 and 3.7, about just pushing it just a week and a half into the future so that we can actually sort of rally up during the sprint and finish up all the fancy features that maybe are just almost ready but not quite. 00:29:05.220 --> 00:29:12.880 And, in fact, as far as far as I can tell, that was the most productive week in the project's history, even up to today. 00:29:12.880 --> 00:29:16.140 We're trying to do this every time pretty much now. 00:29:16.700 --> 00:29:19.580 But why shorten the release cycle? 00:29:19.580 --> 00:29:37.860 Well, the problem with having a release every 18 months is that it builds up this mode of work where most of the time spent on the release is just vague ideas, like having things implemented and left, you know, in a state of there are things that need still to be done. 00:29:37.860 --> 00:29:50.380 And then the few weeks before the beta cut is sort of aggressive sprinting on making sure that we actually make it in time to, like, meet the deadline and have our feature shipped. 00:29:50.380 --> 00:29:57.440 But this doesn't really create a very healthy rhythm of development in my experience. 00:29:57.440 --> 00:30:05.520 And actually, working at Facebook, I learned that, you know, releasing early and releasing often, like, works very well. 00:30:05.520 --> 00:30:12.320 It does have a lot of good features, like, it does decrease the size of our release, right? 00:30:12.320 --> 00:30:21.980 Like, if we released, say, every six months, that would mean that Python 3.8 and 3.9 and 3.10 would have way fewer differences between them. 00:30:21.980 --> 00:30:26.440 So migrating between those releases would also be easier for the user. 00:30:26.440 --> 00:30:28.700 There is a price to pay, right? 00:30:28.700 --> 00:30:35.460 Like, now your tox matrix on your open source project is way bigger because there's more versions of Python. 00:30:35.460 --> 00:30:40.820 It pushes more work onto the release managers and so on and so on. 00:30:40.820 --> 00:30:44.000 So definitely something that people need to agree with. 00:30:44.000 --> 00:30:50.180 But I still believe that we would be better off having smaller releases that are released more frequently. 00:30:50.400 --> 00:30:52.900 That sounds good to me, especially the year thing. 00:30:52.900 --> 00:30:56.940 You could schedule the release to be in the fall or something. 00:30:56.940 --> 00:31:02.120 So you always have at PyCon sort of a sprint before the beta period closes. 00:31:02.120 --> 00:31:03.080 Things like that, right? 00:31:03.080 --> 00:31:04.500 For example, yes. 00:31:04.500 --> 00:31:07.040 Now it's kind of out of phase, basically. 00:31:07.040 --> 00:31:10.000 Every other year or something weird like that, right? 00:31:10.000 --> 00:31:11.300 So yeah, I think it makes a lot of sense. 00:31:11.300 --> 00:31:12.320 It makes it pretty predictable. 00:31:13.040 --> 00:31:16.660 The major tech conferences are in May and June. 00:31:16.660 --> 00:31:19.040 We know that Python releases in the fall. 00:31:19.040 --> 00:31:19.420 I don't know. 00:31:19.420 --> 00:31:20.280 Something like this, right? 00:31:20.280 --> 00:31:22.020 Like, that's just how it might go. 00:31:22.020 --> 00:31:27.240 This portion of Talk Python To Me has been brought to you by Rollbar. 00:31:27.240 --> 00:31:30.920 One of the frustrating things about being a developer is dealing with errors. 00:31:30.920 --> 00:31:35.960 Relying on users to report errors, digging through log files, trying to debug issues, 00:31:35.960 --> 00:31:39.920 or getting millions of alerts just flooding your inbox and ruining your day. 00:31:40.380 --> 00:31:44.700 With Rollbar's full-stack error monitoring, you get the context, insight, and control you 00:31:44.700 --> 00:31:46.680 need to find and fix bugs faster. 00:31:46.680 --> 00:31:50.660 Adding Rollbar to your Python app is as easy as pip install Rollbar. 00:31:50.660 --> 00:31:54.900 You can start tracking production errors and deployments in eight minutes or less. 00:31:54.900 --> 00:31:59.080 Are you considering self-hosting tools for security or compliance reasons? 00:31:59.080 --> 00:32:02.660 Then you should really check out Rollbar's Compliance SaaS option. 00:32:02.660 --> 00:32:07.160 Get advanced security features and meet compliance without the hassle of self-hosting, 00:32:07.480 --> 00:32:12.040 including HIPAA, ISO 27001, Privacy Shield, and more. 00:32:12.040 --> 00:32:13.420 They'd love to give you a demo. 00:32:13.420 --> 00:32:15.120 Give Rollbar a try today. 00:32:15.120 --> 00:32:18.800 Go to talkpython.fm/Rollbar and check them out. 00:32:20.940 --> 00:32:24.560 Next one is about unplugging old batteries, right? 00:32:24.560 --> 00:32:26.520 Python is said to come with batteries included. 00:32:26.520 --> 00:32:29.800 That means it has rich standard library and all sorts of stuff you can use. 00:32:29.800 --> 00:32:32.740 But every now and then, those go out of fashion. 00:32:32.740 --> 00:32:33.780 People stop using them. 00:32:33.780 --> 00:32:34.840 Like, what do you do then, right? 00:32:34.840 --> 00:32:35.880 Do you still have to maintain them? 00:32:35.880 --> 00:32:38.140 So who wants to take this one? 00:32:38.140 --> 00:32:40.100 I'll take it because it's been... 00:32:40.100 --> 00:32:42.340 I've been rummating on this in the back of my head for... 00:32:42.340 --> 00:32:44.100 It feels like a decade now. 00:32:44.500 --> 00:32:50.100 So this was a presentation by Christian Hamies. 00:32:50.100 --> 00:32:51.980 I'm going to butcher Christian's last name. 00:32:51.980 --> 00:32:52.520 I'm so sorry. 00:32:52.520 --> 00:33:01.920 Where he basically has a rough draft of a PEP where he has suggested some modules that we can potentially remove from the standard library. 00:33:02.840 --> 00:33:13.920 And we've done this once before in a large movement when we went from two to three where I actually personally went through and got a bunch of modules deprecated and removed. 00:33:13.920 --> 00:33:20.020 And the main reason we do this on occasion, some things just turn out to not be useful anymore. 00:33:20.020 --> 00:33:27.700 For instance, a good example is moving from Python two to three, we got rid of the gopher lib module because who runs gopher anymore? 00:33:27.700 --> 00:33:31.220 Heck, who even knows what gopher is, right? 00:33:31.220 --> 00:33:33.000 Yeah, gopher, that was one of the originals. 00:33:33.000 --> 00:33:33.540 They tell. 00:33:33.540 --> 00:33:35.500 I know what that gopher is. 00:33:35.500 --> 00:33:44.820 But the key thing here is there is a burden of cost of maintenance for every single module we have in the standard library. 00:33:44.820 --> 00:33:49.280 Even if it's just sitting there, there's still the cost of updating it. 00:33:49.280 --> 00:33:53.840 For instance, we just made async a proper keyword in 3.7. 00:33:53.840 --> 00:33:57.980 That means any module that was using async as a variable name had to be updated. 00:33:57.980 --> 00:34:00.240 There's potential bug reports. 00:34:00.460 --> 00:34:01.400 There's feature requests. 00:34:01.400 --> 00:34:08.920 Even if all those were ignored, they still take time because, for instance, when you go through and triage issues, you still have to see that it's an issue. 00:34:08.920 --> 00:34:09.760 You still have to read it. 00:34:09.760 --> 00:34:11.200 You still have to choose not to do it. 00:34:11.200 --> 00:34:15.500 So there is a time sink regardless of how much maintenance you actually put into it. 00:34:16.060 --> 00:34:24.740 So I personally have always wanted to kind of potentially scale back the amount of modules we have in the standard library because I don't think a lot of people realize we literally have hundreds. 00:34:24.740 --> 00:34:33.620 I wrote a really quick script the other day to count the number of .RST files in the library directory that had either letters, numbers, or underscores. 00:34:33.620 --> 00:34:36.300 And the count was 248. 00:34:36.880 --> 00:34:40.800 So that's a rough count of how many top-level modules there are in the standard library. 00:34:40.800 --> 00:34:43.900 I mean, that's not an insignificant number. 00:34:43.900 --> 00:34:47.560 And you have to remember that there are only 93 core developers in total. 00:34:47.880 --> 00:34:54.440 And over the past year, only 46 people across the globe have submitted a PR that got merged. 00:34:54.440 --> 00:35:04.300 So there's definitely a maintenance burden here where the amount of code to be maintained is not in a good ratio to the amount of people who are able to help keep it going. 00:35:04.300 --> 00:35:08.380 So Christian was basically saying, we got some modules we need to get rid of. 00:35:08.380 --> 00:35:16.260 A good example from Christian's PEP is, how many modules do you think there are specifically for processing sound files in the standard library? 00:35:16.260 --> 00:35:17.180 So there's three. 00:35:17.180 --> 00:35:17.800 There should be one. 00:35:18.200 --> 00:35:19.000 No, there's three. 00:35:19.000 --> 00:35:20.280 Yeah, there's three. 00:35:20.280 --> 00:35:24.020 There's AIFF for AIFC module. 00:35:24.020 --> 00:35:26.240 There's the SunAU module. 00:35:26.240 --> 00:35:28.060 And then there's the Wave module. 00:35:28.060 --> 00:35:28.360 Wow. 00:35:28.360 --> 00:35:29.480 Exactly. 00:35:29.480 --> 00:35:31.560 So why do we have this? 00:35:31.560 --> 00:35:34.040 Why do we even need this kind of thing in the standard library? 00:35:34.040 --> 00:35:42.420 So that was Christian's point, was there are some things that literally just don't have a purpose anymore because they were put in back when basically Guido accepted anything. 00:35:42.420 --> 00:35:47.300 Because there was no PyPI and there was no distribution model except CPython itself. 00:35:47.440 --> 00:35:47.600 Right. 00:35:47.600 --> 00:35:52.000 Now you can pip install the tools you need to work with MP3s or whatever it is. 00:35:52.000 --> 00:35:55.180 And why does that need to be part of the standard library, right? 00:35:55.180 --> 00:35:55.720 Exactly. 00:35:55.880 --> 00:36:01.700 And we've never had a discussion as a group to really come down with a set of guidelines of what should or should not be in the standard library. 00:36:02.660 --> 00:36:09.240 And unfortunately, as we keep alluding to, lack of governance means there's no one to have that discussion with at the moment. 00:36:09.240 --> 00:36:11.780 But it is something we're probably going to have to decide. 00:36:11.780 --> 00:36:16.540 Do we want to stay as heavily batteries included now that PyPI exists and is so solid? 00:36:17.000 --> 00:36:24.000 Do we want to scale it back and be more targeted towards what a potential script writer needs to maintain their machine? 00:36:24.000 --> 00:36:30.520 But as soon as they go past anything standard, they're just going to be expected to go and get it from PyPI. 00:36:30.520 --> 00:36:32.580 Yeah, that's an interesting idea. 00:36:32.820 --> 00:36:35.400 Like, I don't think, for instance, we would add argparsenecessarily today. 00:36:35.400 --> 00:36:43.560 We could have stayed with getopt or something simple and say, if your command line interface is going to get that complex, you need like get level subcommands and stuff. 00:36:43.780 --> 00:36:51.300 There's probably going to be something developed better on PyPI that you're going to want to grab versus something we should ship in the standard library that we have to maintain. 00:36:51.300 --> 00:36:55.600 And this is also, by the way, why we don't have requests in the standard library because it develops faster. 00:36:55.600 --> 00:36:58.760 But also pulling requests would also mean pulling Euralib 3. 00:36:58.760 --> 00:37:01.580 And it's just one thing that goes back to maintenance. 00:37:01.580 --> 00:37:11.120 How do we keep this sustainable and everyone happy with the code quality while not burning out from the fact that there are nearly 200 open issues against argparsealone? 00:37:11.360 --> 00:37:19.240 Right, and the release cycle as well being 18 months means, you know, a new HTTP thing comes out, right? 00:37:19.240 --> 00:37:24.380 It would take forever to get that actually into Python's main HTTP library, which would be weird. 00:37:24.380 --> 00:37:32.200 Yeah, so basically Christian's just saying we need to evaluate what's in there right now and make a decision of what really should still be there and what maybe should go out. 00:37:32.200 --> 00:37:40.120 And he's fairly conservative because, as I said, we've not had a conversation of general guidelines of what should qualify for something being in the standard library. 00:37:40.260 --> 00:37:41.340 Yeah, it makes a lot of sense to me. 00:37:41.340 --> 00:37:46.620 Like, I have no expectation that I can write a proper web app without going to PyPI and using pip. 00:37:46.620 --> 00:37:48.040 It just doesn't make sense. 00:37:48.040 --> 00:37:51.200 But there's obviously the compatibility thing, right? 00:37:51.200 --> 00:37:54.240 You don't want to rip out things that someone might be using and break them. 00:37:54.240 --> 00:37:55.640 So, definitely worth considering. 00:37:55.640 --> 00:38:02.520 Another thing that Christian did was talk about Linux distributions and Python 2 and with the end-of-life Python 2 coming. 00:38:03.260 --> 00:38:06.040 How are distributions that ship Python 2 going to deal with that? 00:38:06.040 --> 00:38:08.880 Let's keep moving because I think we have some more that are more relevant. 00:38:08.880 --> 00:38:10.500 But I think, you know, people can read up on that. 00:38:10.500 --> 00:38:11.200 That's pretty interesting. 00:38:11.200 --> 00:38:14.780 Lucas, maybe you should take this one because I know you do so much with static typing. 00:38:14.780 --> 00:38:17.680 The next session was an update on Python static typing. 00:38:17.680 --> 00:38:20.340 Static typing is still very much in progress. 00:38:20.340 --> 00:38:24.060 There's a bunch of things that is happening with it. 00:38:24.060 --> 00:38:36.800 One of the things that was discussed was how should we package external typing information for projects which are themselves not typed yet? 00:38:36.800 --> 00:38:44.380 Or if they want to be typed now, how do we expose this information to the type checker like mypy? 00:38:44.380 --> 00:39:04.200 In fact, this is one of the reasons why TypeScript and its ecosystem is so successful because the equivalent there, the definitely typed website and the related integration with npm that the types provide has proven very successful. 00:39:05.280 --> 00:39:11.400 So Ethan has been working on PEP about this, PEP 561. 00:39:11.400 --> 00:39:19.000 And as far as I can tell, it's already landed and PyPI already has the required support for it and whatnot. 00:39:19.000 --> 00:39:35.740 So in the future, we are going to be able to slowly move away from the model where TypeShed, the repository and the library shipped with mypy and other type checkers, is the sort of library of the collection of types for the entire world. 00:39:35.740 --> 00:39:38.300 That's obviously very hard to maintain. 00:39:38.300 --> 00:39:40.280 That's obviously very hard to do well. 00:39:40.280 --> 00:39:44.720 So we would like to decentralize where the stops are held. 00:39:44.720 --> 00:39:45.960 Yeah, that makes a lot of sense. 00:39:45.960 --> 00:39:57.480 Like shipping them with, say, when you pip install, if I say pip install SQLAlchemy, it would be great if the stub file that defined the types just came as part of that just landed on my file system. 00:39:57.480 --> 00:39:58.560 I didn't have to think about it. 00:39:58.560 --> 00:39:58.840 Yeah. 00:39:58.840 --> 00:40:01.620 So there were a few other updates. 00:40:01.620 --> 00:40:02.820 I want to be like short now. 00:40:02.820 --> 00:40:05.480 So like I don't actually steal the entire episode. 00:40:05.480 --> 00:40:16.720 But there's a number of other peps that were typing related, like PEP 560 moved some of the typing functionality into the core interpreter so that it's now way faster. 00:40:17.100 --> 00:40:27.920 And PEP 563, very dear to my heart, was about making the typing module a bit more usable in terms of just, I don't know, aesthetics, right? 00:40:27.920 --> 00:40:40.320 Like enabling things like forward references for classes, which means you can actually use a type of a class within that class or before that class is even defined and whatnot. 00:40:40.860 --> 00:40:44.480 And the most interesting probably is 544, which is protocols. 00:40:44.480 --> 00:40:49.140 So like duck typing for static type checkers. 00:40:49.140 --> 00:40:51.600 This was a rather long presentation and whatnot. 00:40:51.600 --> 00:40:53.540 Like I find this top interesting. 00:40:53.540 --> 00:40:57.280 So, you know, we can do an entire episode on that alone. 00:40:57.280 --> 00:40:57.960 Yeah, absolutely. 00:40:57.960 --> 00:41:02.900 And the idea with protocols being that's kind of the way Python type system works. 00:41:02.900 --> 00:41:06.180 Like as long as I can call this function and it has this field, like we're good. 00:41:06.180 --> 00:41:13.540 And so this is like bringing that into the type annotations world saying, well, whatever you pass here, it has to have this attribute and this method, right? 00:41:13.540 --> 00:41:14.720 Something to that effect. 00:41:14.720 --> 00:41:15.540 Yeah, nice. 00:41:15.540 --> 00:41:16.380 Yes, exactly. 00:41:16.380 --> 00:41:21.380 There was a discussion on whether virtual environments are serving us well, especially around the teaching. 00:41:21.680 --> 00:41:27.140 Brett, this one actually features Steve Dower, your colleague at Microsoft. 00:41:27.140 --> 00:41:28.200 So tell us about it. 00:41:28.200 --> 00:41:28.560 Yeah. 00:41:28.560 --> 00:41:35.800 So I believe there's actually already a pip now up on the proposal. 00:41:35.800 --> 00:41:42.780 Basically, if you follow certain people on Twitter, one of the common issues they have is trying to explain virtual environments to beginners. 00:41:42.780 --> 00:41:48.960 And part of that's because pip automatically installs to your global environment and your user environment by default. 00:41:49.520 --> 00:41:52.140 There's a long running issue on pip to change that default. 00:41:52.140 --> 00:41:52.780 That would be nice. 00:41:52.780 --> 00:41:53.020 Yeah. 00:41:53.020 --> 00:41:54.940 Feel free to comment on that issue. 00:41:54.940 --> 00:41:55.620 I'm sure they love it. 00:41:55.620 --> 00:42:04.100 Basically, virtual environments are really what everyone wants, but it's an extra level of work to try to explain how that functions. 00:42:04.100 --> 00:42:17.840 And Steve Dower and Kuchel Dauer and various other people got into a conversation over this, where the idea of more or less having something equivalent to node modules directory came up. 00:42:17.840 --> 00:42:20.460 The current name is proposed as Dunderpy packages. 00:42:21.240 --> 00:42:25.340 And basically, the idea is your dependencies should be installed in the local directory. 00:42:25.340 --> 00:42:29.960 And Python would more or less add that to your system path by default. 00:42:29.960 --> 00:42:36.240 And you would teach tools of pip to just install in there when appropriate. 00:42:36.240 --> 00:42:38.280 And that's it. 00:42:38.280 --> 00:42:39.620 It's a fairly simple concept. 00:42:40.060 --> 00:42:45.280 Right now, once again, no governance means it really hasn't been discussed beyond getting the pepper written. 00:42:45.280 --> 00:42:56.980 But probably the discussion is going to end up revolving around whether that is enough to warrant the added complexity of having this yet another way to specify where your dependencies can live. 00:42:57.540 --> 00:42:59.680 And does it solve enough of the problem? 00:42:59.680 --> 00:42:59.940 Right. 00:42:59.940 --> 00:43:09.200 Are you just changing one hard way to explain things for another and then making it worse by having pip ENV, pip, this other way, virtual environments? 00:43:09.200 --> 00:43:11.040 It's like, ah, can't take it anymore. 00:43:11.040 --> 00:43:11.660 Exactly. 00:43:11.660 --> 00:43:20.580 So that's going to be the real question, I think, is does it solve the case for enough people to warrant the cost of introducing yet another way to do this? 00:43:20.580 --> 00:43:24.040 Because virtual environments won't go away because they do serve a purpose. 00:43:24.040 --> 00:43:32.580 It's whether or not this will simplify it for 90, 95% of the world and that last 5% are going to be advanced users who will know how to use virtual environments. 00:43:32.580 --> 00:43:41.820 Or do we just have to push the tooling to just get better to make it easier to work with virtual environments as it's such as pipenv or something else? 00:43:41.820 --> 00:43:44.240 Yeah, I don't know exactly what the right answer is. 00:43:44.240 --> 00:43:44.240 It's a tough question. 00:43:44.240 --> 00:43:50.640 But it's, I feel like no matter which of the options you choose, they're not quite there. 00:43:50.640 --> 00:43:52.020 They're close. 00:43:52.560 --> 00:43:57.260 I use just virtual environments straight up with pip and it's all good, a V&V module. 00:43:57.260 --> 00:43:59.500 But still, I hear you. 00:43:59.500 --> 00:43:59.960 Very interesting. 00:43:59.960 --> 00:44:05.900 Okay, so I think we have time for just two more where we're getting close to the end of our time we have together. 00:44:05.900 --> 00:44:08.900 So the next one, I'll let whoever wants this take it. 00:44:08.900 --> 00:44:11.800 This is PEP 572. 00:44:11.800 --> 00:44:18.640 That was the big in-line assignment PEP that caused a lot of grief and Keto stepped down over. 00:44:18.900 --> 00:44:21.620 And now what are we going to do in terms of decision making? 00:44:21.620 --> 00:44:24.860 And it sounds like almost everything we've talked about hinges upon this. 00:44:24.860 --> 00:44:25.520 Who wants it? 00:44:25.520 --> 00:44:28.940 Well, I see everyone's leaping up to take the lead on this discussion. 00:44:28.940 --> 00:44:30.460 This one's a hot potato, man. 00:44:30.460 --> 00:44:31.140 No one wants this. 00:44:31.140 --> 00:44:31.580 All right. 00:44:31.580 --> 00:44:32.520 So, yeah. 00:44:32.520 --> 00:44:33.300 I can do it. 00:44:33.300 --> 00:44:33.680 It's fine. 00:44:33.900 --> 00:44:35.240 So, basically, it was a discussion. 00:44:35.240 --> 00:44:38.280 This was – so, the language sub button happened in May. 00:44:38.280 --> 00:44:41.020 Guido stepped down, I believe, in July. 00:44:41.020 --> 00:44:48.040 So, this all predated Guido taking his indefinite vacation as BDFL. 00:44:48.040 --> 00:44:55.160 And, basically, it was a discussion of what can we do going forward to manage our PEP process better? 00:44:55.160 --> 00:45:08.380 Because PEP 572, which is assignment expressions, was a very, as Michael alluded to, a very hot topic where a lot of things were discussed on Python ideas. 00:45:09.180 --> 00:45:11.300 And, clearly, it got resolved. 00:45:11.300 --> 00:45:13.220 And it was actually a reasonable discussion. 00:45:13.220 --> 00:45:16.440 And then it went to Python dev as part of the PEP process. 00:45:16.440 --> 00:45:17.860 And it all got rehashed yet again. 00:45:17.860 --> 00:45:21.200 And, actually, it got a little – I don't want to say pushy is quite the right word. 00:45:21.200 --> 00:45:22.540 But it got a bit more vehement. 00:45:22.540 --> 00:45:26.260 And some people were making rather grandiose statements. 00:45:26.260 --> 00:45:32.940 Like, at one point, I think someone, a core dev, said, if this gets emerged, I will refuse to review any PR that uses this feature. 00:45:32.940 --> 00:45:36.020 Like, it got really – I personally think overblown. 00:45:36.400 --> 00:45:41.980 And, which is partially why Guido just said, I never want to have to fight this hard to defend my decisions ever again. 00:45:41.980 --> 00:45:42.940 I'm taking vacation. 00:45:42.940 --> 00:45:51.600 So, this was mainly a discussion of what can we do to try to get the PEP process to not be so burdensome while keeping it, obviously, for our needs of recording history. 00:45:51.600 --> 00:45:57.040 Making sure we don't have to have discussions about every single solitary suggestion someone has. 00:45:57.040 --> 00:46:04.500 And try to find a good balance of load versus, basically, proper gatekeeping to make sure we don't feel overloaded. 00:46:04.500 --> 00:46:05.460 Yeah, that's definitely important. 00:46:05.560 --> 00:46:14.420 I guess, just to add, I think it's also something we are all looking into improving in our governance PEPs. 00:46:14.420 --> 00:46:23.720 We want to try to look into how the PEP process has been going in the past and whether there are things we can improve on how to make decisions. 00:46:23.720 --> 00:46:28.240 And as well as where should discussions happen. 00:46:28.240 --> 00:46:31.580 Those are also being discussed in the governance PEPs. 00:46:31.580 --> 00:46:31.840 Yeah. 00:46:31.980 --> 00:46:32.220 Okay. 00:46:32.220 --> 00:46:33.340 That's an important one. 00:46:33.340 --> 00:46:37.120 All right, Marietta, I'm going to give you the last one because we are out of time. 00:46:37.120 --> 00:46:44.380 But we got about three minutes to talk about a pair of presentations, one of which you gave about mentoring and diversity in Python. 00:46:44.380 --> 00:46:45.980 Want to give us the wrap on that? 00:46:46.160 --> 00:46:46.420 Yes. 00:46:46.420 --> 00:46:52.280 So, basically, the whole core team has been trying to improve our diversity. 00:46:52.280 --> 00:46:59.520 If you remember a few years ago, there was no women at all in the language summit itself. 00:46:59.820 --> 00:47:17.600 But this year, we're trying to improve our diversity among our own contributors team. 00:47:17.600 --> 00:47:20.960 And I shared some ideas. 00:47:20.960 --> 00:47:26.040 I got some ideas from Sage and shared that with the core developers. 00:47:26.040 --> 00:47:29.380 So, we've been doing some things. 00:47:29.380 --> 00:47:34.740 I know Guido himself mentored a few women who now are core developers. 00:47:35.740 --> 00:47:38.980 I know Victor himself is looking. 00:47:38.980 --> 00:47:41.780 He told me he's looking for women to mentor. 00:47:41.780 --> 00:47:47.760 And we have set up office hours over in Zulip. 00:47:47.760 --> 00:47:48.920 And I know Zach. 00:47:48.920 --> 00:47:56.960 Zach, where he has a calendar where people can sign up to get one-on-one mentorship with him. 00:47:57.560 --> 00:48:08.380 All of these are all ways we are trying to do in making it to lower barrier into contributing, welcoming more underrepresented people. 00:48:08.380 --> 00:48:12.240 I would love to see more diversity in the core developer team. 00:48:12.240 --> 00:48:14.940 But also, it's just good for the community overall, I think. 00:48:14.940 --> 00:48:15.860 Absolutely, yeah. 00:48:15.860 --> 00:48:19.260 Can we make sure we put those links in to the show notes? 00:48:19.260 --> 00:48:20.580 Like, if you help me get those links. 00:48:20.580 --> 00:48:26.260 So, people out there who may want to contact these folks to get mentorship or consider this process. 00:48:26.260 --> 00:48:27.100 For sure, yes. 00:48:27.180 --> 00:48:29.240 So, we do have the core mentorship mailing list. 00:48:29.240 --> 00:48:29.880 I will share. 00:48:29.880 --> 00:48:35.340 And if you look at the dev guide, there is a link for core developers office hours there. 00:48:35.340 --> 00:48:36.740 But I will share the links. 00:48:36.740 --> 00:48:37.000 Great. 00:48:37.000 --> 00:48:37.400 Thank you. 00:48:37.400 --> 00:48:38.540 All right. 00:48:38.540 --> 00:48:41.720 I think we have to leave it there because we're on a schedule. 00:48:41.720 --> 00:48:42.580 Can't just talk forever. 00:48:42.580 --> 00:48:44.380 So, thank you all for being here. 00:48:44.380 --> 00:48:48.340 Marietta, Lucas, Brett, thank you for sharing this whole experience. 00:48:48.340 --> 00:48:52.260 And I'm looking forward to hearing about the 2019 Language Summit when it happens. 00:48:52.260 --> 00:48:53.200 Thank you so much. 00:48:53.200 --> 00:48:53.940 Thanks, Michael. 00:48:53.940 --> 00:48:54.360 You bet. 00:48:54.360 --> 00:48:54.840 Bye, everyone. 00:48:54.840 --> 00:48:55.240 Bye. 00:48:56.800 --> 00:48:59.640 This has been another episode of Talk Python To Me. 00:48:59.640 --> 00:49:05.240 Our guests on this episode have been Marietta Wijaya, Lucas Lenga, and Brett Cannon. 00:49:05.240 --> 00:49:08.540 And this episode has been brought to you by Linode and Rollbar. 00:49:08.540 --> 00:49:12.340 Linode is bulletproof hosting for whatever you're building with Python. 00:49:12.880 --> 00:49:16.720 Get four months free at talkpython.fm/linode. 00:49:16.720 --> 00:49:18.520 That's L-I-N-O-D-E. 00:49:18.520 --> 00:49:21.280 Rollbar takes the pain out of errors. 00:49:21.280 --> 00:49:29.000 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. 00:49:29.660 --> 00:49:30.660 As Talk Python To Me. 00:49:30.660 --> 00:49:36.060 As Talk Python To Me listeners, track a ridiculous number of errors for free at rollbar.com slash talkpythontome. 00:49:36.060 --> 00:49:38.100 Want to level up your Python? 00:49:38.500 --> 00:49:45.140 If you're just getting started, try my Python jumpstart by building 10 apps or our brand new 100 days of code in Python. 00:49:45.140 --> 00:49:48.940 And if you're interested in more than one course, be sure to check out the Everything Bundle. 00:49:48.940 --> 00:49:51.180 It's like a subscription that never expires. 00:49:51.180 --> 00:49:53.380 Be sure to subscribe to the show. 00:49:53.380 --> 00:49:55.580 Open your favorite podcatcher and search for Python. 00:49:55.580 --> 00:49:56.820 We should be right at the top. 00:49:56.820 --> 00:50:06.140 You can also find the iTunes feed at /itunes, Google Play feed at /play, and direct RSS feed at /rss on talkpython.fm. 00:50:06.140 --> 00:50:08.000 This is your host, Michael Kennedy. 00:50:08.000 --> 00:50:09.360 Thanks so much for listening. 00:50:09.360 --> 00:50:10.440 I really appreciate it. 00:50:10.440 --> 00:50:12.380 Now get out there and write some Python code. 00:50:12.380 --> 00:50:33.000 I'll see you next time.