#206: Python dropping old operating systems is normal!

00:00 Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to

00:04 your earbuds. This is episode 206. Wow. Recorded October 28th, 2020. I am Brian Okken.

00:11 And I'm Michael Kennedy.

00:12 Yeah. And we have a special guest today, Steve Dower.

00:14 Hi. Thanks for having me on.

00:15 Hey, Steve. Thanks for coming. It's great to have you here.

00:17 I also want to throw out that this is sponsored by Tech Meme Ride Home podcast. Check them out

00:22 at pythonbytes.fm/ride. Steve, I'm sure many listeners know you, but maybe just give us

00:26 the quick rundown. You do cool stuff at Microsoft, getting Python better on Windows and you're a core

00:31 developer. Yeah. So my main day job is for Microsoft, where I work as basically a Python engineer,

00:37 kind of a wide ranging resource to the company. So I haven't shipped anything in my own in a while,

00:44 but I've had my fingers in a lot of Python related things that have gone out recently. So it's a lot

00:50 of fun, a lot of bouncing around between different teams, getting to work with a lot of different

00:53 people. And yeah, as you say, I'm a CPython core developer, one of the Windows experts on the team.

00:58 I'm responsible for the builds that go up on python.org and just generally keeping Python running

01:04 while on Windows.

01:04 Yeah, that's awesome. And you've done some interesting talks like Python is okay on Windows actually,

01:10 and talked about some of the popularity of it and how we as a community shouldn't

01:14 discount it just because we might happen to be on a Mac or use Linux or whatever, right? A lot of

01:19 people do Python on Windows. Yeah, yeah, the estimates vary. And every time I get new numbers,

01:25 they seem to show up slightly different. So it's real hard to get a good fix on how many

01:28 Python developers there even are in the world. I did get some numbers recently that I had a few

01:33 people double check because they were saying there's like 20 million installs of Python on

01:38 Windows in the entire ecosystem, which sounded like too many to me. So I had them double check.

01:43 And then I had someone else double check. And they all came back saying, yeah, it's about that.

01:47 So I'm like, okay, there's a lot of Python on Windows out there. But yeah, it doesn't show up

01:51 in conferences doesn't show up on Twitter that much. And a lot of people just look at the packages that

01:56 don't work and go, well, I guess it doesn't exist on Windows, because otherwise this package would

01:59 work. And so you know, chicken and egg problem, right? Yeah, there's a lot of chicken and egg

02:04 problems in the Python space. I mean, it's a beautiful place. But there are some of these weird chicken

02:08 and egg ones. Yeah, it's weird. I've been using Python on Windows since I started Python.

02:12 So have I.

02:13 But one thing I haven't been using very much is enums. So that was an attempt at a transition.

02:20 Why not, Brian? Tell us more.

02:22 Actually, I've tried many times I've tried to use enums. And I actually just to be honest,

02:28 I don't very much. And partly because I'm used to using enums in C and C++. And they're,

02:34 they just will act like symbols in C and C++. They work pretty good. There is some weirdness

02:40 with enums in Python. And I'm going to highlight an article called Making Enums, as always,

02:46 arguably more Pythonic by Harry Percival. He starts it off by saying, I hate enums. So Harry's a funny

02:53 guy. And this is a fairly hilarious look at why enums are frustrating sometimes. And then he presents a

03:01 semi reasonable workaround, I think, to make them more usable. So what's wrong with enums? Well,

03:06 he gives an example. And just as a simple enum with string values. And you can't directly if you

03:15 try to compare one of the enum elements to the value, like the value gave like a similar string,

03:21 it's not equal, it doesn't compare. But you can use a dot value or in the enum value. But that's,

03:27 it's just weird. He also said, he kind of thinks it'd be neat if you could do a random choice of all

03:32 the enum values, I think that would be neat. And you can't directly convert them to a list. There's

03:37 just interacting with the enum type itself, or the class itself is, has problems. In the documentation,

03:44 there is a suggestion that you can, with you can, instead of strings, use ints, and do an

03:50 int enum, and it works a little better. And if you like it like that, but want strings, you can make

03:54 your own string enum class. I'm not sure why they didn't just build this into the default, or, you know,

04:01 one of the standard types anyway, but string enum is not there. But there's an example. And it sort of

04:09 fixes a lot of stuff, but not everything. It doesn't, still doesn't allow for those direct

04:13 comparisons. So the solution that Harry came up with is just kind of like the solution, the

04:19 documentation says, derived from both enum type and str when you're creating your enum class. But then

04:26 also define this little snippet of a dunder str method, so that the str method works better. And at

04:35 that point, most of the stuff works that he wants to work. It still doesn't do random choice. But

04:41 apparently, he's gotten over that a little bit. So I actually think this is really, this is still

04:46 just a really small snippet, a little, like two lines of extra code to add to your enum types,

04:52 make them a little bit more usable. So I think it's reasonable.

04:55 If you're judging by, like, value add per character, this is awesome, because it makes working with

05:02 the enumeration so much nicer, you can do like the natural things that you would expect,

05:05 especially around testing and comparison. And it's like, also add a drive from str and just

