WEBVTT 00:00:00.001 --> 00:00:04.280 Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to 00:00:04.280 --> 00:00:11.420 your earbuds. This is episode 206. Wow. Recorded October 28th, 2020. I am Brian Okken. 00:00:11.420 --> 00:00:12.260 And I'm Michael Kennedy. 00:00:12.260 --> 00:00:14.380 Yeah. And we have a special guest today, Steve Dower. 00:00:14.380 --> 00:00:15.580 Hi. Thanks for having me on. 00:00:15.580 --> 00:00:17.700 Hey, Steve. Thanks for coming. It's great to have you here. 00:00:17.700 --> 00:00:22.040 I also want to throw out that this is sponsored by Tech Meme Ride Home podcast. Check them out 00:00:22.040 --> 00:00:26.800 at pythonbytes.fm/ride. Steve, I'm sure many listeners know you, but maybe just give us 00:00:26.800 --> 00:00:31.860 the quick rundown. You do cool stuff at Microsoft, getting Python better on Windows and you're a core 00:00:31.860 --> 00:00:37.620 developer. Yeah. So my main day job is for Microsoft, where I work as basically a Python engineer, 00:00:37.620 --> 00:00:44.900 kind of a wide ranging resource to the company. So I haven't shipped anything in my own in a while, 00:00:44.900 --> 00:00:50.180 but I've had my fingers in a lot of Python related things that have gone out recently. So it's a lot 00:00:50.180 --> 00:00:53.300 of fun, a lot of bouncing around between different teams, getting to work with a lot of different 00:00:53.300 --> 00:00:58.860 people. And yeah, as you say, I'm a CPython core developer, one of the Windows experts on the team. 00:00:58.860 --> 00:01:04.180 I'm responsible for the builds that go up on python.org and just generally keeping Python running 00:01:04.180 --> 00:01:04.800 while on Windows. 00:01:04.800 --> 00:01:10.660 Yeah, that's awesome. And you've done some interesting talks like Python is okay on Windows actually, 00:01:10.660 --> 00:01:14.040 and talked about some of the popularity of it and how we as a community shouldn't 00:01:14.040 --> 00:01:19.240 discount it just because we might happen to be on a Mac or use Linux or whatever, right? A lot of 00:01:19.240 --> 00:01:25.120 people do Python on Windows. Yeah, yeah, the estimates vary. And every time I get new numbers, 00:01:25.120 --> 00:01:28.840 they seem to show up slightly different. So it's real hard to get a good fix on how many 00:01:28.840 --> 00:01:33.600 Python developers there even are in the world. I did get some numbers recently that I had a few 00:01:33.600 --> 00:01:38.220 people double check because they were saying there's like 20 million installs of Python on 00:01:38.220 --> 00:01:43.620 Windows in the entire ecosystem, which sounded like too many to me. So I had them double check. 00:01:43.620 --> 00:01:47.100 And then I had someone else double check. And they all came back saying, yeah, it's about that. 00:01:47.100 --> 00:01:51.560 So I'm like, okay, there's a lot of Python on Windows out there. But yeah, it doesn't show up 00:01:51.560 --> 00:01:56.220 in conferences doesn't show up on Twitter that much. And a lot of people just look at the packages that 00:01:56.220 --> 00:01:59.900 don't work and go, well, I guess it doesn't exist on Windows, because otherwise this package would 00:01:59.900 --> 00:02:04.560 work. And so you know, chicken and egg problem, right? Yeah, there's a lot of chicken and egg 00:02:04.560 --> 00:02:08.460 problems in the Python space. I mean, it's a beautiful place. But there are some of these weird chicken 00:02:08.460 --> 00:02:12.120 and egg ones. Yeah, it's weird. I've been using Python on Windows since I started Python. 00:02:12.300 --> 00:02:13.000 So have I. 00:02:13.000 --> 00:02:20.500 But one thing I haven't been using very much is enums. So that was an attempt at a transition. 00:02:20.500 --> 00:02:22.820 Why not, Brian? Tell us more. 00:02:22.820 --> 00:02:28.680 Actually, I've tried many times I've tried to use enums. And I actually just to be honest, 00:02:28.680 --> 00:02:34.480 I don't very much. And partly because I'm used to using enums in C and C++. And they're, 00:02:34.540 --> 00:02:40.760 they just will act like symbols in C and C++. They work pretty good. There is some weirdness 00:02:40.760 --> 00:02:46.380 with enums in Python. And I'm going to highlight an article called Making Enums, as always, 00:02:46.380 --> 00:02:53.500 arguably more Pythonic by Harry Percival. He starts it off by saying, I hate enums. So Harry's a funny 00:02:53.500 --> 00:03:01.600 guy. And this is a fairly hilarious look at why enums are frustrating sometimes. And then he presents a 00:03:01.600 --> 00:03:06.380 semi reasonable workaround, I think, to make them more usable. So what's wrong with enums? Well, 00:03:06.380 --> 00:03:15.140 he gives an example. And just as a simple enum with string values. And you can't directly if you 00:03:15.140 --> 00:03:21.260 try to compare one of the enum elements to the value, like the value gave like a similar string, 00:03:21.480 --> 00:03:27.200 it's not equal, it doesn't compare. But you can use a dot value or in the enum value. But that's, 00:03:27.200 --> 00:03:32.820 it's just weird. He also said, he kind of thinks it'd be neat if you could do a random choice of all 00:03:32.820 --> 00:03:37.680 the enum values, I think that would be neat. And you can't directly convert them to a list. There's 00:03:37.680 --> 00:03:44.500 just interacting with the enum type itself, or the class itself is, has problems. In the documentation, 00:03:44.500 --> 00:03:50.400 there is a suggestion that you can, with you can, instead of strings, use ints, and do an 00:03:50.400 --> 00:03:54.940 int enum, and it works a little better. And if you like it like that, but want strings, you can make 00:03:54.940 --> 00:04:01.820 your own string enum class. I'm not sure why they didn't just build this into the default, or, you know, 00:04:01.820 --> 00:04:09.120 one of the standard types anyway, but string enum is not there. But there's an example. And it sort of 00:04:09.120 --> 00:04:13.580 fixes a lot of stuff, but not everything. It doesn't, still doesn't allow for those direct 00:04:13.580 --> 00:04:19.220 comparisons. So the solution that Harry came up with is just kind of like the solution, the 00:04:19.220 --> 00:04:26.800 documentation says, derived from both enum type and str when you're creating your enum class. But then 00:04:26.800 --> 00:04:35.840 also define this little snippet of a dunder str method, so that the str method works better. And at 00:04:35.840 --> 00:04:41.360 that point, most of the stuff works that he wants to work. It still doesn't do random choice. But 00:04:41.360 --> 00:04:46.880 apparently, he's gotten over that a little bit. So I actually think this is really, this is still 00:04:46.880 --> 00:04:52.120 just a really small snippet, a little, like two lines of extra code to add to your enum types, 00:04:52.120 --> 00:04:55.300 make them a little bit more usable. So I think it's reasonable. 00:04:55.300 --> 00:05:02.200 If you're judging by, like, value add per character, this is awesome, because it makes working with 00:05:02.200 --> 00:05:05.920 the enumeration so much nicer, you can do like the natural things that you would expect, 00:05:05.920 --> 00:05:11.720 especially around testing and comparison. And it's like, also add a drive from str and just 00:05:11.720 --> 00:05:15.180 add a dunder str method. And you're good. Steve, what do you think about this? 00:05:15.180 --> 00:05:21.040 Yeah, I'd just add that the gotcha that you have by doing this is now you can have two values from 00:05:21.040 --> 00:05:26.420 different enums compare as equal, which as I recall from the original discussions was the reason this 00:05:26.420 --> 00:05:30.900 wasn't put in by default, say you've got a color enumeration and a fruit enumeration, 00:05:30.900 --> 00:05:37.940 is orange the same between the two? And I think the decision was made for enums to say no, it's not. 00:05:37.940 --> 00:05:42.680 If it's a fruit orange, it's different from the color orange. Making this change or using an int 00:05:42.680 --> 00:05:47.000 enum is going to make them equal. So as long as you're prepared to deal with that, which to be quite 00:05:47.000 --> 00:05:52.600 honest, every time I've reached for enums, I am much happier with string literals and quite comfortable 00:05:52.600 --> 00:05:56.400 with them matching equal. Yeah, but that is just one thing to watch out for. Usually it's about 00:05:56.400 --> 00:06:00.740 constraining the list of things like I know there's five things I want to make sure I don't like somehow 00:06:00.740 --> 00:06:06.400 mix up what those five are. I just want to go, you know, class dot and here's the five. Let my editor 00:06:06.400 --> 00:06:11.500 tell me which one of those it is. It seems like it's all that. So what do you think about if you overrode 00:06:11.500 --> 00:06:18.880 like if you added dunder EQ, dunder NEQ, so like the comparison would say it has to be this type of 00:06:18.880 --> 00:06:22.720 enumeration and the stir value has to match? Yeah, that would certainly deal with that. Gotcha. 00:06:22.720 --> 00:06:27.600 Again, when these were being designed, basically anything that gets designed and added to Python 00:06:27.600 --> 00:06:32.420 has a very large group of very smart people work through it. And, you know, as a result, 00:06:32.420 --> 00:06:36.580 things always get missed. So it's possible that one was just missed. It's also possible that 00:06:36.580 --> 00:06:42.720 someone did figure out a reason why that was also risky. And, and, you know, risky when you're 00:06:42.720 --> 00:06:46.620 developing one of the most popular languages in the world is just anything that might surprise 00:06:46.620 --> 00:06:51.140 anyone. So someone has deliberately designed around using enums everywhere, they're probably 00:06:51.140 --> 00:06:57.400 not going to be surprised. Someone who is using code and that developer has swapped out all of their, 00:06:57.400 --> 00:07:01.080 you know, they, they had a class with static variables and they turned it into an enum and 00:07:01.080 --> 00:07:06.020 now stuff breaks because of the defaults that were chosen for enum. That's the kind of thing that 00:07:06.020 --> 00:07:10.620 you're trying to avoid. And, you know, in a language that has anywhere between, you know, 00:07:10.620 --> 00:07:16.420 five and 20 million kind of regular users. But as a workaround, I mean, if you know where your enum is 00:07:16.420 --> 00:07:20.200 going to be used, there's a reason you can derive from string and it's exactly for stuff like this. 00:07:20.200 --> 00:07:25.340 Yeah. Thanks Harry for putting out there. That's quite a neat, a little bit of a advisor. And I'm so glad 00:07:25.340 --> 00:07:31.860 that we have Steve here because I picked some sort of semi internal type of pieces and I'm going to make 00:07:31.860 --> 00:07:36.940 some statements about it. And then Steve can correct me to make it more accurate. And also we get the 00:07:36.940 --> 00:07:41.160 core developers, but a perspective, not that you represent all core developers, but at least a 00:07:41.160 --> 00:07:47.480 slice. All right. So this next one I want to cover is that Python 3.10 will be 10% faster. And this is 00:07:47.480 --> 00:07:57.180 the 4.5 years in the making. So Yuri Stelovanov long ago did some work on optimizing, I think, 00:07:57.180 --> 00:08:04.420 what was it? Load attribute or was it load method, load call method. So about some of these load 00:08:04.420 --> 00:08:13.780 operations down at the CPython C eval level. And then Pablo Galindo, who's also a core developer 00:08:13.780 --> 00:08:20.040 and the Python 3.10, 3.11 release manager picked up this work. And now we have load method, 00:08:20.040 --> 00:08:27.140 call method and load global going faster. So basically there's some optimizations around 00:08:27.140 --> 00:08:34.100 those opcodes that make this much faster. And this idea apparently first originated in PyPy. 00:08:34.100 --> 00:08:41.500 PyPy. So I'm pretty excited to see that, you know, some simple internals that don't seem to change a 00:08:41.500 --> 00:08:44.300 whole lot of stuff might make this a lot faster. What do you think, Steve? 00:08:44.300 --> 00:08:49.440 This one is real. Like I was so excited about this when it was first being proposed. The basis of the 00:08:49.440 --> 00:08:55.420 idea is that Python keeps everything in dictionaries, which means every time you look up, you know, dot 00:08:55.420 --> 00:09:00.320 name of anything, it takes that name, makes it a string, turns it into a, like gets the hash value, 00:09:00.460 --> 00:09:05.420 looks it up in a dictionary, finds the value, maybe wraps that up in some extra stuff. Like if it's 00:09:05.420 --> 00:09:09.560 going to be a method, it's not stored as a method. You turn it into a method when you know what it's 00:09:09.560 --> 00:09:15.280 being kind of dotted through to get to, and then returns that. That's a whole lot of work. And if 00:09:15.280 --> 00:09:19.320 you're regularly calling the same method over and over again, why not cache it? 00:09:19.320 --> 00:09:22.400 That's the heart of this, right? It does that cache around load adder, right? 00:09:22.560 --> 00:09:26.660 Yeah, it does that cache. And the insight that Yuri had that he made work, and in fact, 00:09:26.660 --> 00:09:31.740 I think someone else had suggested it earlier and hadn't gotten it to work was what happens when 00:09:31.740 --> 00:09:37.380 things change? Because again, as I say, it's, we're designing language for many, many people do all 00:09:37.380 --> 00:09:41.940 sorts of weird things. And if you cache a method lookup, and then someone tries to monkey patch it, 00:09:41.940 --> 00:09:46.180 you know, we've now broken their code for the sake of an optimization, which, you know, is a no, 00:09:46.220 --> 00:09:51.440 in Pythons, like correctness beats performance. In every case, that's just the trade off that the 00:09:51.440 --> 00:09:55.620 language chooses to make. That's almost always what you want, right? Like, when would you want to be 00:09:55.620 --> 00:10:00.020 faster and wrong rather than slower and right? I'd be happy with faster and no monkey patching. 00:10:00.020 --> 00:10:06.300 But yes, yes, sure. Like faster and fewer restricted capabilities might be a really good trade off, 00:10:06.300 --> 00:10:11.160 but faster and wrong is not a good one. Yeah, we did some benchmarking and basically found that 00:10:11.160 --> 00:10:19.440 there was a way to track all dictionary updates in the entire runtime with a version tag that was not 00:10:19.440 --> 00:10:24.300 going to instantly overflow and not going to break everything. So it became really easy to say, 00:10:24.300 --> 00:10:30.520 has this dictionary changed since I last looked at it with one single value comparison? And so it looks 00:10:30.520 --> 00:10:37.080 at that value. If it has changed, it's going to do the full lockup again. 99.999% of the time it hasn't 00:10:37.080 --> 00:10:42.800 changed so it can give you the cached value and you saved big dictionary lookup, possibly error handling, 00:10:42.800 --> 00:10:49.020 descriptive protocol, all of this extra stuff that just adds so much weight to every operation. 00:10:49.020 --> 00:10:51.960 Yeah. And that's everywhere. I mean, that's everywhere in the language. 00:10:51.960 --> 00:10:52.860 Absolutely everywhere. 00:10:52.860 --> 00:10:57.600 That's fantastic. One of the things when I was first getting into Python that made me sort of have a sad 00:10:57.600 --> 00:11:05.600 face was realizing that having function calls was pretty expensive, right? Like having a big call chain, 00:11:05.600 --> 00:11:10.120 like actually the act of calling a function has a fair amount of overhead. When I wanted to break my 00:11:10.120 --> 00:11:14.100 code into like a bunch of small functions to make it real readable, this part needs to go a little 00:11:14.100 --> 00:11:20.060 faster. Maybe that's not what I want. You know? And so hopefully this helps with that as well. 00:11:20.060 --> 00:11:26.100 Yeah. That and vector call is another optimization that we got in recently. I think that might've been 00:11:26.100 --> 00:11:32.000 the pet 509 actually was vector call also designed to make that faster. Just removing some of the 00:11:32.000 --> 00:11:36.620 the internal steps for doing a function call. Fantastic. And it's like Brian said, this is 00:11:36.620 --> 00:11:42.120 everywhere. So that's everyone's going to benefit. This is fantastic. Yeah. Well, we would like to thank 00:11:42.120 --> 00:11:49.180 our sponsor. So this episode is brought to you by Tech Meme Ride Home podcast. This is a great podcast 00:11:49.180 --> 00:11:55.740 for more than two years and nearly 700 episodes. The Tech Meme Ride Home has been Silicon Valley's 00:11:55.740 --> 00:12:02.700 favorite tech news podcast. The Tech Meme Ride Home is a daily podcast only 15 to 20 minutes long and even 00:12:02.700 --> 00:12:09.460 and every day by 5 p.m. Eastern. It's all the latest tech news, but it's more than just headlines. 00:12:09.460 --> 00:12:15.020 You could get a robot to read your headlines. The Tech Meme Ride Home is all the context around the 00:12:15.020 --> 00:12:20.140 latest news of the day. It's all the top stories, the top posts and tweets and conversations about those 00:12:20.140 --> 00:12:26.040 stories as well as behind the scenes analysis. The Tech Meme Ride Home is the TLDR as a service. 00:12:26.040 --> 00:12:31.720 The folks at Tech Meme are online all day reading everything so that they can catch you up. Search 00:12:31.720 --> 00:12:38.100 your podcast app now for Ride Home and subscribe to the Tech Meme Ride Home podcast or visit 00:12:38.100 --> 00:12:43.300 pythonbytes.fm/ride to subscribe. Yeah. Thanks for sponsoring the show. And Brian, 00:12:43.300 --> 00:12:49.160 every day, like we do this once a week and it's a lot of work. These guys are on it. I could totally do 00:12:49.160 --> 00:12:53.640 this every day. If I didn't have another job, I would not have any problem with catching up on 00:12:53.640 --> 00:12:59.640 Python News Daily. So actually sounds quite lovely. I wonder how that podcast is doing now that not so 00:12:59.640 --> 00:13:06.720 many people are having to, you know, commute to and from work. That sounds like one of the things where 00:13:06.720 --> 00:13:12.400 you hope that you've, you've given people the excuse to tell their employer on my commute between 00:13:12.400 --> 00:13:17.780 four and 5 p.m. I can't do it. You know, I've logged off and go listen to a podcast during that time. 00:13:17.780 --> 00:13:22.080 I listen to podcasts while I'm, I realized I was missing out. So I started listening to podcasts 00:13:22.080 --> 00:13:28.060 while I'm doing my laundry. I do it when I'm, we're doing some doing dishes. I listen when I'm 00:13:28.060 --> 00:13:32.600 doing yard work, stuff like that. Yeah. I recently broke out some other older podcasts just to catch 00:13:32.600 --> 00:13:37.860 up on stuff with a big mess I had around the home. Like it's a long story with a new puppy that's not 00:13:37.860 --> 00:13:45.240 worth going into. Maybe I'll tell you guys after the show. It's pretty outrageous anyway. Yeah. And 00:13:45.240 --> 00:13:50.340 it's so enjoyable, but what I've actually found is shows like Python bites and right home that have 00:13:50.340 --> 00:13:55.020 like a bunch of short little things that you can just drop in and out of match a lot better. Now that 00:13:55.020 --> 00:13:58.900 people are not commuting so much, you can like do that 10 minutes while you're like folding laundry 00:13:58.900 --> 00:14:03.560 and get like a whole segment. And so I think he gets varied, but actually it's pretty interesting. 00:14:03.560 --> 00:14:08.180 And I think that they and us here are well positioned. Like talk Python has more of a dip 00:14:08.180 --> 00:14:12.260 than Python bites. Have you surveyed your listeners to find out what they're doing while they listen to 00:14:12.260 --> 00:14:17.640 you? No, not really. Everyone should tweet at these guys, Twitter. What were you doing when you were 00:14:17.640 --> 00:14:23.220 hearing this podcast? Yeah, that's awesome. I've got a few anecdotes, but nothing like a survey that 00:14:23.220 --> 00:14:27.980 would give me a proper answer. Steve, I think your next item is super, super interesting. And 00:14:27.980 --> 00:14:33.360 people speaking to Twitter, right? Like this whole conversation started as a, Hey, Twitter 00:14:33.360 --> 00:14:38.760 message. Like why did this happen? Well, let's ask Steve. Yeah. As you know, I spend a decent amount 00:14:38.760 --> 00:14:44.800 of time on Twitter. My handle there is Zuba, Z-O-O-B-A, which you'll probably never find in search if 00:14:44.800 --> 00:14:50.100 you're looking for my name, but that's where I am. I really like actually searching for what people 00:14:50.100 --> 00:14:54.400 are saying about Python on windows. It's kind of the most honest feedback you get when they think 00:14:54.400 --> 00:15:00.500 you're not listening. And so I go and listen. And one of these popped up, which was, Oh, I tried to 00:15:00.500 --> 00:15:07.160 install Python 3.9 newest release about a little bit under a month ago on my windows seven machine, 00:15:07.160 --> 00:15:12.560 and I couldn't install it. And since then, I've actually seen a few more posts. Someone managed to 00:15:12.560 --> 00:15:16.760 bypass the installer completely and get it all the way onto their windows seven machine and then found out 00:15:16.760 --> 00:15:21.960 it wouldn't run. Oh man. Yeah. And so the question was, I was like, why would you do this? Windows seven 00:15:21.960 --> 00:15:26.200 is still a fairly big platform. Why would you take it out? And you know, the answer was just a bit too 00:15:26.200 --> 00:15:30.800 long for a tweet, but someone, you know, kindly included Python bites in the reply. And so I said, 00:15:30.800 --> 00:15:38.700 Hey, I'll come on and talk about it. So let's do this topic. And the answer is multiple legal looking 00:15:38.700 --> 00:15:43.360 documents all come together and have to be read in parallel to figure out why we dropped it. 00:15:45.360 --> 00:15:50.500 Yeah. The small business owners know what I'm talking about. So one of those documents is PEP 11, 00:15:50.500 --> 00:15:56.780 one of the lowest number PEPs that we have, and it's titled removing support for little used platforms. 00:15:56.780 --> 00:16:04.780 The title was not originally about windows, but there is a section in that PEP that describes Python's 00:16:04.780 --> 00:16:12.980 policy for supporting windows on release day of 3.x.0, all the supported versions of windows covered by 00:16:13.360 --> 00:16:20.500 Microsoft support lifecycle will be supported by CPython. And that's on the 3.x.0 release date. 00:16:20.500 --> 00:16:27.200 So what that means is then you now have to go and look at Microsoft support lifecycle website and look 00:16:27.200 --> 00:16:32.060 up all of the different versions of windows to see which ones are still covered by support to that date. 00:16:32.060 --> 00:16:37.760 Windows seven fell out of extended support in January. There was quite a bit of noise about that 00:16:37.760 --> 00:16:43.260 because that means no more security patches, except Microsoft did do a couple more security patches 00:16:43.260 --> 00:16:48.680 because some really bad stuff was found, but that's largely stopped. Essentially, it's the point when 00:16:48.680 --> 00:16:54.040 the only people who get windows seven support are paying for it. And I assume they're paying large 00:16:54.040 --> 00:16:58.740 amounts of money for it. I don't actually know how much it costs, but that's the point where, you know, 00:16:58.740 --> 00:17:03.020 you bought it, but you don't get the free support anymore. So CPython follows that because 00:17:03.020 --> 00:17:08.460 no one is paying the core team to support Python on all of these platforms. And so it's, 00:17:08.460 --> 00:17:16.120 it seems like the fairest point to draw that line is at some point we have to say our volunteers can no 00:17:16.120 --> 00:17:21.820 longer keep a windows seven machine running. Even I can't keep a windows seven machine running safely 00:17:21.820 --> 00:17:26.480 because there's no security updates for it. How am I meant to develop Python on it? How am I meant to 00:17:26.480 --> 00:17:33.120 test Python on it? The burden there is too high for volunteers to handle. So we just say that's the 00:17:33.120 --> 00:17:37.800 point where it goes away. So because those two documents lined up, Windows eight actually dropped 00:17:37.800 --> 00:17:42.680 off a couple of years ago because the support lifecycle ended early for that to force everyone 00:17:42.680 --> 00:17:49.000 onto 8.1. Windows 8.1 has about three more years. So I think Python 3.12 will be the last one to support 00:17:49.000 --> 00:17:54.920 8.1. And then it's all Windows 10 or whatever comes out in the future. Yeah. Yeah. Windows 10 X or 00:17:54.920 --> 00:18:00.940 whatever they call it. That's a different one. That's the Xbox. Yeah. So I, you know, I think this makes a ton 00:18:00.940 --> 00:18:08.240 of sense. And two thoughts I had as you were laying out the case here. One is if you're running a Windows 00:18:08.240 --> 00:18:13.720 seven and you can't upgrade to even Windows eight or more recently Windows 10 or one of the server 00:18:13.720 --> 00:18:18.860 equivalents, right? I'm sure there's like a server equivalent, like Windows 2003 server. I don't know how 00:18:18.860 --> 00:18:22.800 long I supported, but whenever it goes out, it probably falls under that banner as well, right? Yeah. Windows 00:18:22.800 --> 00:18:28.180 server is a bit more interesting. Their life cycles tend to last longer, but historically, 00:18:28.180 --> 00:18:34.680 CPython has only kind of tied itself to the client operating systems. Gotcha. Oh, interesting. Okay. 00:18:34.680 --> 00:18:40.800 So to me, I feel like if you're running code or you're running systems that old, you must be running 00:18:40.800 --> 00:18:47.620 it because it's like some super legacy thing. So do you absolutely necessarily need to have the most 00:18:47.620 --> 00:18:53.000 cutting edge Python or whatever language? Like it's probably something that's 00:18:53.000 --> 00:18:59.040 that way because it's calcified and you probably don't need, or you probably shouldn't be putting 00:18:59.040 --> 00:19:03.140 like the newest, shiniest things on it. Right. That's that one. What do you think? 00:19:03.140 --> 00:19:09.540 Yeah. No, I totally agree with that. If that setup that you're running is so critical that you can't 00:19:09.540 --> 00:19:13.960 upgrade the operating system. How can you upgrade a language runtime? It's like, how can you upgrade 00:19:13.960 --> 00:19:18.780 anything on that? I feel like it's in the category of, please just don't touch it. It's over there. 00:19:18.780 --> 00:19:23.460 Just don't even walk by it. Leave it alone. We cannot have it break. Just leave it over there. 00:19:23.460 --> 00:19:28.520 Probably still has a PS2 keyboard plugged into it. Oh, it might with a little blue or pink round thing. 00:19:28.520 --> 00:19:32.920 Yeah, absolutely. The screen has probably got at least 16 colors. Yeah. And the monitor is probably 00:19:32.920 --> 00:19:38.620 really heavy. Windows seven. It's not that, it's not that old. Some of the, seriously, like the stuff is 00:19:38.620 --> 00:19:42.860 old and you probably don't want to touch it, right? Yeah, that's exactly it. It's all the motivation 00:19:42.860 --> 00:19:47.540 that you would have for updating to Python 3.9 from 3.8. And again, we're talking about a version 00:19:47.540 --> 00:19:53.120 that's only one year old. Like Python 3.8 is not that old and you desperately need to upgrade to 3.9. 00:19:53.120 --> 00:19:59.600 You even more desperately need to upgrade Windows. And there's just really, there really is no question 00:19:59.600 --> 00:20:05.360 about that. The same thing applies to early versions of Ubuntu. People running Ubuntu 14 or even 16 at this 00:20:05.360 --> 00:20:11.360 point, like need to be facing the same thing. And we have similar discussions around OpenSSL, 00:20:11.360 --> 00:20:20.320 where occasionally people will be, oh, I need Python 3.9 to run on OpenSSL 0.9. To which our answer is 00:20:20.320 --> 00:20:27.560 basically, that's pretty hot bleed. It's like, okay, I'm going to play the other side. I totally get the 00:20:27.560 --> 00:20:34.780 reasons. But I also get the questions because the users and the developers or the whoever's wanting 00:20:34.780 --> 00:20:41.220 to install Python, they usually don't get to choose what operating system they're using, but they do get 00:20:41.220 --> 00:20:47.780 to choose which version of Python they're using. So I do get said in some cases and in some cases, 00:20:47.780 --> 00:20:53.420 I totally understand where the question is coming. Yeah. We joke about how old these machines are and 00:20:53.420 --> 00:20:57.920 they're really not. Like people are setting up new machines, probably with Windows 7. They certainly 00:20:57.920 --> 00:21:02.560 were within the last year. And there's good legitimate reasons for that. And we're making 00:21:02.560 --> 00:21:06.120 fun of some of the apparent contradictions, but we're definitely not making fun of the people 00:21:06.120 --> 00:21:12.600 who have often been forced into these positions. But the reality is we can't afford as a volunteer team 00:21:12.600 --> 00:21:20.300 to maintain Python against unmaintained operating systems. And so the advice is stay on the previous 00:21:20.300 --> 00:21:25.880 version of Python that the latest version of Python that works for you. It's not going to break. We're 00:21:25.880 --> 00:21:31.140 not changing it. Anything new that comes up, security fixes will still come out. At some point, 00:21:31.140 --> 00:21:36.180 there just has to be a line drawn. And that's the point where we've chosen to draw it. The other thing 00:21:36.180 --> 00:21:40.340 I want to point out that we changed in this release, which people are more excited about is if you go to 00:21:40.340 --> 00:21:46.180 python.org to download Python for Windows, you get this real big obvious button up front that just says 00:21:46.180 --> 00:21:51.500 download for Windows or download now or something. As of Python 3.9, that's now getting the 64-bit 00:21:51.500 --> 00:21:56.640 version rather than the 32-bit version. For a long time, it's been 32-bit. The reason for that was 00:21:56.640 --> 00:22:01.920 compatibility. We knew a 32-bit one would run anywhere. When we put Python in the Windows store, 00:22:01.920 --> 00:22:07.160 that was 64-bit only. We kind of wanted to test the waters and see, hey, will people notice that we 00:22:07.160 --> 00:22:13.680 haven't put a 32-bit version here? Turns out no one did. And so when we got to 3.9, had that change, 00:22:13.900 --> 00:22:19.840 we made it 64-bit by default. So that has a flow and effect to the ecosystem. A lot of particularly 00:22:19.840 --> 00:22:25.660 data science packages would rather just do 64-bit only packages. Some of them certainly get theirs 00:22:25.660 --> 00:22:32.980 done first and not the 32-bit ones. So we expect to see some flow and impact from that just broader use 00:22:32.980 --> 00:22:36.160 of the 64-bit Python throughout the Windows ecosystem. 00:22:36.540 --> 00:22:41.480 Yeah, that's super cool. And just like the final thought I had was, you know, Django dropped Python 00:22:41.480 --> 00:22:47.180 2 and they're like, we were able to remove so much code and it is easier for new people to contribute 00:22:47.180 --> 00:22:52.100 because they don't have to write for two ecosystems. They write for one. NumPy did the same thing. And I 00:22:52.100 --> 00:22:57.860 feel like this is sort of the same story. Like you guys can just not worry about yet another older, 00:22:57.860 --> 00:23:02.220 outdated operating system and stay focused on what most people care about. 00:23:02.300 --> 00:23:07.520 One thing that someone did suggest in one discussion was why not dynamically light stuff up for the newer 00:23:07.520 --> 00:23:13.120 operating system? And the answer is we do that. And when we drop the older operating system, 00:23:13.120 --> 00:23:18.400 we get to delete about a hundred lines of code for each point where we do that. So it is, 00:23:18.400 --> 00:23:22.580 we get to do a cleanup. We get to say, oh, we don't have to dynamically check for this API, 00:23:22.580 --> 00:23:26.540 this API, load this, cache this, store that, call that, call this format. 00:23:26.700 --> 00:23:31.220 We can just condense that into, oh, we know that this API is there so we can use it 00:23:31.220 --> 00:23:37.900 and just reduce a lot of kind of effectively dead code on newer operating systems. 00:23:37.900 --> 00:23:38.300 Nice. 00:23:38.300 --> 00:23:44.200 Is that a pre-compile like hash if death sort of thing, or is it a runtime thing? Does it make a 00:23:44.200 --> 00:23:44.820 performance difference? 00:23:44.820 --> 00:23:49.840 It definitely makes a performance difference, though we try and minimize it. But again, there's, 00:23:49.840 --> 00:23:54.820 there's always some impact. It tends to be in operating system calls anyway. So you expect a bit of 00:23:54.820 --> 00:23:59.780 overhead. And so it's not going to add a significant kind of percentage overhead compared to whatever 00:23:59.780 --> 00:24:06.360 operation you're doing. But it does certainly add a lot of cognitive burden to someone who's reading 00:24:06.360 --> 00:24:07.080 the code. Sure. 00:24:07.080 --> 00:24:12.760 One example that we got to clean up recently, not in the, in a previous version was we had about, 00:24:12.760 --> 00:24:18.760 I think 70 or 80 lines of code to concatenate two path segments. And this is before Python's loaded. 00:24:18.760 --> 00:24:24.720 So we have to do this with the operating system, the API call up until windows seven, 00:24:24.720 --> 00:24:30.780 I think. So pre windows seven was not secure and it would, you know, buffer over runs, all sorts of 00:24:30.780 --> 00:24:36.400 horrible stuff, but it was the best available function there for handling certain cases. So we'd use it, 00:24:36.400 --> 00:24:42.100 but first we dynamically look for the newer safer one and call that soon as we dropped, I think Vista, 00:24:42.300 --> 00:24:47.840 we could delete all of that code and just unconditionally call the one safe path combined 00:24:47.840 --> 00:24:51.120 function. And that code got a whole lot simpler. 00:24:51.120 --> 00:24:52.500 Yeah. Lovely. That's awesome. 00:24:52.500 --> 00:24:53.620 Yeah. Cool. 00:24:53.620 --> 00:24:55.340 Brian, would you say it's more robust now? 00:24:55.340 --> 00:25:02.460 Yes. I think it would be more robust. Actually, I thought I showed up to the bash podcast. Is this 00:25:02.460 --> 00:25:03.260 the Python podcast? 00:25:03.260 --> 00:25:05.140 Yeah, this is not as bash bites. 00:25:05.140 --> 00:25:11.780 Okay. I love Python. Of course, I still use bash regularly. And I know a lot of people that are, 00:25:12.260 --> 00:25:17.120 like sysops people and other people are using bash daily as well. So I wanted to highlight this 00:25:17.120 --> 00:25:22.600 cool article. This is an article by David Paschley called writing robust bash shell scripts. 00:25:22.600 --> 00:25:28.620 And even though I've been writing scripts for decades, I learned a whole bunch in this and I'm 00:25:28.620 --> 00:25:33.260 going to start changing the way I do things right away. The first two tips right away are things I'm 00:25:33.260 --> 00:25:40.060 going to do. First tip is to include a set dash you and never even heard of this. What it does is it 00:25:40.060 --> 00:25:47.060 makes your bash script exit if it encounters an uninitialized variable. So the problem without 00:25:47.060 --> 00:25:53.900 this is like, let's say you're constructing a path name or something or a path, a long path. And one of 00:25:53.900 --> 00:26:01.720 the directories or file names you have in a variable, if that's never set, a bash normally just silently just 00:26:01.720 --> 00:26:07.880 deletes it and it's just not there. And it'll still keep executing anyway, but it's not going to be what you 00:26:07.880 --> 00:26:16.180 want it to do. So yeah, I definitely want to turn this on so I don't use uninitialized variables. Similarly, if 00:26:16.180 --> 00:26:22.820 any of your script statements returns a non true value, so it's a that's usually in scripts or 00:26:22.820 --> 00:26:30.000 shell work, non true value means something bad happened. If you use set dash E, that will make 00:26:30.000 --> 00:26:36.220 your script exit at any point if one of the sub statements returns a non returns an error value. 00:26:36.380 --> 00:26:42.140 So you don't you don't want to just keep rolling with an error condition. So this is good. I hopefully 00:26:42.140 --> 00:26:48.320 I'll cautiously add this to scripts because I want to make sure they keep working. And then a tip just to 00:26:48.320 --> 00:26:53.300 say expect the unexpected. There will be times where you'll have missing files or missing directories or 00:26:53.300 --> 00:26:58.400 directory that you're writing into is not created. So there's ways to make sure it's there before you 00:26:58.400 --> 00:27:03.620 write to it. If you're especially if you're running on Windows, be prepared for spaces and file names. 00:27:03.620 --> 00:27:11.480 And so variable expansion in bash does not really isolate spaces. So you have to put quotes around 00:27:11.480 --> 00:27:17.120 expansion to make sure that it's a single thing. And one of the things right away, the next one is using 00:27:17.120 --> 00:27:23.300 trap. And I've never actually knew how to do this before. So if you've got a bash script that's running, 00:27:23.420 --> 00:27:29.920 and it just something's wrong and it won't exit, you can kill it or other ways to get it to stop. 00:27:29.920 --> 00:27:32.720 But if you have the system in a state that 00:27:32.720 --> 00:27:37.340 needs some cleanup so that this there's a way to use a trap 00:27:37.340 --> 00:27:40.860 command to exit gracefully and clean up things. 00:27:40.860 --> 00:27:44.620 The last couple of points were be careful of race conditions and be atomic. 00:27:44.620 --> 00:27:48.740 Those are good things to do, but at least a handful of these I'll put to use right away. 00:27:48.740 --> 00:27:52.600 So it's good. Yeah, this is neat. And a lot of the stuff I didn't really 00:27:52.600 --> 00:27:58.100 know about. So yeah, like, continue on if something went wrong, just plowing ahead. 00:27:58.100 --> 00:28:00.220 Yeah, that's cool to know that you can make it stop. 00:28:00.220 --> 00:28:03.740 Steve, do you ever do any bash? You got a WSL thing going on over there? 00:28:03.740 --> 00:28:10.000 I've certainly done a lot more bash since I started using WSL for a lot of things. I was aware that 00:28:10.000 --> 00:28:15.860 using an uninitialized variable would substitute nothing. But I'm very happy to know that there's 00:28:15.860 --> 00:28:20.760 a way to kind of turn that off because that that has certainly caught me out in the past many times. 00:28:21.280 --> 00:28:26.060 And this looks like just a good article that I'm going to have to go read myself now because it has 00:28:26.060 --> 00:28:32.900 everything that you learn from doing scripts in like command prompt or PowerShell now or even Python to 00:28:32.900 --> 00:28:38.240 some extent. I have not personally mapped those to bash equivalents. So it sounds like this would be a 00:28:38.240 --> 00:28:43.560 good place for me to go through that and up my skills a little bit. My favorite thing was the find 00:28:43.560 --> 00:28:49.140 command. And once I got that, that felt as powerful as a reg X. And I'm kind of like, oh, I don't need to write a 00:28:49.140 --> 00:28:53.140 whole script. Now I can just do one excessively long find command. 00:28:53.140 --> 00:28:54.600 Nice. 00:28:54.600 --> 00:28:56.880 Yeah, you find a lot as well. 00:28:56.880 --> 00:29:01.300 All right, this next one, I don't want to spend too much time on because I feel like you could easily 00:29:01.300 --> 00:29:06.860 just go and spend an hour on it. But for time's sake, we don't have a whole lot of time left for 00:29:06.860 --> 00:29:11.400 the episode because we have a bit of a hard stop. So I'm going to go through this and get your guys' 00:29:11.480 --> 00:29:19.700 thoughts on it real quick. There was a tweet about a GitHub repository that was a conversation on 00:29:19.700 --> 00:29:27.940 the Python mailing list. Lots of places. So Anthony Shaw tweeted, calling attention to a roadmap by Mark 00:29:27.940 --> 00:29:37.680 Shannon, called Ideas for Making for Five Times Faster CPython. So he laid out a roadmap and a funding map 00:29:37.680 --> 00:29:42.220 and some interesting ideas. And I'm going to go through them quick. And then especially Steve, 00:29:42.220 --> 00:29:47.620 we'll see what your thoughts are here, how reasonable this might be. So the idea is like, 00:29:47.620 --> 00:29:53.080 there's going to be four different stages. And at each stage, I think you can get 50%. Speed improvement, 00:29:53.080 --> 00:29:57.800 you do that four times, that's, you know, compounding performance interest, you get five. 00:29:57.800 --> 00:30:05.100 So I think it talks about three nines somewhere. But anyway, I think maybe it's got to shift its 00:30:05.100 --> 00:30:10.320 numbers a little. Anyway, so Python 3.10, stage one was to try to improve will be adaptive, 00:30:10.320 --> 00:30:16.680 specialized interpreter that will adapt types and values during execution, exploiting type stability 00:30:16.680 --> 00:30:20.500 without the need for runtime code generation. That almost sounds a little bit like what you're 00:30:20.500 --> 00:30:27.280 talking about with the 10% increase earlier, Steve. And then 3.11, stage two would be improved 00:30:27.280 --> 00:30:32.380 performance for integers, less than one machine word, faster calls and returns to better handling 00:30:32.380 --> 00:30:38.660 of frames and better object memory layout. Stage three, Python 3.12 requires runtime code generation, 00:30:38.660 --> 00:30:43.800 a simple JIT for small regions. Python 13, extending the JIT to do a little bit more. 00:30:44.320 --> 00:30:52.440 And I'm linking to a conversation, a long threaded conversation over on Python dev. There's a whole 00:30:52.440 --> 00:30:56.540 bunch of stuff going on here. So I encourage people to read through it. But there's just like a lot of 00:30:56.540 --> 00:31:01.080 interesting implications about like, how do we pay this if we pay someone to do it? People like Steve 00:31:01.080 --> 00:31:06.980 work on CPython and they don't get paid. Like, how is it fair to pay someone else to do it when other 00:31:06.980 --> 00:31:10.760 people are volunteering their time? There's a lot going on here. Steve, what do you think about this? 00:31:10.760 --> 00:31:15.020 Have you been following this? I read through the original proposal. I haven't had a chance to chat 00:31:15.020 --> 00:31:21.660 with Mark directly about it. I will, I guess, start by saying that Mark is a very smart guy. And he has 00:31:21.660 --> 00:31:27.480 done all of this planning off on his own in secret and kind of come out and shared this plan with us, 00:31:27.480 --> 00:31:32.360 which, you know, is it's not an ideal kind of workflow, certainly when you're part of a team. 00:31:32.820 --> 00:31:37.920 But I have certainly found in the past that when you get a very smart guy or very smart girl goes 00:31:37.920 --> 00:31:42.520 off and disappears for a few weeks and comes back and says, I've solved it. There's a good chance 00:31:42.520 --> 00:31:47.640 they've solved it. So I'm very interested to see where it goes. The part of the discussion that you 00:31:47.640 --> 00:31:53.480 didn't mention is, or that you hinted at is this is kind of a proposal for the Python Software Foundation 00:31:53.480 --> 00:32:00.560 to fund the work. And that part of that funding is conditional on delivery. So the way he's proposed, 00:32:00.560 --> 00:32:05.420 this would work. And the implication seems to be that Mark will do the work himself and be the one 00:32:05.420 --> 00:32:10.380 getting paid for it. Yeah, that seemed like it wasn't clear from his GitHub repo. But if you read 00:32:10.380 --> 00:32:14.980 the conversation, it was like, look, I'm pretty sure I can do these things. This is how much would make 00:32:14.980 --> 00:32:19.620 sense for me to spend the next couple of years working on it and getting paid. How do we do a 00:32:19.620 --> 00:32:23.560 fundraiser so that I can do this for everyone? Yeah. And, you know, I think under those conditions, 00:32:23.560 --> 00:32:28.900 if the PSF is able to put the budget towards it, they are in a bit of a tight spot. 00:32:29.240 --> 00:32:33.660 Since PyCon is normally the big fundraiser for the year, and that didn't happen. On the other hand, 00:32:33.660 --> 00:32:40.280 it's also the big expense. But financially, the PSF is not in their normal place where they'd be for 00:32:40.280 --> 00:32:47.080 for the year, because PyCon didn't happen in the same way. But I think if they're prepared to put 00:32:47.080 --> 00:32:53.280 funding towards this, I guess if the community consensus is that this is the most important 00:32:53.280 --> 00:32:58.560 thing for us to do. And there's certainly potential downsides to doing it. Code complexity is the big 00:32:58.560 --> 00:33:04.180 one. And I don't actually think there's a way that you implement this or even achieve these performance 00:33:04.180 --> 00:33:11.240 gains without making the code much more complex, and hence less accessible to new contributors and, 00:33:11.740 --> 00:33:15.320 people in earlier stages of learning to code, at least on the C side. 00:33:15.320 --> 00:33:15.980 Yeah. 00:33:15.980 --> 00:33:16.640 Yeah. 00:33:16.640 --> 00:33:22.900 So there's trade-offs. I'm very interested to see what would come about. I assume that because 310 is 00:33:22.900 --> 00:33:28.120 targeted for the first pass, that it's already done. And he's already got the code. And he's trying to 00:33:28.120 --> 00:33:33.880 actually... And he's just trying to get confirmation that he can spend the next few years heavily investing 00:33:33.880 --> 00:33:38.480 in it instead of having to go find a full-time job and go back to doing this in the evenings. 00:33:38.480 --> 00:33:38.700 Yeah. 00:33:38.700 --> 00:33:43.380 Which, you know, I'm fully supportive of. Again, it's really just a big open question of, 00:33:43.380 --> 00:33:50.040 is this the most important thing for Python to be funding right now, for CPython to be getting 00:33:50.040 --> 00:33:55.100 in particular? Someone, I forget who, raised the question of what if we put that money towards PyPy 00:33:55.100 --> 00:33:59.860 instead? You know, what could they do with it in that amount of time? And ultimately, 00:33:59.860 --> 00:34:05.620 it's going to come down to someone, probably a small group, presumably the steering council will 00:34:05.620 --> 00:34:10.340 have some involvement from the technical side. The Python Software Foundation Board will no doubt be 00:34:10.340 --> 00:34:18.040 involved in just deciding, is this the best use of the money that we have or can go out and get 00:34:18.040 --> 00:34:21.180 for what benefits it would produce? 00:34:21.180 --> 00:34:26.020 Yeah. When I look at it with the funding side, I see it as very brought with challenges on the 00:34:26.020 --> 00:34:31.160 sort of community funding and the PSF funding. But I know there's so many huge companies out there that 00:34:31.160 --> 00:34:36.600 spend an insane amount of money on compute and infrastructure that make a lot of money. And that 00:34:36.600 --> 00:34:43.460 if they could have a 5x speed up on their code, they could probably save that money right away on 00:34:43.460 --> 00:34:47.680 infrastructure. So it seems like that they could also get funded that way. But we should probably 00:34:47.680 --> 00:34:51.460 move on just because I've got to, I'm going to make sure we have time for everything else before we 00:34:51.460 --> 00:34:55.180 end up running out of time. I just do want to call out, like, you should go check out that 00:34:55.180 --> 00:34:59.500 conversation. There's a very funny excerpt from Larry Hastings. It says, speaking as the gillectomy 00:34:59.500 --> 00:35:03.260 guy, they were talking about borrowed references being a challenge, saying borrowed references are evil. 00:35:03.260 --> 00:35:07.860 The definition of a valid lifetime of borrowed reference doesn't exist because they are a hack 00:35:07.860 --> 00:35:13.440 baked into the API that we mostly get away with because of the GIL. If I still had wishes left on my 00:35:13.440 --> 00:35:18.660 monkey's paw, I'd wish them away. Unfortunately, I used my last wish back in February wishing I could spend more 00:35:18.660 --> 00:35:26.160 time at home. So bad. All right, Steve, let's get a little bit more insight from you on this last one, 00:35:26.160 --> 00:35:30.360 huh? Because you were at the core developer sprints, which recently happened. 00:35:30.360 --> 00:35:33.920 Yeah. So I don't know exactly what day this is going to go out. But last week, 00:35:33.920 --> 00:35:41.620 from recording day, we had the CPython core developer sprints. So this is kind of a get together, 00:35:41.620 --> 00:35:48.520 generally in person event that the core development team has done for five years now. I think this is 00:35:48.520 --> 00:35:54.900 the fifth year. In the past, we've all gone down to Facebook or Microsoft or last year, we hung out 00:35:54.900 --> 00:36:02.800 at Bloomberg in London and basically spent a week in a room together coding, discussing, reviewing things, 00:36:02.800 --> 00:36:08.880 designing things, planning things, and otherwise just getting to actually meet our other contributors 00:36:08.880 --> 00:36:14.440 because we all work online. We all mostly work over email and kind of bug tracker and GitHub 00:36:14.440 --> 00:36:19.220 pull requests throughout the year. And so it's a really good opportunity to get to meet each other, 00:36:19.220 --> 00:36:24.540 get to see who we're dealing with. It's a lot harder to be angry at someone over email when you've met 00:36:24.540 --> 00:36:25.140 them. Yes. 00:36:25.280 --> 00:36:29.440 And so it's been a really good event. This year, because we're obviously not traveling for it, 00:36:29.440 --> 00:36:36.340 we were hosted by Python Discord, which is at pythondiscord.com. There's a server that is really 00:36:36.340 --> 00:36:40.700 well managed. It's really well organized. I was impressed. I have not been there before, 00:36:40.700 --> 00:36:45.660 but it was great. They set up, felt like thousands of channels for us, far too many, 00:36:45.660 --> 00:36:52.040 but it gave us plenty of space to kind of mingle with other core devs while we were discussing and 00:36:52.040 --> 00:36:57.620 working and planning anything. We also did a Q&A. So there'll be a link in the notes for that from 00:36:57.620 --> 00:37:02.240 YouTube that we live streamed. We had people submit questions ahead of time, everything from 00:37:02.240 --> 00:37:08.500 what situations should I use a mangled name in, like a double underscore led name through to, 00:37:08.500 --> 00:37:11.620 you know, what's your least favorite part of Python? What do you most want to replace? 00:37:12.040 --> 00:37:16.400 Did you ever expect Python to get so big? And we had a lot more people involved. We normally do 00:37:16.400 --> 00:37:21.700 a panel for the host company. So we'll, we'll get kind of their employees together. And it's like part 00:37:21.700 --> 00:37:26.700 of the perk for funding the venue and typically meals and coffee and everything for the week. 00:37:26.700 --> 00:37:33.600 This time it was public on YouTube. It was all kind of over video. So everyone got a bit of a turn 00:37:33.600 --> 00:37:37.400 to jump in. So you'll get to see a lot more core developer faces than you've probably ever seen before. 00:37:37.400 --> 00:37:40.200 You'll get to hear from a lot more of us than you have before. 00:37:41.080 --> 00:37:46.900 And a lot of interesting things, the big kind of ideas that came out of the week, 00:37:46.900 --> 00:37:52.380 kind of hard to say. A lot of us did come out feeling like we didn't get as much forward momentum 00:37:52.380 --> 00:37:57.040 on stuff as we normally would in person. But at the same time, a lot of things did move forward. 00:37:57.040 --> 00:38:02.620 I think there were about seven or eight peps passed up to the steering council during the week, 00:38:02.620 --> 00:38:08.420 the various things. One of mine was deprecating disti-tills, which is an entire podcast on its own. 00:38:08.420 --> 00:38:15.660 So I might have to call you guys another time to talk about that one through to a proposal to change 00:38:15.660 --> 00:38:21.480 how we represent 3.10. Because a lot of places we put the version numbers back to back with no 00:38:21.480 --> 00:38:26.860 separator. And so you have, you know, 3.8, 3.9 with no nothing in between. Now we're up to 3.10, 00:38:26.940 --> 00:38:33.560 or is it 3.10? Yeah. Okay. How do we fix that? And we had a lot of discussions about that. 00:38:33.560 --> 00:38:39.740 There was obviously a lot of talk about JIT, about the C API, all the usual things that we talk about. 00:38:39.740 --> 00:38:43.980 But again, because it was online, it was really good to have such a range of people involved 00:38:43.980 --> 00:38:48.320 across different time zones and people who would not normally get to travel. 00:38:48.500 --> 00:38:50.580 Yeah. It makes it more accessible. Yeah. That's awesome. 00:38:50.580 --> 00:38:54.560 Yeah. We have core developers in countries who can't leave. Like they literally cannot leave their 00:38:54.560 --> 00:39:01.500 country either because the populace is just strictly controlled or they know they would not get back in 00:39:01.500 --> 00:39:07.660 it when they tried to go home. And so they were able to participate. And that was great to, you know, 00:39:07.660 --> 00:39:13.580 see and meet some of those people. We had a few mentees come along to interact with the rest of the team. 00:39:14.620 --> 00:39:18.800 And just overall a good week. Awesome. Yeah. Cool. And yeah, people can check it out. The YouTube 00:39:18.800 --> 00:39:22.240 stream. I definitely want to check that out. Sounds neat. All right, Brian, we've got two minutes left. 00:39:22.240 --> 00:39:26.480 Do you think we should do a joke? Yeah, let's do the joke. Oh, let's just cut to the joke. So we, 00:39:26.480 --> 00:39:33.800 we don't miss that. Right. So you and I spoke about Hacktoberfest going wrong and like random PRs to like 00:39:33.800 --> 00:39:40.800 config files and change, changing the spelling and config file settings. So there is a guy who posted on 00:39:40.800 --> 00:39:50.020 Twitter and said, Hey, I let me double check the name. It was Stuart McCroden. And he posted this cool 00:39:50.020 --> 00:39:57.840 t-shirt that he got. It says Hacktoberfest 2020. Any PR is a good R and it's Lua.py. And it has import 00:39:57.840 --> 00:40:03.420 high in Vim. Then the PR just adds hash. This imports a package. 00:40:05.420 --> 00:40:07.700 That's awesome. Steve, did you suffer from any of these? 00:40:07.700 --> 00:40:11.820 I did not. I might've done. My GitHub notifications are a mess. 00:40:11.820 --> 00:40:14.660 So yeah, I don't even know yet. 00:40:14.660 --> 00:40:18.900 Yeah. I don't, I don't see poor requests until I actually go look at the repo myself 00:40:18.900 --> 00:40:22.300 for the most part. Yeah. I got a bunch. I got a whole bunch. 00:40:22.300 --> 00:40:26.960 Yeah, me too. Cool. Okay. I wanted to do one. This should have been a topic, but the 00:40:26.960 --> 00:40:32.480 five most difficult programming languages in the world. This was submitted to us by Troy 00:40:32.840 --> 00:40:37.740 Codil, Codil, I think. It's not really a full topic, but I thought it was hilarious. This 00:40:37.740 --> 00:40:46.420 is an article where the author, Locad, Locate, I guess, actually took five programming languages, 00:40:46.420 --> 00:40:53.200 Malbosh, Intercal, Brain, you know, we all know that one, Cow, and Whitespace, and wrote 00:40:53.200 --> 00:40:59.780 Hello World in that language. And these are hilarious. And my favorite is Whitespace because the entire 00:40:59.780 --> 00:41:05.480 language depends on space tab and line feed for writing the program. And any non-Whitespace 00:41:05.480 --> 00:41:08.820 character is considered a comment. So this is great. 00:41:08.820 --> 00:41:15.700 That's crazy. I don't know why the APL wasn't on there. APL is just fully insane. Let me, 00:41:15.700 --> 00:41:22.160 I'll put it just in the show notes here at the bottom of this, an example of APL. That right 00:41:22.160 --> 00:41:27.300 there that I put on is, I can't try to even speak this, but that is an entire thing that finds 00:41:27.300 --> 00:41:32.420 all prime numbers from one to R in that line. I hope you guys see at the bottom of the notes. 00:41:32.420 --> 00:41:33.420 That's insane, isn't it? 00:41:33.420 --> 00:41:35.840 That's not even intentionally bad, is it? 00:41:35.840 --> 00:41:41.820 No, it's meant to be a real programming language. It's as if the Egyptians who only wrote in Hero 00:41:41.820 --> 00:41:47.560 Graphics decided to write a programming language. That's how I feel. It's insane. But it's a 00:41:47.560 --> 00:41:50.960 legitimate language. People try to use it. They do use it. Anyway. 00:41:50.960 --> 00:41:52.860 Not very long, I expect. 00:41:52.860 --> 00:41:56.480 Only as long as they must. And then they immediately stop. 00:41:56.480 --> 00:42:03.500 I just like that this Intercal example, it's so polite. It's please, please do, please, please, 00:42:03.500 --> 00:42:04.620 oh, please give up. 00:42:06.500 --> 00:42:12.060 Yeah. Apparently you have to sprinkle pleases in it or else it's like error because it's, 00:42:12.060 --> 00:42:17.160 you're not polite enough. But if you do too much, it also errors because you're overly polite. 00:42:17.160 --> 00:42:20.760 I like that. We need more passive aggressive languages like that. 00:42:20.760 --> 00:42:23.300 Lovely. 00:42:23.300 --> 00:42:26.420 Cool. Well, thanks a lot, guys. It was fun. 00:42:26.420 --> 00:42:27.960 Yeah. Yeah. Thanks, Brian, Michael. 00:42:27.960 --> 00:42:30.840 Yeah. Thanks. And thanks for being here, Steve. It's great to have your perspective. 00:42:30.840 --> 00:42:36.580 Thank you for listening to Python Bytes. Follow the show on Twitter at Python Bytes. That's Python 00:42:36.580 --> 00:42:43.080 Bytes as in B-Y-T-E-S. And get the full show notes at Python Bytes.FM. If you have a news item 00:42:43.080 --> 00:42:47.960 you want featured, just visit Python Bytes.FM and send it our way. We're always on the lookout for 00:42:47.960 --> 00:42:51.960 sharing something cool. This is Brian Okken. And on behalf of myself and Michael Kennedy, 00:42:51.960 --> 00:42:55.280 thank you for listening and sharing this podcast with your friends and colleagues.