05:11 add a dunder str method. And you're good. Steve, what do you think about this?

05:15 Yeah, I'd just add that the gotcha that you have by doing this is now you can have two values from

05:21 different enums compare as equal, which as I recall from the original discussions was the reason this

05:26 wasn't put in by default, say you've got a color enumeration and a fruit enumeration,

05:30 is orange the same between the two? And I think the decision was made for enums to say no, it's not.

05:37 If it's a fruit orange, it's different from the color orange. Making this change or using an int

05:42 enum is going to make them equal. So as long as you're prepared to deal with that, which to be quite

05:47 honest, every time I've reached for enums, I am much happier with string literals and quite comfortable

05:52 with them matching equal. Yeah, but that is just one thing to watch out for. Usually it's about

05:56 constraining the list of things like I know there's five things I want to make sure I don't like somehow

06:00 mix up what those five are. I just want to go, you know, class dot and here's the five. Let my editor

06:06 tell me which one of those it is. It seems like it's all that. So what do you think about if you overrode

06:11 like if you added dunder EQ, dunder NEQ, so like the comparison would say it has to be this type of

06:18 enumeration and the stir value has to match? Yeah, that would certainly deal with that. Gotcha.

06:22 Again, when these were being designed, basically anything that gets designed and added to Python

06:27 has a very large group of very smart people work through it. And, you know, as a result,

06:32 things always get missed. So it's possible that one was just missed. It's also possible that

06:36 someone did figure out a reason why that was also risky. And, and, you know, risky when you're

06:42 developing one of the most popular languages in the world is just anything that might surprise

06:46 anyone. So someone has deliberately designed around using enums everywhere, they're probably

06:51 not going to be surprised. Someone who is using code and that developer has swapped out all of their,

06:57 you know, they, they had a class with static variables and they turned it into an enum and

07:01 now stuff breaks because of the defaults that were chosen for enum. That's the kind of thing that

07:06 you're trying to avoid. And, you know, in a language that has anywhere between, you know,

07:10 five and 20 million kind of regular users. But as a workaround, I mean, if you know where your enum is

07:16 going to be used, there's a reason you can derive from string and it's exactly for stuff like this.

07:20 Yeah. Thanks Harry for putting out there. That's quite a neat, a little bit of a advisor. And I'm so glad

07:25 that we have Steve here because I picked some sort of semi internal type of pieces and I'm going to make

07:31 some statements about it. And then Steve can correct me to make it more accurate. And also we get the

07:36 core developers, but a perspective, not that you represent all core developers, but at least a

07:41 slice. All right. So this next one I want to cover is that Python 3.10 will be 10% faster. And this is

07:47 the 4.5 years in the making. So Yuri Stelovanov long ago did some work on optimizing, I think,

07:57 what was it? Load attribute or was it load method, load call method. So about some of these load

08:04 operations down at the CPython C eval level. And then Pablo Galindo, who's also a core developer

08:13 and the Python 3.10, 3.11 release manager picked up this work. And now we have load method,

08:20 call method and load global going faster. So basically there's some optimizations around

08:27 those opcodes that make this much faster. And this idea apparently first originated in PyPy.

08:34 PyPy. So I'm pretty excited to see that, you know, some simple internals that don't seem to change a

08:41 whole lot of stuff might make this a lot faster. What do you think, Steve?

08:44 This one is real. Like I was so excited about this when it was first being proposed. The basis of the

08:49 idea is that Python keeps everything in dictionaries, which means every time you look up, you know, dot

08:55 name of anything, it takes that name, makes it a string, turns it into a, like gets the hash value,

09:00 looks it up in a dictionary, finds the value, maybe wraps that up in some extra stuff. Like if it's

09:05 going to be a method, it's not stored as a method. You turn it into a method when you know what it's

09:09 being kind of dotted through to get to, and then returns that. That's a whole lot of work. And if

09:15 you're regularly calling the same method over and over again, why not cache it?

09:19 That's the heart of this, right? It does that cache around load adder, right?

09:22 Yeah, it does that cache. And the insight that Yuri had that he made work, and in fact,

09:26 I think someone else had suggested it earlier and hadn't gotten it to work was what happens when

09:31 things change? Because again, as I say, it's, we're designing language for many, many people do all

09:37 sorts of weird things. And if you cache a method lookup, and then someone tries to monkey patch it,

09:41 you know, we've now broken their code for the sake of an optimization, which, you know, is a no,

09:46 in Pythons, like correctness beats performance. In every case, that's just the trade off that the

09:51 language chooses to make. That's almost always what you want, right? Like, when would you want to be

09:55 faster and wrong rather than slower and right? I'd be happy with faster and no monkey patching.

10:00 But yes, yes, sure. Like faster and fewer restricted capabilities might be a really good trade off,

10:06 but faster and wrong is not a good one. Yeah, we did some benchmarking and basically found that

10:11 there was a way to track all dictionary updates in the entire runtime with a version tag that was not

10:19 going to instantly overflow and not going to break everything. So it became really easy to say,

10:24 has this dictionary changed since I last looked at it with one single value comparison? And so it looks

10:30 at that value. If it has changed, it's going to do the full lockup again. 99.999% of the time it hasn't

10:37 changed so it can give you the cached value and you saved big dictionary lookup, possibly error handling,

10:42 descriptive protocol, all of this extra stuff that just adds so much weight to every operation.

10:49 Yeah. And that's everywhere. I mean, that's everywhere in the language.

10:51 Absolutely everywhere.

10:52 That's fantastic. One of the things when I was first getting into Python that made me sort of have a sad

10:57 face was realizing that having function calls was pretty expensive, right? Like having a big call chain,

11:05 like actually the act of calling a function has a fair amount of overhead. When I wanted to break my

11:10 code into like a bunch of small functions to make it real readable, this part needs to go a little

11:14 faster. Maybe that's not what I want. You know? And so hopefully this helps with that as well.

11:20 Yeah. That and vector call is another optimization that we got in recently. I think that might've been

11:26 the pet 509 actually was vector call also designed to make that faster. Just removing some of the

11:32 the internal steps for doing a function call. Fantastic. And it's like Brian said, this is

11:36 everywhere. So that's everyone's going to benefit. This is fantastic. Yeah. Well, we would like to thank

11:42 our sponsor. So this episode is brought to you by Tech Meme Ride Home podcast. This is a great podcast

11:49 for more than two years and nearly 700 episodes. The Tech Meme Ride Home has been Silicon Valley's

11:55 favorite tech news podcast. The Tech Meme Ride Home is a daily podcast only 15 to 20 minutes long and even

12:02 and every day by 5 p.m. Eastern. It's all the latest tech news, but it's more than just headlines.

12:09 You could get a robot to read your headlines. The Tech Meme Ride Home is all the context around the

12:15 latest news of the day. It's all the top stories, the top posts and tweets and conversations about those

12:20 stories as well as behind the scenes analysis. The Tech Meme Ride Home is the TLDR as a service.

12:26 The folks at Tech Meme are online all day reading everything so that they can catch you up. Search

12:31 your podcast app now for Ride Home and subscribe to the Tech Meme Ride Home podcast or visit

12:38 pythonbytes.fm/ride to subscribe. Yeah. Thanks for sponsoring the show. And Brian,

12:43 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

12:49 this every day. If I didn't have another job, I would not have any problem with catching up on

12:53 Python News Daily. So actually sounds quite lovely. I wonder how that podcast is doing now that not so

12:59 many people are having to, you know, commute to and from work. That sounds like one of the things where

13:06 you hope that you've, you've given people the excuse to tell their employer on my commute between

13:12 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.

13:17 I listen to podcasts while I'm, I realized I was missing out. So I started listening to podcasts

13:22 while I'm doing my laundry. I do it when I'm, we're doing some doing dishes. I listen when I'm

13:28 doing yard work, stuff like that. Yeah. I recently broke out some other older podcasts just to catch

13:32 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

13:37 worth going into. Maybe I'll tell you guys after the show. It's pretty outrageous anyway. Yeah. And

13:45 it's so enjoyable, but what I've actually found is shows like Python bites and right home that have

13:50 like a bunch of short little things that you can just drop in and out of match a lot better. Now that

13:55 people are not commuting so much, you can like do that 10 minutes while you're like folding laundry

13:58 and get like a whole segment. And so I think he gets varied, but actually it's pretty interesting.

14:03 And I think that they and us here are well positioned. Like talk Python has more of a dip

14:08 than Python bites. Have you surveyed your listeners to find out what they're doing while they listen to

14:12 you? No, not really. Everyone should tweet at these guys, Twitter. What were you doing when you were

14:17 hearing this podcast? Yeah, that's awesome. I've got a few anecdotes, but nothing like a survey that

14:23 would give me a proper answer. Steve, I think your next item is super, super interesting. And

14:27 people speaking to Twitter, right? Like this whole conversation started as a, Hey, Twitter

14:33 message. Like why did this happen? Well, let's ask Steve. Yeah. As you know, I spend a decent amount

14:38 of time on Twitter. My handle there is Zuba, Z-O-O-B-A, which you'll probably never find in search if

14:44 you're looking for my name, but that's where I am. I really like actually searching for what people

14:50 are saying about Python on windows. It's kind of the most honest feedback you get when they think

14:54 you're not listening. And so I go and listen. And one of these popped up, which was, Oh, I tried to

15:00 install Python 3.9 newest release about a little bit under a month ago on my windows seven machine,

15:07 and I couldn't install it. And since then, I've actually seen a few more posts. Someone managed to

15:12 bypass the installer completely and get it all the way onto their windows seven machine and then found out

15:16 it wouldn't run. Oh man. Yeah. And so the question was, I was like, why would you do this? Windows seven

15:21 is still a fairly big platform. Why would you take it out? And you know, the answer was just a bit too

15:26 long for a tweet, but someone, you know, kindly included Python bites in the reply. And so I said,

15:30 Hey, I'll come on and talk about it. So let's do this topic. And the answer is multiple legal looking

15:38 documents all come together and have to be read in parallel to figure out why we dropped it.

15:45 Yeah. The small business owners know what I'm talking about. So one of those documents is PEP 11,

15:50 one of the lowest number PEPs that we have, and it's titled removing support for little used platforms.

15:56 The title was not originally about windows, but there is a section in that PEP that describes Python's

16:04 policy for supporting windows on release day of 3.x.0, all the supported versions of windows covered by

16:13 Microsoft support lifecycle will be supported by CPython. And that's on the 3.x.0 release date.

16:20 So what that means is then you now have to go and look at Microsoft support lifecycle website and look

16:27 up all of the different versions of windows to see which ones are still covered by support to that date.

16:32 Windows seven fell out of extended support in January. There was quite a bit of noise about that

16:37 because that means no more security patches, except Microsoft did do a couple more security patches

16:43 because some really bad stuff was found, but that's largely stopped. Essentially, it's the point when

16:48 the only people who get windows seven support are paying for it. And I assume they're paying large

16:54 amounts of money for it. I don't actually know how much it costs, but that's the point where, you know,

16:58 you bought it, but you don't get the free support anymore. So CPython follows that because

17:03 no one is paying the core team to support Python on all of these platforms. And so it's,

17:08 it seems like the fairest point to draw that line is at some point we have to say our volunteers can no

17:16 longer keep a windows seven machine running. Even I can't keep a windows seven machine running safely

17:21 because there's no security updates for it. How am I meant to develop Python on it? How am I meant to

17:26 test Python on it? The burden there is too high for volunteers to handle. So we just say that's the

17:33 point where it goes away. So because those two documents lined up, Windows eight actually dropped

17:37 off a couple of years ago because the support lifecycle ended early for that to force everyone

17:42 onto 8.1. Windows 8.1 has about three more years. So I think Python 3.12 will be the last one to support

17:49 8.1. And then it's all Windows 10 or whatever comes out in the future. Yeah. Yeah. Windows 10 X or

17:54 whatever they call it. That's a different one. That's the Xbox. Yeah. So I, you know, I think this makes a ton

18:00 of sense. And two thoughts I had as you were laying out the case here. One is if you're running a Windows

18:08 seven and you can't upgrade to even Windows eight or more recently Windows 10 or one of the server

18:13 equivalents, right? I'm sure there's like a server equivalent, like Windows 2003 server. I don't know how

18:18 long I supported, but whenever it goes out, it probably falls under that banner as well, right? Yeah. Windows

18:22 server is a bit more interesting. Their life cycles tend to last longer, but historically,

18:28 CPython has only kind of tied itself to the client operating systems. Gotcha. Oh, interesting. Okay.

18:34 So to me, I feel like if you're running code or you're running systems that old, you must be running

18:40 it because it's like some super legacy thing. So do you absolutely necessarily need to have the most

18:47 cutting edge Python or whatever language? Like it's probably something that's

18:53 that way because it's calcified and you probably don't need, or you probably shouldn't be putting

18:59 like the newest, shiniest things on it. Right. That's that one. What do you think?

19:03 Yeah. No, I totally agree with that. If that setup that you're running is so critical that you can't

19:09 upgrade the operating system. How can you upgrade a language runtime? It's like, how can you upgrade

19:13 anything on that? I feel like it's in the category of, please just don't touch it. It's over there.

19:18 Just don't even walk by it. Leave it alone. We cannot have it break. Just leave it over there.

19:23 Probably still has a PS2 keyboard plugged into it. Oh, it might with a little blue or pink round thing.

19:28 Yeah, absolutely. The screen has probably got at least 16 colors. Yeah. And the monitor is probably

19:32 really heavy. Windows seven. It's not that, it's not that old. Some of the, seriously, like the stuff is

19:38 old and you probably don't want to touch it, right? Yeah, that's exactly it. It's all the motivation

19:42 that you would have for updating to Python 3.9 from 3.8. And again, we're talking about a version

19:47 that's only one year old. Like Python 3.8 is not that old and you desperately need to upgrade to 3.9.

19:53 You even more desperately need to upgrade Windows. And there's just really, there really is no question

19:59 about that. The same thing applies to early versions of Ubuntu. People running Ubuntu 14 or even 16 at this

20:05 point, like need to be facing the same thing. And we have similar discussions around OpenSSL,

20:11 where occasionally people will be, oh, I need Python 3.9 to run on OpenSSL 0.9. To which our answer is

20:20 basically, that's pretty hot bleed. It's like, okay, I'm going to play the other side. I totally get the

20:27 reasons. But I also get the questions because the users and the developers or the whoever's wanting

20:34 to install Python, they usually don't get to choose what operating system they're using, but they do get

20:41 to choose which version of Python they're using. So I do get said in some cases and in some cases,

20:47 I totally understand where the question is coming. Yeah. We joke about how old these machines are and

20:53 they're really not. Like people are setting up new machines, probably with Windows 7. They certainly

20:57 were within the last year. And there's good legitimate reasons for that. And we're making

21:02 fun of some of the apparent contradictions, but we're definitely not making fun of the people

21:06 who have often been forced into these positions. But the reality is we can't afford as a volunteer team

21:12 to maintain Python against unmaintained operating systems. And so the advice is stay on the previous

21:20 version of Python that the latest version of Python that works for you. It's not going to break. We're

21:25 not changing it. Anything new that comes up, security fixes will still come out. At some point,

21:31 there just has to be a line drawn. And that's the point where we've chosen to draw it. The other thing

21:36 I want to point out that we changed in this release, which people are more excited about is if you go to

21:40 python.org to download Python for Windows, you get this real big obvious button up front that just says

21:46 download for Windows or download now or something. As of Python 3.9, that's now getting the 64-bit

21:51 version rather than the 32-bit version. For a long time, it's been 32-bit. The reason for that was

21:56 compatibility. We knew a 32-bit one would run anywhere. When we put Python in the Windows store,

22:01 that was 64-bit only. We kind of wanted to test the waters and see, hey, will people notice that we

22:07 haven't put a 32-bit version here? Turns out no one did. And so when we got to 3.9, had that change,

22:13 we made it 64-bit by default. So that has a flow and effect to the ecosystem. A lot of particularly

22:19 data science packages would rather just do 64-bit only packages. Some of them certainly get theirs

22:25 done first and not the 32-bit ones. So we expect to see some flow and impact from that just broader use

22:32 of the 64-bit Python throughout the Windows ecosystem.

22:36 Yeah, that's super cool. And just like the final thought I had was, you know, Django dropped Python

22:41 2 and they're like, we were able to remove so much code and it is easier for new people to contribute

22:47 because they don't have to write for two ecosystems. They write for one. NumPy did the same thing. And I

22:52 feel like this is sort of the same story. Like you guys can just not worry about yet another older,

22:57 outdated operating system and stay focused on what most people care about.

23:02 One thing that someone did suggest in one discussion was why not dynamically light stuff up for the newer

23:07 operating system? And the answer is we do that. And when we drop the older operating system,

23:13 we get to delete about a hundred lines of code for each point where we do that. So it is,

23:18 we get to do a cleanup. We get to say, oh, we don't have to dynamically check for this API,

23:22 this API, load this, cache this, store that, call that, call this format.

23:26 We can just condense that into, oh, we know that this API is there so we can use it

23:31 and just reduce a lot of kind of effectively dead code on newer operating systems.

23:37 Nice.

23:38 Is that a pre-compile like hash if death sort of thing, or is it a runtime thing? Does it make a

23:44 performance difference?

23:44 It definitely makes a performance difference, though we try and minimize it. But again, there's,

23:49 there's always some impact. It tends to be in operating system calls anyway. So you expect a bit of

23:54 overhead. And so it's not going to add a significant kind of percentage overhead compared to whatever

23:59 operation you're doing. But it does certainly add a lot of cognitive burden to someone who's reading

24:06 the code. Sure.

24:07 One example that we got to clean up recently, not in the, in a previous version was we had about,

24:12 I think 70 or 80 lines of code to concatenate two path segments. And this is before Python's loaded.

24:18 So we have to do this with the operating system, the API call up until windows seven,

24:24 I think. So pre windows seven was not secure and it would, you know, buffer over runs, all sorts of

24:30 horrible stuff, but it was the best available function there for handling certain cases. So we'd use it,

24:36 but first we dynamically look for the newer safer one and call that soon as we dropped, I think Vista,

24:42 we could delete all of that code and just unconditionally call the one safe path combined

24:47 function. And that code got a whole lot simpler.

24:51 Yeah. Lovely. That's awesome.

24:52 Yeah. Cool.

24:53 Brian, would you say it's more robust now?

24:55 Yes. I think it would be more robust. Actually, I thought I showed up to the bash podcast. Is this

25:02 the Python podcast?

25:03 Yeah, this is not as bash bites.

25:05 Okay. I love Python. Of course, I still use bash regularly. And I know a lot of people that are,

25:12 like sysops people and other people are using bash daily as well. So I wanted to highlight this

25:17 cool article. This is an article by David Paschley called writing robust bash shell scripts.

25:22 And even though I've been writing scripts for decades, I learned a whole bunch in this and I'm

25:28 going to start changing the way I do things right away. The first two tips right away are things I'm

25:33 going to do. First tip is to include a set dash you and never even heard of this. What it does is it

25:40 makes your bash script exit if it encounters an uninitialized variable. So the problem without

25:47 this is like, let's say you're constructing a path name or something or a path, a long path. And one of

25:53 the directories or file names you have in a variable, if that's never set, a bash normally just silently just

26:01 deletes it and it's just not there. And it'll still keep executing anyway, but it's not going to be what you

26:07 want it to do. So yeah, I definitely want to turn this on so I don't use uninitialized variables. Similarly, if

26:16 any of your script statements returns a non true value, so it's a that's usually in scripts or

26:22 shell work, non true value means something bad happened. If you use set dash E, that will make

26:30 your script exit at any point if one of the sub statements returns a non returns an error value.

26:36 So you don't you don't want to just keep rolling with an error condition. So this is good. I hopefully

26:42 I'll cautiously add this to scripts because I want to make sure they keep working. And then a tip just to

26:48 say expect the unexpected. There will be times where you'll have missing files or missing directories or

26:53 directory that you're writing into is not created. So there's ways to make sure it's there before you

26:58 write to it. If you're especially if you're running on Windows, be prepared for spaces and file names.

27:03 And so variable expansion in bash does not really isolate spaces. So you have to put quotes around

27:11 expansion to make sure that it's a single thing. And one of the things right away, the next one is using

27:17 trap. And I've never actually knew how to do this before. So if you've got a bash script that's running,

27:23 and it just something's wrong and it won't exit, you can kill it or other ways to get it to stop.

27:29 But if you have the system in a state that needs some cleanup so that this there's a way to use a trap

27:37 command to exit gracefully and clean up things.

27:40 The last couple of points were be careful of race conditions and be atomic.

27:44 Those are good things to do, but at least a handful of these I'll put to use right away.

27:48 So it's good. Yeah, this is neat. And a lot of the stuff I didn't really

27:52 know about. So yeah, like, continue on if something went wrong, just plowing ahead.

27:58 Yeah, that's cool to know that you can make it stop.

28:00 Steve, do you ever do any bash? You got a WSL thing going on over there?

28:03 I've certainly done a lot more bash since I started using WSL for a lot of things. I was aware that

28:10 using an uninitialized variable would substitute nothing. But I'm very happy to know that there's

28:15 a way to kind of turn that off because that that has certainly caught me out in the past many times.

28:21 And this looks like just a good article that I'm going to have to go read myself now because it has

28:26 everything that you learn from doing scripts in like command prompt or PowerShell now or even Python to

28:32 some extent. I have not personally mapped those to bash equivalents. So it sounds like this would be a

28:38 good place for me to go through that and up my skills a little bit. My favorite thing was the find

28:43 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

28:49 whole script. Now I can just do one excessively long find command.

28:53 Nice.

28:54 Yeah, you find a lot as well.

28:56 All right, this next one, I don't want to spend too much time on because I feel like you could easily

29:01 just go and spend an hour on it. But for time's sake, we don't have a whole lot of time left for

29:06 the episode because we have a bit of a hard stop. So I'm going to go through this and get your guys'

29:11 thoughts on it real quick. There was a tweet about a GitHub repository that was a conversation on

29:19 the Python mailing list. Lots of places. So Anthony Shaw tweeted, calling attention to a roadmap by Mark

29:27 Shannon, called Ideas for Making for Five Times Faster CPython. So he laid out a roadmap and a funding map

29:37 and some interesting ideas. And I'm going to go through them quick. And then especially Steve,

29:42 we'll see what your thoughts are here, how reasonable this might be. So the idea is like,

29:47 there's going to be four different stages. And at each stage, I think you can get 50%. Speed improvement,

29:53 you do that four times, that's, you know, compounding performance interest, you get five.

29:57 So I think it talks about three nines somewhere. But anyway, I think maybe it's got to shift its

30:05 numbers a little. Anyway, so Python 3.10, stage one was to try to improve will be adaptive,

30:10 specialized interpreter that will adapt types and values during execution, exploiting type stability

30:16 without the need for runtime code generation. That almost sounds a little bit like what you're

30:20 talking about with the 10% increase earlier, Steve. And then 3.11, stage two would be improved

30:27 performance for integers, less than one machine word, faster calls and returns to better handling

30:32 of frames and better object memory layout. Stage three, Python 3.12 requires runtime code generation,

30:38 a simple JIT for small regions. Python 13, extending the JIT to do a little bit more.

30:44 And I'm linking to a conversation, a long threaded conversation over on Python dev. There's a whole

30:52 bunch of stuff going on here. So I encourage people to read through it. But there's just like a lot of

30:56 interesting implications about like, how do we pay this if we pay someone to do it? People like Steve

31:01 work on CPython and they don't get paid. Like, how is it fair to pay someone else to do it when other

31:06 people are volunteering their time? There's a lot going on here. Steve, what do you think about this?

31:10 Have you been following this? I read through the original proposal. I haven't had a chance to chat

31:15 with Mark directly about it. I will, I guess, start by saying that Mark is a very smart guy. And he has

31:21 done all of this planning off on his own in secret and kind of come out and shared this plan with us,

31:27 which, you know, is it's not an ideal kind of workflow, certainly when you're part of a team.

31:32 But I have certainly found in the past that when you get a very smart guy or very smart girl goes

31:37 off and disappears for a few weeks and comes back and says, I've solved it. There's a good chance

31:42 they've solved it. So I'm very interested to see where it goes. The part of the discussion that you

31:47 didn't mention is, or that you hinted at is this is kind of a proposal for the Python Software Foundation

31:53 to fund the work. And that part of that funding is conditional on delivery. So the way he's proposed,

32:00 this would work. And the implication seems to be that Mark will do the work himself and be the one

32:05 getting paid for it. Yeah, that seemed like it wasn't clear from his GitHub repo. But if you read

32:10 the conversation, it was like, look, I'm pretty sure I can do these things. This is how much would make

32:14 sense for me to spend the next couple of years working on it and getting paid. How do we do a

32:19 fundraiser so that I can do this for everyone? Yeah. And, you know, I think under those conditions,

32:23 if the PSF is able to put the budget towards it, they are in a bit of a tight spot.

32:29 Since PyCon is normally the big fundraiser for the year, and that didn't happen. On the other hand,

32:33 it's also the big expense. But financially, the PSF is not in their normal place where they'd be for

32:40 for the year, because PyCon didn't happen in the same way. But I think if they're prepared to put

32:47 funding towards this, I guess if the community consensus is that this is the most important

32:53 thing for us to do. And there's certainly potential downsides to doing it. Code complexity is the big

32:58 one. And I don't actually think there's a way that you implement this or even achieve these performance

33:04 gains without making the code much more complex, and hence less accessible to new contributors and,

33:11 people in earlier stages of learning to code, at least on the C side.

33:15 Yeah.

33:15 Yeah.

33:16 So there's trade-offs. I'm very interested to see what would come about. I assume that because 310 is

33:22 targeted for the first pass, that it's already done. And he's already got the code. And he's trying to

33:28 actually... And he's just trying to get confirmation that he can spend the next few years heavily investing

33:33 in it instead of having to go find a full-time job and go back to doing this in the evenings.

33:38 Yeah.

33:38 Which, you know, I'm fully supportive of. Again, it's really just a big open question of,

33:43 is this the most important thing for Python to be funding right now, for CPython to be getting

33:50 in particular? Someone, I forget who, raised the question of what if we put that money towards PyPy

33:55 instead? You know, what could they do with it in that amount of time? And ultimately,

33:59 it's going to come down to someone, probably a small group, presumably the steering council will

34:05 have some involvement from the technical side. The Python Software Foundation Board will no doubt be

34:10 involved in just deciding, is this the best use of the money that we have or can go out and get

34:18 for what benefits it would produce?

34:21 Yeah. When I look at it with the funding side, I see it as very brought with challenges on the

34:26 sort of community funding and the PSF funding. But I know there's so many huge companies out there that

34:31 spend an insane amount of money on compute and infrastructure that make a lot of money. And that

34:36 if they could have a 5x speed up on their code, they could probably save that money right away on

34:43 infrastructure. So it seems like that they could also get funded that way. But we should probably

34:47 move on just because I've got to, I'm going to make sure we have time for everything else before we

34:51 end up running out of time. I just do want to call out, like, you should go check out that

34:55 conversation. There's a very funny excerpt from Larry Hastings. It says, speaking as the gillectomy

34:59 guy, they were talking about borrowed references being a challenge, saying borrowed references are evil.

35:03 The definition of a valid lifetime of borrowed reference doesn't exist because they are a hack

35:07 baked into the API that we mostly get away with because of the GIL. If I still had wishes left on my

35:13 monkey's paw, I'd wish them away. Unfortunately, I used my last wish back in February wishing I could spend more

35:18 time at home. So bad. All right, Steve, let's get a little bit more insight from you on this last one,

35:26 huh? Because you were at the core developer sprints, which recently happened.

35:30 Yeah. So I don't know exactly what day this is going to go out. But last week,

35:33 from recording day, we had the CPython core developer sprints. So this is kind of a get together,

35:41 generally in person event that the core development team has done for five years now. I think this is

35:48 the fifth year. In the past, we've all gone down to Facebook or Microsoft or last year, we hung out

35:54 at Bloomberg in London and basically spent a week in a room together coding, discussing, reviewing things,

36:02 designing things, planning things, and otherwise just getting to actually meet our other contributors

36:08 because we all work online. We all mostly work over email and kind of bug tracker and GitHub

36:14 pull requests throughout the year. And so it's a really good opportunity to get to meet each other,

36:19 get to see who we're dealing with. It's a lot harder to be angry at someone over email when you've met

36:24 them. Yes.

36:25 And so it's been a really good event. This year, because we're obviously not traveling for it,

36:29 we were hosted by Python Discord, which is at pythondiscord.com. There's a server that is really

36:36 well managed. It's really well organized. I was impressed. I have not been there before,

36:40 but it was great. They set up, felt like thousands of channels for us, far too many,

36:45 but it gave us plenty of space to kind of mingle with other core devs while we were discussing and

36:52 working and planning anything. We also did a Q&A. So there'll be a link in the notes for that from

36:57 YouTube that we live streamed. We had people submit questions ahead of time, everything from

37:02 what situations should I use a mangled name in, like a double underscore led name through to,

37:08 you know, what's your least favorite part of Python? What do you most want to replace?

37:12 Did you ever expect Python to get so big? And we had a lot more people involved. We normally do

37:16 a panel for the host company. So we'll, we'll get kind of their employees together. And it's like part

37:21 of the perk for funding the venue and typically meals and coffee and everything for the week.

37:26 This time it was public on YouTube. It was all kind of over video. So everyone got a bit of a turn

37:33 to jump in. So you'll get to see a lot more core developer faces than you've probably ever seen before.

37:37 You'll get to hear from a lot more of us than you have before.

37:41 And a lot of interesting things, the big kind of ideas that came out of the week,

37:46 kind of hard to say. A lot of us did come out feeling like we didn't get as much forward momentum

37:52 on stuff as we normally would in person. But at the same time, a lot of things did move forward.

37:57 I think there were about seven or eight peps passed up to the steering council during the week,

38:02 the various things. One of mine was deprecating disti-tills, which is an entire podcast on its own.

38:08 So I might have to call you guys another time to talk about that one through to a proposal to change

38:15 how we represent 3.10. Because a lot of places we put the version numbers back to back with no

38:21 separator. And so you have, you know, 3.8, 3.9 with no nothing in between. Now we're up to 3.10,

38:26 or is it 3.10? Yeah. Okay. How do we fix that? And we had a lot of discussions about that.

38:33 There was obviously a lot of talk about JIT, about the C API, all the usual things that we talk about.

38:39 But again, because it was online, it was really good to have such a range of people involved

38:43 across different time zones and people who would not normally get to travel.

38:48 Yeah. It makes it more accessible. Yeah. That's awesome.

38:50 Yeah. We have core developers in countries who can't leave. Like they literally cannot leave their

38:54 country either because the populace is just strictly controlled or they know they would not get back in

39:01 it when they tried to go home. And so they were able to participate. And that was great to, you know,

39:07 see and meet some of those people. We had a few mentees come along to interact with the rest of the team.

39:14 And just overall a good week. Awesome. Yeah. Cool. And yeah, people can check it out. The YouTube

39:18 stream. I definitely want to check that out. Sounds neat. All right, Brian, we've got two minutes left.

39:22 Do you think we should do a joke? Yeah, let's do the joke. Oh, let's just cut to the joke. So we,

39:26 we don't miss that. Right. So you and I spoke about Hacktoberfest going wrong and like random PRs to like

39:33 config files and change, changing the spelling and config file settings. So there is a guy who posted on

39:40 Twitter and said, Hey, I let me double check the name. It was Stuart McCroden. And he posted this cool

39:50 t-shirt that he got. It says Hacktoberfest 2020. Any PR is a good R and it's Lua.py. And it has import

39:57 high in Vim. Then the PR just adds hash. This imports a package.

40:05 That's awesome. Steve, did you suffer from any of these?

40:07 I did not. I might've done. My GitHub notifications are a mess.

40:11 So yeah, I don't even know yet.

40:14 Yeah. I don't, I don't see poor requests until I actually go look at the repo myself

40:18 for the most part. Yeah. I got a bunch. I got a whole bunch.

40:22 Yeah, me too. Cool. Okay. I wanted to do one. This should have been a topic, but the

40:26 five most difficult programming languages in the world. This was submitted to us by Troy

40:32 Codil, Codil, I think. It's not really a full topic, but I thought it was hilarious. This

40:37 is an article where the author, Locad, Locate, I guess, actually took five programming languages,

40:46 Malbosh, Intercal, Brain, you know, we all know that one, Cow, and Whitespace, and wrote

40:53 Hello World in that language. And these are hilarious. And my favorite is Whitespace because the entire

40:59 language depends on space tab and line feed for writing the program. And any non-Whitespace

41:05 character is considered a comment. So this is great.

41:08 That's crazy. I don't know why the APL wasn't on there. APL is just fully insane. Let me,

41:15 I'll put it just in the show notes here at the bottom of this, an example of APL. That right

41:22 there that I put on is, I can't try to even speak this, but that is an entire thing that finds

41:27 all prime numbers from one to R in that line. I hope you guys see at the bottom of the notes.

41:32 That's insane, isn't it?

41:33 That's not even intentionally bad, is it?

41:35 No, it's meant to be a real programming language. It's as if the Egyptians who only wrote in Hero

41:41 Graphics decided to write a programming language. That's how I feel. It's insane. But it's a

41:47 legitimate language. People try to use it. They do use it. Anyway.

41:50 Not very long, I expect.

41:52 Only as long as they must. And then they immediately stop.

41:56 I just like that this Intercal example, it's so polite. It's please, please do, please, please,

42:03 oh, please give up.

42:06 Yeah. Apparently you have to sprinkle pleases in it or else it's like error because it's,

42:12 you're not polite enough. But if you do too much, it also errors because you're overly polite.

42:17 I like that. We need more passive aggressive languages like that.

42:20 Lovely.

42:23 Cool. Well, thanks a lot, guys. It was fun.

42:26 Yeah. Yeah. Thanks, Brian, Michael.

42:27 Yeah. Thanks. And thanks for being here, Steve. It's great to have your perspective.

42:30 Thank you for listening to Python Bytes. Follow the show on Twitter at Python Bytes. That's Python

42:36 Bytes as in B-Y-T-E-S. And get the full show notes at Python Bytes.FM. If you have a news item

42:43 you want featured, just visit Python Bytes.FM and send it our way. We're always on the lookout for

42:47 sharing something cool. This is Brian Okken. And on behalf of myself and Michael Kennedy,

42:51 thank you for listening and sharing this podcast with your friends and colleagues.