#153: How Python Evolves Transcript

00:00 Michael Kennedy: If you've spent some time in the Python community, you've probably heard of the term PEP, which stands for Python Enhancement Proposal. In fact, the very first one was created in June 2000, and its purpose was to define the PEP process itself. Our guest this week, Nick Coghlan, was a co-author on that very PEP and many, many more. In this episode, we're going to discuss PEPs and how Python officially evolved, but also there are many other forces that drive and influence Python. So let's dig into all of these right now. This is Talk Python to Me Episode 153, recorded February 6th, 2018. Welcome to Talk Python to Me, a weekly podcast on Python, the language, the library, the ecosystem, and the personalities. This is your host, Michael Kennedy. Follow me on Twitter where I'm @mkennedy. Keep up with the show and listen to past episodes at talkpython.fm and follow the show on Twitter via @talkpython. This episode is brought to you by Linode and Datadog. Be sure to check out their offers during their segments. It really helps support the show. Nick, welcome to Talk Python.

01:18 Nick Coghlan: Hey, very happy to be here.

01:20 Michael Kennedy: Oh, it's a real honor to have you on the show. You've been at this Python thing for quite some time, so--

01:26 Nick Coghlan: Going on 15 years I think.

01:27 Michael Kennedy: Yeah, that's awesome. Our main focus today is going to be to talk about how Python evolves, all the different forces that press on it, the PEP process, all these great things. But before we get into those, let's just get your story. How'd you get into programming in Python?

01:42 Nick Coghlan: I'm actually one of those folks who got into it as a kid. My parents got our first computer when I was 9 or 10 I think, which was a Apple IIe. Spent lots of time playing Winter Olympics and stuff on that with my siblings. Anyway, I don't actually remember the name of the book, but it was like this big green thing, which had instructions on how to do programming in Apple Basic. The classic 10, print Hello World, go to 10 type thing.

02:12 Michael Kennedy: Maybe a little indentation and it screams across the screen, the zigzag, yeah.

02:16 Nick Coghlan: Yeah, basically. You couldn't save anything because your computer didn't have a hard drive.

02:20 Michael Kennedy: It's so crazy how storage used to be. I remember some of my friends, they had, it must have been an Apple. I can't remember what it was, but it had like a big cassette player. You would plug it in and the cassette somehow provided data to the computer. I don't even remember how that works.

02:38 Nick Coghlan: I just missed the cassette era with the computers at my place. We had the big 5 1/4 inch floppy disks, which actually were floppy.

02:47 Michael Kennedy: Back when floppy disks, they were actually floppy. That's where the name came from. 'cause they weren't for a long time.

02:53 Nick Coghlan: No, the 3 1/2s were never floppy, unless you broke them open. Once you broke the case open, then the disk inside was very floppy. A friend of mine did have a Commodore 64 though, and that was the, you put the tape in, you play the game.

03:09 Michael Kennedy: So how did it work? Did the tape basically load the data into memory, and then it would just run from there?

03:14 Nick Coghlan: Yeah, basically.

03:15 Michael Kennedy: Yeah that's, technology used to be so crazy. Now it's a little more standardized. It's still crazy, but less bizarre, I guess.

03:23 Nick Coghlan: Well, we were just using a magnetic tape on reels, instead of a crystalline structure in a USB key.

03:29 Michael Kennedy: Yeah, that's right. I guess we'll look back on this time as quaint when we're talking about quantum computers, and whatever comes in 10 years, right? AI is in, who knows?

03:38 Nick Coghlan: The one that amuses me is you look back at shows like Babylon 5 and stuff, where they have their data crystals, and you go, "We literally have data crystals. That's what a USB key is."

03:48 Michael Kennedy: We really live farther in the future than I think we really appreciate. All right, so you did some of this early, really programming in this funky era, which we're talking about, but then moved on from there, I'm sure.

03:59 Nick Coghlan: Yep. So then I discovered in high school that programming was something you could do as a career. Which was cool. Then I went into university as a Computer Systems Engineer, which is kind of... Computer Systems Engineering basically lives at the boundary between Electrical and Electronic Engineering, and Software Engineering.

04:20 Michael Kennedy: Back then, there were not really software development degrees, right? You either--

04:25 Nick Coghlan: Yeah, yeah.

04:26 Michael Kennedy: I mean like the sort of Software Engineering, not Computer Science side. Oh, yeah? Nice.

04:33 Nick Coghlan: Australia's a bit different from the US, so for us--

04:36 Michael Kennedy: You guys are ahead of us, basically, yeah?

04:39 Nick Coghlan: I was in university from '95 through to 2000. When I started, you could do a straight-up Information Technology degree, with a software, there was a sub-software specialty in that. Or you could do Computer System Engineering under the Engineering Department, which is what I did. I think, by the time I graduated, there was a straight-up Software Engineering program and I think that was through the Engineering Department.

05:10 Michael Kennedy: That's cool. I know those were coming on right around then. I missed that whole time. My college started in '91, so yeah, just missed that window, as well. I started before the web, so that was fun. I remember the web coming out. That was so fun, right?

05:24 Nick Coghlan: That was the other thing, was our high school IT teacher, he basically, he also ran the after school computer club funnily enough. He was introducing us to the Mosaic Browser, and Netscape Navigator 1.0. A bunch of us in '93 it would have been, so grade 10, were all getting into the online multi-user dungeon type stuff. Poly.clarkson.sos.net is a domain name that's embedded in my brain, because that was the MUD we played on.

05:58 Michael Kennedy: Those were such fun times. That's so awesome. I played a bunch of those as well. All right, so did you learn Python in college? Or, did it come after that?

06:07 Nick Coghlan: I have a funny university story about Python, which is, our networking teacher in '99, this was, wanted to try and level the playing field amongst all the students for the networking project he was giving us, which was like a protocol design type thing. He basically, so told us, "The standard language for the assignment's going to be Python because none of you will know that." So that's funny now, looking back at it 20 years later. It's like no lecturer would do that today. But the other one was that I actually put my hand up in class and said, "Do we have to use Python or can we us a language we already know, like Java?" He said, "Sure, if you really want to." But then I did the assignment in Python. I'm going, "Okay, I don't want to anymore." That was still Python 1.5.2 at that point.

06:55 Michael Kennedy: Wow, those are pretty early days. But the contrast with Java probably was pretty stark.

06:59 Nick Coghlan: Yeah, absolutely. We were mostly interested in the wire protocol structure, so using the struct module to construct messages to send them back and forth.

07:09 Michael Kennedy: Oh yeah, very cool.

07:09 Nick Coghlan: So yeah, it was quite a cool assignment. But interestingly, I didn't touch Python again for another three years after that, I think.

07:17 Michael Kennedy: Wow.

07:17 Nick Coghlan: Yeah.

07:17 Michael Kennedy: Nice, and then you probably graduated three years later or so, and then was it work that brought us here, or what happened?

07:23 Nick Coghlan: Yeah, so what happened was I'd actually started working for Boeing Australia on the Australian Defense Force's high-frequency radio communications infrastructure as an undergrad. That became a full-time job after I graduated. The system I was working on was actually a digital signal processing system for voice detection in HF. Essentially, in HF, the problem is ordinary squelchers don't work, because HF is just very crackly and poppy. If you want to try and detect voice, you actually have to do signal analysis to say where's the energy, is this just random crackling noise, or does it actually look vaguely like a human voice? So that was all going on fine, C programming for the DSP, but we didn't really have a proper test harness for it. We just had a C application that ran on the host system, and if it got to the end without crashing, awesome!

08:17 Michael Kennedy: That basically is good now, we're going to ship it.

08:19 Nick Coghlan: Funnily enough, we kept finding bugs in the DSP software in the next level of integration testing. It's like, who knew?

08:29 Michael Kennedy: Who knew? What a mystery.

08:31 Nick Coghlan: Anyway, we needed to do a better job of testing this. There was another part of the system to orchestrate starting and stopping services, and bringing sites online and offline and they just recently got approval to introduce Python 2.2 into the system so they could use it as this control and orchestration language, which meant it's on the approved languages list, which meant, and it had this wonderful thing called the Python Unit Test Module.

09:02 Michael Kennedy: Yeah, I remember back then, C++ didn't have very many options and C even less, right?

09:07 Nick Coghlan: We actually had a in-house thing that the engineers in Boeing Australia had designed for writing tests in C++. This was around the time where a colleague had inspired me to learn iForm. We were fully into the extreme programming, test-driven development, all that sort of stuff.

09:25 Michael Kennedy: Yeah, all that stuff was going strong then, and it was so amazing.

09:30 Nick Coghlan: So they'd written that and it was a choice between that and the Python stuff. But the beautiful thing that the Python stuff had was, so our host system was running Windows NT, and Python had the wave module that would let us play WAV files out of the host system, which was very handy, because we needed to play those to check for the reactions from the signal processing software. Then, and this is why I sometimes say that it's Dave Beasley's fault that I'm a Python programmer, the SWIG existed and so what SWIG let us do is we had a C++ driver that ran on the host that the main production application used to talk to DSPs. What SWIG let me do, was basically I just wrote one .i file for SWIG to wrap the production driver. Then suddenly I had this unit test system, where I could call the production driver to set things up in the DSP, call the wave module to play audio files out of the test system, and then monitor over the network to say, "Did the signal processing software send the messages we expected it to send?"

10:48 Michael Kennedy: That's really cool, that's awesome. So practicality wins the day. There's some simple tools that solve the problem.

10:54 Nick Coghlan: That's kind of continued then. I've always been a huge fan of Python for testing because it means that, when you try to do testing in C and C++ directly, you spend a lot of time building test scaffolding to let you say, "Is this thing the same as that thing?" Or, "Is this what I expected?" The beauty of being in Python is you can express a lot of things more simply in the Python code than you can in the production code.

11:21 Michael Kennedy: It lets you move faster, it lets your tests be easier to maintain over time. Yeah, it's wonderful.

11:26 Nick Coghlan: You get this really nice combination of, the tests in Python express your intent, and then it doesn't matter what your production code is in, you're just saying, "Am I matching my intent?" Whether it's faster or through a different mechanism or whatever so--

11:40 Michael Kennedy: Yeah, really nice. You're probably not still doing that same project today. What are you working on now?

11:45 Nick Coghlan: I worked on that project in different roles, for like 12 years. Technically right now, I'm not doing anything. I finished up at Red Hat at the end of last year. Right now I'm talking to a few different people about what I'm going to do next.

12:02 Michael Kennedy: That's awesome.

12:02 Nick Coghlan: Yeah, so--

12:03 Michael Kennedy: Taking your time to kind of find the next big thing.

12:05 Nick Coghlan: I've got the luxury of not having to make a quick decision about what I want to do next. So it means I'm kind of going, what do I really want to be doing? 'cause to be honest, I've spent the six years since I left Boeing, I've been completely in the software infrastructure space. It's like, while I don't dislike that, I do really miss being able to point at piece of hardware and say, "My software makes that work."

12:32 Michael Kennedy: Yeah, so when are we going to be riding in your next self-driving airplane that you're creating, or your next rider, right? It's coming a few years out, right?

12:39 Nick Coghlan: So that's the thing of, it's very tempting to just say, "You know what, I'm kind of going to get out of the software infrastructure world and go back into the physical hardware that does stuff." But at the same time, there's a lot of interesting stuff to be done in open source supply chain management.

12:54 Michael Kennedy: Yeah, of course there's so many interesting problems. There's definitely no shortage of that. That's awesome. Let's go ahead and talk about our main topic, which is how Python evolves. We were talking just before I hit record, and I feel like the two major ways that kind of drive where Python goes is, kind of from the official inside, which is this PEP process and these other meetings, and core developers. Then there's the outside world where nobody asks for permission. They just go make stuff. Then you guys look at it and go, "Wait, actually they're doing really cool stuff over here. Does that really drive, Does that control like a satellite in space? How are you doing that? Are you doing it with Python?" So there's these sort of two forces. The internal PEPs and the external just, what people are doing. What do you think about that?

13:44 Nick Coghlan: I kind of mentally break it up into two problems. It's the thing of applying Python to a problem domain, and that's the case of like, even Python 1.5.2 was an entirely usable orchestration language. Python 2.2 was exceptional. That's why we stuck with it for so long at Boeing. In that sense, it becomes the case of take Python as it exists today, apply it to a problem you have today, and write whatever the libraries you need in order to model that domain successfully. That, again, gets back to my original exposure to it as hardware testing and orchestration for an existing system. I don't recall any time when I was doing that saying, "Oh, I wish Python whatever," because it was the case of it did everything I needed it to do, and anything it didn't already do, we'd just add a library for it. We were actually doing a lot of stuff with CORBA at the time as our distributed communication protocol. There are actually a bunch of different request brokers surviving out there. So for that, Python-Dev doesn't need to be involved. This occasionally frustrates people because they want us to be the single authority for all things Python and they're going, "You need to do something about blah." We're going, "Why? It doesn't need to be us." It's like, "We're not the domain experts on that."

15:12 Michael Kennedy: That's really interesting and that is definitely something that's different in the Python world from other organizations that are much more, sort of, mothership oriented. I'm thinking Apple and Microsoft. If something is going to happen in those ecosystems, there's very much like a blessing from the people who make the decisions.

15:32 Nick Coghlan: Yup.

15:34 Michael Kennedy: That just doesn't happen here, right?

15:35 Nick Coghlan: Well, and this is one of the interesting things. This might be a bit of a tangent but the hardware system that I worked on for Boeing, a lot of the time I spent working on that was actually as a system architect rather than a software developer. When you're doing system architecture, you spend a lot of time doing, make buy decisions of whether you're going to write something or you're whether you're going to buy something that somebody else is selling, which means you end up doing a lot of, spending a lot of time thinking about incentives and trajectories and why is a vendor doing a certain thing and what does that mean for you using them as a vendor? If you look at the history of programming languages, like C came about because people just needed an abstraction layer over assembly. Like rewriting--

16:20 Michael Kennedy: It was absolutely necessary to us.

16:21 Nick Coghlan: Yeah, so it was absolutely necessary and so that was kind of, that kind of evolved out of the needs of hardware manufacturers because they didn't want to rewrite their own software for every new version of their hardware. That was actually quite a user-driven evolution there. Like, at that point, that was vendors solving a problem that they had and not necessarily trying to use it to lock in customers. But, then you look at things like emergence of Java, driven by Sun to try and stay relevant in a world where Microsoft were eating their lunch. As it turns out, it just made it easier for Linux to eat Sun's lunch. So, I don't think Java actually worked out quite the way Sun might have hoped. Then it ended up at Oracle and Oracle is still trying to use it as a way for them to stay relevant. C# came out of Microsoft after they got into a big argument with Sun over Visual J++. So, very much driven by Microsoft's things of, "How do we do something about this Java thing and make sure we stay relevant in the business software world?" Go, driven by Google, trying to write Think. Apple, really, really want people to develop on Apple, for Apple, exclusively for Apple. They will do your market segmentation for you by excluding anybody who can't afford our hardware. But, it means if you write for Apple platforms you're writing for wealthy people who'll probably be able to pay you. It becomes that thing of, most languages exist in this space of having been designed for a company that's trying to sell you something. Sun was trying to sell you servers. Microsoft wanted to sell you Windows. Apple want to sell you tablets and iPhones and Mac machines. So there's those commercial incentives behind there. Then you come into the Python world and it's like, well, Guido wanted to program his computer more easily and he wanted to make it easier for people to learn to program. So the incentives behind it are very different. Then you also look at how the Python Software Foundation was set up. It was set up as a public-interest charity and not as a trade association. Then you add in the fact that some of Python's biggest vendors don't even recognize that they're in the Python business. They're just shipping this thing that came with their Linux distro saying, "Sure you might want to use this," or, "We use this, you might want to as well." So the vendors are all really quite passive and hands off as well. They're just going, "Yeah, whatever, we'll just do whatever, we'll just ship it." So you end up with this very different dynamic where the large corporations are users but not really driving the direction of the language.

19:12 Michael Kennedy: It's really interesting and I'm sure people who come from the spaces that you named, they look around and they're like, "What? There's really no one group that just tells me the way?" It's pretty interesting. This portion of Talk Python to Me is brought to you by Linode. Are you looking for bulletproof hosting that's fast, simple and incredibly affordable? Look past that bookstore and check out Linode at talkpython.fm/linode, that's L-I-N-O-D-E. Plans start at just $5 a month for a dedicated server with a gig of RAM. They have 10 data centers across the globe so, no matter where you are, there's a data center near you. Whether you want to run your Python Web app, host a private Git server or file server, you'll get native SSDs on all the machines, a newly upgraded 200 Gb network, 24/7 friendly support, even on holidays, and a seven-day, money-back guarantee. Do you need a little help with your infrastructure? They even offer professional services to help you get started with architecture, migrations and more. Get a dedicated server for free for the next four months. Just visit talkpython.fm/linode. So, I think maybe one of the places to start is the Python that you described, back when you started your project in Boeing was being used to solve different problems than it necessarily is now and there, basically, even if you just talk about Python, obviously the syntax is there. But what that means and how people use that could be really different based on who they are and how they're solving problems. We never even read data science code. I feel like I'm reading almost like a different dialect of the language because the mannerisms and the libraries just make it feel really different than say, a web app, that's really broken into little pieces.

20:58 Nick Coghlan: I think I've mainly used Python myself in the use cases of test automation, which I would still say I've used it more for test automation than I have for anything else. Hardware simulators, particularly when you're working on a big thing like HF radio communications. You're not going to have a 10 kilowatt radio transmitter sitting next to your desk. You're not going to have giant antenna switch matrix sitting next to your desk. Even if you do, you might have one or two, which isn't going to scale to automate testing for the whole system. By writing simulators for those things in Python, you can just do that relatively easily and test things that you just cannot test in reality. So that's an interesting use case. Then, yeah, the straight-up web application development dating from the CGI days, which is actually how we wrote the original version of the system orchestration, distributed system orchestration, which you now mostly see in things like Ansible and Salt and the Python wrappers around Docker and Kubernetes.

21:59 Michael Kennedy: Yeah, you even have people doing things like building, like, say, microcontroller code where your Python program almost is the operating system. Like you wire your lambda expressions directly to hardware interrupts. It's like there's this whole thing and, what I think is really interesting and both a challenge and, I think it's a challenge that's been well-met by the language team and Guido, in particular, is Python could be used in all these ways and it doesn't feel like it's built specifically for one of them. You know what I mean? Like if I were to look at R, R is made for a thing. It's for solving math problems. I know you can kind of do other stuff with it, whereas Python also solves math problems really well but it also build web apps amazing, or controls space telescopes, or you name it, or automates hardware, right?

22:47 Nick Coghlan: I think this gets back to the origins in the ABC research language, where the goal of ABC was to be a language for teaching people how computers worked or how to think computationally. Then Python was basically Guido's version of that that you could actually use to, that he could use for automating things. It becomes that thing of that base layer of your imperative procedural programming of, do thing A, do thing B, if condition, do thing C or do thing D, do thing E five times, do thing F until we run out of stuff. That basic procedural stuff. It's fascinating like if you go read standard operating procedures, work instructions and so forth that are written for humans, those are your basic constructs of how we give directions to each other. It's only when you go to build more complex systems do you start needing all of the other constructs of computer science. It's the thing of, you start with imperative programming 'cause that's the way humans think. It's if humans are going to write a checklist or break down a task step-by-step to give to each other, they're going to start with that procedural model. But, there's a reason computer science evolved all these other things because that procedural modeling has scalability issues, both in terms of--

24:14 Michael Kennedy: In terms of complexity for sure, yeah.

24:15 Nick Coghlan: Yeah, yeah, and so, but it's, if you look at the way a lot of languages are written, they're saying they have a very strong opinion on this is how we're going to deal with complexity. That's great if you have a problem which fits well into that complexity management model. The beauty of Python is Python says, "Well, you're going to have procedural stuff in there somewhere, so start with procedural. But, we know procedural doesn't scale to large teams, to large code bases, so we're going to offer you all these other options for refactoring your code as you better understand the problem you have." That basically means you have this common procedural subset but then you have all of these different approaches to data modeling and computational flow modeling and all that sort of stuff where, once you figure out what kind of problem you have, you can move in that direction.

25:15 Michael Kennedy: Yeah and I feel like you kind of captured one of the really special things about the language, and that is you can start simple, but it's not a simplistic language. Whereas Java and C#, they say, "You work in this big formal framework from Hello World onward." You take all the complexity management from the beginning. There's other languages like, say, Visual Basic, that are like, "No, the world is simple enough. We're going to build simple things." But, you hit an upper bound. You're like, "Okay, well, I can't use this anymore because", I don't know, threading, whatever, right? There's just a bunch of things that you can't build with a simpler language and somehow Python's managed to cross that gap and that's pretty awesome.

25:55 Nick Coghlan: I think one of the ways we actually do that is if you look under the hood of a lot of those high-level constructs, ultimately they just boil down to procedural internals. Like, at runtime, we are literally running through and doing stuff procedurally and I think of it as the kind of a no-privileged access concept, which is not actually true. We do have privileged access and the interpreter can do things that ordinary Python code can't. But, as far as we can, we make it so that all of the syntactic sugar that we provide for things like classes and so on and so forth, we do our best to make sure that there is an actual procedural equivalent that any syntactic construct, beyond the basic arithmetic, you can write out a pure Python equivalent. May not run as fast, and you may not get the error handling right, but conceptually there is a Python equivalent that's just procedural code, which is quite fun.

26:59 Michael Kennedy: That's a really cool philosophy. Let's focus on some specific domains. We touched on them a little bit. We have web frameworks, GUI libraries, scientific stacks, and these have all evolved over time. One big example is of the space from this sort of infrastructure world you were talking about is Ansible.

27:16 Nick Coghlan: One of the things I like about Ansible is, if you look at, like Python's basically been part of Linux distributions almost from the beginning. I think it was there in 1.5. It was there in Red Hat Linux. It ended up becoming part of Red Hat Enterprise Linux so they had to deal with the Python 2 transition. Now they're dealing with the Python 2 to Python 3 transition. But any way, by being there by default, and it was always there in all the Red Hat systems because it was part of the package manager, it was usually there on other distros because some utility or other would be on the system that needed it. So it meant that sys admins started doing lots of admin scripting in Python. They'd write these tools in Python and everybody would write their own and then they kind of like going, "Well, hang on, why is every admin having to write their own custom code for all the same tasks?" In a lot of ways you can look at Ansible as the way of going, "Well how about we turn the actual automation bits into modules that you put on a", say, Ansible Galaxy which you can then use from a declarative thing to say, "I want all of this stuff to happen in this order", and that then gives you that more structured notion of what are the concepts that admins need to care about rather than the precise syntax of a for loop or whatever? So you go from this procedural model down at the Python layer, up to a declarative model further up the stack.

28:52 Michael Kennedy: You get so much flexibility when you say, "This is the state I want it to be in. I don't care how that happens. You just make that happen. If you want to change how you do that, I don't care. I just want the end state to have"--

29:03 Nick Coghlan: To look like this.

29:03 Michael Kennedy: "Nginx installed with this as a SSL certificate or whatever."

29:07 Nick Coghlan: One of the phrases I use for this is the idea of executable knowledge, which is the case of, you can have a domain expert write a piece of software and they'd know all the nitty gritty horrible details of how messy reality is because humans and history. But, as the user, you don't need to care. You're just like going, "I'm just going to trust you to know more about that than I do." Say, "Make it so." Then one of the things I love about the scientific Python stack is like people talk about, "Oh programmers need to be good at math." You're going, "No, programmers are terrible at math."

29:45 Michael Kennedy: I have this conversation a lot with a lot of people. They say, "Well what kind of math should I study?" It's like, "You know, I barely use algebra for my job."

29:53 Nick Coghlan: It's the thing of most of us stopped learning math in high school. I did learn a bunch of engineering mathematics and actually working a signal processing job I finally understood what a Fast Fourier Transform was really for, which it never clicked for me in university. But, in my day-to-day job now, I don't use any of that. I haven't used that since I was doing the signal processing stuff. Even when I was using it, the actual Fast Fourier Transform, I just called TI's library to do it. It's the same with scientific stack today. Modern research mathematics is spectacularly sophisticated, whether you're looking at the numeric algorithms an array-oriented programming or Calculus or whatever. But in Python you can just go, "Well, I'm not going to understand all of that myself. I'm just going to import pandas and have magic happen."

30:44 Michael Kennedy: Or I'm going to set up a random forest or some deep learning thing by five lines of configuration or something.

30:50 Nick Coghlan: You're like, "I'm going", and it's a thing of use should be simpler than implementation. You should be able to use things without understanding how they're implemented. I think that's the beauty of how the domain-specific tools evolve, is people are able to write them, expose these common APIs as import magic from here.

31:10 Michael Kennedy: All right, all right. Queue xkcd.

31:12 Nick Coghlan: Then you have access as a user to all of this amazing domain knowledge that you then don't have to, you can learn it if you want to or you may learn it by necessity when it breaks and you're like, it's like, when it breaks, you get to keep all the pieces.

31:29 Michael Kennedy: There's also this difference of being like, "I'm learning it enough to implement it or completely work in it, or I'm learning the concept of it really well." Like, I understand the relational model of a database and indexes and all these things, but I don't know that I could go write a database from scratch without a lot of research. But that's okay, I don't mind using a database. It works fine, you know?

31:51 Nick Coghlan: Yeah, well and SQLAlchemy is another really good example of executable knowledge. I highly recommend some of the talks about the design of that, and the work that goes into keeping things responsive at the application level and avoiding roundtrips to the database while, at the same time, making sure you don't get yourself into the trouble with cache incoherency and all that sort of stuff. It's an amazing piece of work, but, at a user level, it's import.

32:18 Michael Kennedy: Yeah, it's amazingly simple, right?

32:20 Nick Coghlan: Yeah.

32:21 Michael Kennedy: So another really interesting area, especially in the evolution part, is because, you know, Python came out in 1991. So, it's seen a lot of different UI stories along the ways. It's spread so far and wide and, to be honest, the UI story today is so unlike it was in the early days. So, touch a little bit on this evolution through the Windows, macOS, Linux UI story.

32:51 Nick Coghlan: One of the ways this comes up is people are going why Tcl/Tk in the standard library? Tcl/Tk has been there longer than I've been using Python. One of the interesting things is, so when I started working professionally in '98, Linux just wasn't there for the design of big systems. This was actually a source of frustration on the system I was working on because there was a lot of servers where we were running Windows NT on them. We're just like going, "Why?" There were bunch of other servers we were running Solaris on them and we were like going, "Why?" Then you looked at when those operating systems were picked and the state Linux was in at that time and just going, "Uh, yeah, okay, I understand this decision completely now."

33:30 Michael Kennedy: Fair enough, yeah.

33:30 Nick Coghlan: Switching now would--

33:32 Michael Kennedy: Committed, yeah.

33:34 Nick Coghlan: We did end up switching a bunch of those things out for Linux eventually, but, it took some time and it took some work. So anyway, you look in the late '90s, Linux isn't really a presence yet. It's starting to become a thing. But it's ad hoc and experimental and--

33:48 Michael Kennedy: Yeah, and its desktop story is even more ad hoc and more experimental.

33:51 Nick Coghlan: So lots of things we take for granted today just don't exist, like Gnome. Gnome was founded in '98. TkInter was just how you did cross-platform Unix GUIs. If you wanted a GUI that worked on AIX and worked on Solaris and worked on various other things, you used TkInter. Hey, it works on Windows too. Doesn't look anything like it made a Windows app, but it works on Windows.

34:18 Michael Kennedy: Looks like transplated from another world, but, yeah, you could put stuff in the text boxes.

34:23 Nick Coghlan: Yeah, and so Tcl/Tk was the way you did cross-platform in the late '90s. At that point, that was before the PEP process, before SourceForge development, so before any of that, It was like, yeah, IDLE ended up in the standard library, so there was a default editor and it was all cool. But then, as Windows became increasingly popular and as Linux became increasingly popular, you basically had people writing native Win32 apps. You had Qt as a C++ wrapper that tried to use native widgets when it could and emulate it when it couldn't. Then you had GTK emerging as this is the way Linux distros are going to do their desktop applications.

35:07 Michael Kennedy: Right, and just to put in perspective in time, when Windows 95 hit, that was a major, major change in the desktop environment, right?

35:15 Nick Coghlan: Yeah!

35:16 Michael Kennedy: That really was a big splash. Sort of like the iPhone landing in the phone world.

35:20 Nick Coghlan: Yeah, absolutely.

35:22 Michael Kennedy: So it's not surprising that a lot of people went to this Win32 space with MFC or whatever they were using.

35:28 Nick Coghlan: It was also right about then that, you basically could make a good living either selling prepackaged Windows software or software for download. Like the internet was just becoming a thing.

35:41 Michael Kennedy: There was that Tucows and all those places coming along. The internet was coming along. Yeah, it was great.

35:46 Nick Coghlan: It was the idea of, pay to download was a thing. You basically clicked through and gave somebody money to download stuff from their website.

35:55 Michael Kennedy: Another one that came up was wxPython.

35:57 Nick Coghlan: This was the thing of, so, kind of along a similar line to Qt. There was wxWidgets and wxWidgets was that thing of how do I write cross-platform macOS, Windows, and Unixy applications without having to rewrite my GUI for every one? Then so then wxPython wrapped wxWidgets. We had PyQt from Riverbank to wrap Qt. None of these ever got added to the standard library because just the rate of evolution and the size and complexity of the libraries they were binding to, Tcl/Tk's tiny by comparison. It became the case of that kind of started the, to this day, unresolved fight between Qt and GTK on Linux. Personally, I use KDE just because it's, I grew up with Windows, used Windows and DOS since DOS 5 I think. I'm just used to the Windows paradigms of how things work. As much as people who are fond of Mac Os X might go, "Oh, but this way's better." I'm going, "It might be better for you. It's not for me." It's just got so complicated that it was just like, "There is no standard. So there's nothing we can pull into the standard library and say this is the way things are going to be from now on."

37:15 Michael Kennedy: The licensing is a little weird on Qt and so there's just a bunch of stuff that just is not a good fit.

37:21 Nick Coghlan: Like GTK's efforts to support, well, so, the problem with GTK is that its efforts to support anything cross-platform isn't really a thing. It's the, essentially the Linux and Unixy equivalent, of the Win32 APIs. In itself, it's not really cross-platform because it doesn't delegate to platform native stuff when you're running it somewhere other than Linux.

37:47 Michael Kennedy: That's really important because that's what it takes to make your app look like it belongs in that environment.

37:52 Nick Coghlan: Yeah, you have to use the native widgets rather than skinning your own emulation.

37:56 Michael Kennedy: Yeah, so right after this whole sort of thing, the world kind of said, "Okay, well, Java and C# and Windows Forms and WPF and Swing and just all of this stuff kind of scrambled it further."

38:09 Nick Coghlan: That was the C, C++ world which is kind of CPython's native stomping grounds. That was complex enough. Then we had the whole thing of, oh, writing C and C++ directly is really hard, and it's really hard to secure, so managed languages are going to be the answer. Then Sun and Microsoft get into a fight. So you end up with Java and C# and the JVM and the CLR rather than one platform. So that's like, "Okay, cool. That makes life even more complicated for everyone." Then, Apple came along--

38:44 Michael Kennedy: Somehow they became relevant again 'cause they were on the verge of being barely relevant.

38:49 Nick Coghlan: Never gone away completely because they always had that graphic designer/creative artist market, and so there was always that strong core of like, they were always second. Like Windows completely took over the desktop, but Apple always had that five to 10% of die-hard macOS fans. I think it was Autodesk stuff tended to run really well on the Macs. But then the iPhone happened. People are going, "Oh, we need touch interfaces. We can't assume there's a mouse and keyboard all the time." It's like, "Okay, what are you Cocoa bindings like? What are your Carbon bindings like?" I lost track at Carbon. I haven't paid any attention since then. I don't know if it's still Carbon or if they've moved onto something else by now. But, yeah, and so that was like, "Oh, okay, everybody needs to care about macOS X again." Then Google came along and said, "Well, the native base platform for Android isn't going to be the underlying Linux core. It's going to be the dalvik layer." So, if you want everything to run snappily and use native widgets and be nice, you really need to be running in the platform Java Runtime. Then you're just like going, if you don't do that, then you're either going to be bridging into Java which is slow or you're going to be using non-native widgets and emulating the native ones. You so go, "Oh really? This was already terrible and you just made it worse."

40:25 Michael Kennedy: Yeah, and you've got things like Electron JS and Cordova and Ionic and all these other frameworks are trying to make the web sort of fit into this world. They're all pretty neat and every one of these kind of had their space, but it just makes the story harder for what is the path for Python in some sort of UI story. There are some options though, right?

40:44 Nick Coghlan: wxWidets and wxPython when they were designed, basically said, "Okay, there's three big things we need to care about. We need to care about Windows. We need to care about macOS X. We need to care about GTK." So they basically said, "We're going to provide an abstraction layer over those three things. You write to our abstraction layer and then we'll translate it as appropriate for any given platform."

41:03 Michael Kennedy: Have you been tracking the Phoenix Project for them?

41:05 Nick Coghlan: I was for a while because that was the gating thing for their Python 3 support. I haven't looked at it recently though.

41:12 Michael Kennedy: So they just, like this week, maybe, released wxPython 4.0 which it's the whole Phoenix release. I don't know how much that was before but it seems like this might be coming back as a solid option. I actually wrote an app in this this morning and it was really nice.

41:26 Nick Coghlan: That's really cool to hear because there's a, Robin Dunn wrote a book, WxPython in Action, like 15 years ago? 10 years ago?

41:33 Michael Kennedy: Time for her second edition.

41:34 Nick Coghlan: Yeah, yeah, but, I was one of the tech reviewers for that.

41:37 Michael Kennedy: How nice. I think the name says it a lot, right? The codename is Phoenix, like it's back, sort of, from the ashes.

41:45 Nick Coghlan: Because they were tightly tied to the C, C++ libraries they were kind of, that whole Java and C# and the web thing, made life really difficult for them because all these shifting paradigms and expectations were all happening.

42:00 Michael Kennedy: This portion of Talk Python to Me is sponsored by Datadog. With infrastructure monitoring, distributed tracing and now logging, Datadog provides end-to-end visibility into the health and performance of your Python applications. With out-of-the-box support for frameworks like Django, Bottle and Flask, you can start monitoring your application performance within minutes. Start monitoring your Python applications with a free trial, and as an added bonus, Datadog will send you a free T-shirt. Just visit talkpython.fm/datadog for more details. Another one I have high hopes for is the project from BeeWare.

42:36 Nick Coghlan: Yes, and BeeWare's Toga is the one I think is really interesting. So it's still relatively young. Still lots of missing pieces. It's based on that core notion of, to really give a compelling user experience for somebody that is expecting a platform native experience, you need to actually use the native widgets. That if you're emulating the widgets, then users can tell because application can be cross-platform. Users, generally speaking, are not. They're using one platform, they're expecting your application to behave like all the other things on that platform.

43:14 Michael Kennedy: Right, you just want to reach all the users, but they're probably in one place, individually for the most part.

43:20 Nick Coghlan: Generally speaking, users'll be like, they have the native apps for whatever client device they're using, plus they have a web experience. Then maybe they have a native desktop OS as well. But it's increasingly becoming a thing of, now lots of people do everything on their tablet or on their phone. They have no desktop. Toga basically take the point of view of, "Okay, CSS is good as a way of styling things and doing layout and all that sort of stuff. So let's lift that in and use that as the basis of styling your application."

43:55 Michael Kennedy: That's a brilliant design choice, I think.

43:57 Nick Coghlan: Yeah, and so, "Okay, let's not reinvent that. Let's just use that." But, at the same time, now I don't think they use the DOM. I don't think they pulled the whole DOM in, but they made sure that whatever they did was easy to translate into HTML5 DOM. Essentially, what they let you do is, rather than having to choose between, "Am I writing a web app or am I writing a native app?" They treat HTML5 as another target environment. You basically, one of the things you can get out of your project, is a Django 5 progressive web app that say, "Okay, so we target the browser as a platform. There's your web app. Here's your native iPhone app. Here's your native Android app." It's really impressive the amount of underlying infrastructure they've developed for this.

44:48 Michael Kennedy: There's a lot of building pieces, a lot of cross-compilers and a lot of stuff that makes this possible.

44:53 Nick Coghlan: One of the big things they realized was that they didn't have to write a Python compiler for every target environment. What they could do is they could use CPython as the core compiler and emit CPython AST, I think. Then go from the AST layer into JavaScript via the Batavia Project and into the JVM via the VOC project. Then anywhere else that has native C APIs, then they can just use CPython. But it was that big thing of, that in the web they really needed the native JavaScript implementation just because currently the costs of getting from another language runtime into JavaScript to access the DOM is just too slow for really snappy responsiveness on applications. Web assembly might change that once they add some DOM interfaces. But for now it's just--

45:50 Michael Kennedy: Yeah, I'm really interested to see how web assembly's going to affect this 'cause there's a lot of JavaScript, Python to JavaScript options, like Brython, Sculpt, Transcript, Batavia. If that becomes like a native thing that is fast, that actually might be really interesting.

46:05 Nick Coghlan: One of the ways I put it is JavaScript's in interesting position where it's ubiquitous because, for historical reasons, that--

46:16 Michael Kennedy: Because Netscape.

46:18 Nick Coghlan: Because Netscape, but also because we managed to avoid the vendor fight.

46:21 Michael Kennedy: Yeah, that's true.

46:21 Nick Coghlan: Microsoft actually eventually came to the party and said, "Okay, we'll just implement JavaScript as written." and so that Java versus C# style split never happened, which is kind of astonishing.

46:34 Michael Kennedy: Those were bitter fights over the whole browser Internet time, so it's surprising that that LINK Wedge made it through as a shared item.

46:42 Nick Coghlan: It's astonishing that it survived the vendor turf wars. Full credit to them for dealing with that.

46:48 Michael Kennedy: Yeah, but maybe it wouldn't have if JavaScript has been more important at the time. But, at the time, it was kind of like jQuery was the pinnacle. You could animate in a little thing. You could put a little like calendar, but it wasn't like Angular and all these other major front end whereas like, the major part of your app is now that thing.

47:06 Nick Coghlan: I think that is the thing of it. You kind of do need that freedom of, the vendors are there so you have the credibility and the resources, but they're not really paying attention and they're not trying to use you as a competitive weapon, because, yeah, that's when things get really messy.

47:23 Michael Kennedy: Yeah, that's really interesting. Let's focus on another area for a moment. Let's talk about sort of the meta tooling, like the packaging and software distribution story around Python. We have things like Briefcase from the BeeWare guys just the same area that we just talked about. We've got cx_Freeze, IcePy installer and that project I talked about, wxPython. There's a bunch of options and more that we're not even listing. There's pip obviously. But, maybe talk a little bit about the evolution of that kind of stuff.

47:49 Nick Coghlan: This is a fascinating thing because back when I worked for Boeing, we did a lot of stuff with Windows and so we were running Windows installers and writing software that actually properly respects platform conventions, is genuinely difficult.

48:04 Michael Kennedy: It's super difficult, yeah.

48:06 Nick Coghlan: When I worked for Red Hat, one of my biggest complaints was that there basically isn't any developer documentation for here is how to write a well-behaved Linux application. Like, they just don't exist. You've got bits scattered over in the file system hierarchy standard and all that sort of stuff. You're just like going, "The reason people don't write well-behaved applications is they have no idea what the rules are because none of the Linux vendors have actually written the equivalent of Apple's user interface guidelines or Microsoft's user interface guidelines." You need those to say, "What should I be doing? 'cause otherwise I'll just make something--"

48:49 Michael Kennedy: "Where do I even put the program on the computer?"

48:51 Nick Coghlan: Computer, that's right!

48:51 Michael Kennedy: "Once I install it, what's everybody supposed to do there?"

48:54 Nick Coghlan: It's like Linux devs will say, "Oh, but file system hierarchy standard." I'm going, "Have you tried to read that documentation?" It's all written for system administrators. It's like, none of it's written for software developers. So, here is what your application should do. You're just like going, "Okay, so how about we just define a simpler format that lets developers not worry about the whole mess that's out there?" Say like, "You just write your applications a monolithic thing that drops into a directory and just tag bits of it with what they are and then we can write tooling that will distribute things out into the right places." The beauty of working, and this is something we've been working really hard to enable on the disutils level, which is that, so we focus primarily on the developer use case of, "I'm installing this to hack on it, not to just run it as an application." You want to be able to run test suites. You want to be able to install dependencies in order to run a modified version that you've made local changes to. All that sort of stuff. We're really primarily interested in the developer experience. But at the same time, we're trying to get to a point where having where we make our description formats actually specified standards, so that applications other than Python itself can read them. Then once you do that and once you start describing things in static meta data formats then suddenly you enable stuff like PEX which is the Python Excecutable Format, and basically takes that and says, "Okay well, here's thing where you just have to add a Python runtime and say run that thing", and also getting to the point of actually having true single binary executables.

50:51 Michael Kennedy: Yeah, for people who are listening, PEX is basically like a bizzaro hack on a zip file that contains a bunch of Python code, right? But it lets you package up everything that you need into like one distributable binary thing.

51:05 Nick Coghlan: Slight tangent, that's actually a case where we made a change through a tracker issue to enable execution of zip files. Then we forgot to mention it in the Python 2.6 what's new. We're like going, "Why does nobody know that Python can do this?" We're like going, "Oh, because--"

51:25 Michael Kennedy: You never told them.

51:26 Nick Coghlan: The only mention is like buried in the newsfile for Python 2.6. We never actually put it in the What's New.

51:33 Michael Kennedy: How funny.

51:34 Nick Coghlan: Then I think it was around Python 3.4 or 3.5 we actually added zipout to the standard library, not to let you execute this thing, but to provide some tools for creating them. Then I think, after we did that, then more people were aware that the capability existed and that it existed since 2.6.

51:52 Michael Kennedy: Why does this exist? Can you actually turn making up part of this? So what do you think about, to me one of the challenges of Python outside the server space, the server space everything seems basically handled to me, but if I want to write an application, let's say I go and use wxPython or PyQT or something like that and I get this nice app. I want to give this, you know we talked about Tucows and the download stuff and here's my zip and I'm going to, like the story for that in Python is, I think it's coming along, but it's still pretty early days. Things like PyInstaller and stuff, you can make these sort of binaries that don't even required Python on the machine for the dependencies. You don't have to describe, "Hey dear user, you begin by creating a virtual environment and pip installing these things." Like that's not the average non-developer workflow.

52:41 Nick Coghlan: That's the average thing.

52:41 Michael Kennedy: Yeah, exactly. So here's my .app or my .exe. There's one thing, I double-click it. That's it. How do you see the current space, where we're going? Are you optimistic around that? Do you think it matters?

52:54 Nick Coghlan: I think it does matter. Interestingly, 'cause it's one of those things like desktop I think is going to go the way of kind of like an artist's drawing table. Most people don't have a drawing table in their house. But if you're a professional artist you probably will. It becomes that thing of, you get to the point where, vast majority of stuff can be done with just a phone or a tablet. But there will be things where, professional things or hobbyist things where you're going, "No, no, no, I want a desktop."

53:27 Michael Kennedy: Right, you know one example, people say this stuff a lot and I do agree with you. One example might be like if you're writing software for your company of 10,000 stock traders. They all look at the market and they have those insane like six-screen, nine-screen configurations. They want their little dashboard to absolutely update insanely fast, just almost client-server style. A mobile app or a high-latency web app or something is probably not going to be a replacement for those kinds of environments.

53:59 Nick Coghlan: Yeah, exactly. You're going to have those specialist applications. I think the direction we're going to go is, again, talking about the BeeWare stuff, I really like the direction they've taken with Briefcase, where the idea is, instead of trying to convince developers to care about all these potential deployment targets, you instead get them to describe the information that they have that they have that the computer cannot figure out automatically in a way that's useful to them for their own development environments. So, in this case, Python-level dependency descriptions, that sort of stuff. Then you just try and automate everything from that point forward. Russell Keith-Magee, the founder of BeeWare has a wonderful demo of, what's it, six platforms in 20 minutes. He does have his machine already set up to publish to all the different platforms. So like he has Xcode stuff pre-installed. But, yeah, so in 20 minutes, he goes from a blank page to a built Android application, a built iOS application, a built Django web application, a Windows Installer, I don't think he has flat pack in there as well yet, but I think he was looking at it. So, yeah, and so it becomes that thing of as a developer you just go, "I write my app and then I can do cross-platform stuff without too much pain."

55:16 Michael Kennedy: Sounds a little bit like what Ansible does for server orchestration.

55:19 Nick Coghlan: I think so. It's about encapsulating that executable knowledge of what does a native app look like on these platforms?

55:26 Michael Kennedy: Are you optimistic on Python as a language for building mobile apps?

55:31 Nick Coghlan: Yeah I think so.

55:31 Michael Kennedy: Somewhere in the future?

55:32 Nick Coghlan: I don't know yet whether that will come about through the BeeWare VOC model or whether it will be a result of getting decent web assembly DOM access and doing things that way or some combination thereof. Because one of the interesting things about web assembly DOM models is it then raises the prospect of potentially exposing native widgets through those interfaces, which all becomes quite interesting.

56:01 Michael Kennedy: Yeah, that's for sure. One thing that might be an interesting path that is not any of the ones you mentioned, those all could be good, and we only need one, right? It could be PyPy actually to some degree or the Pigeon Project, where the way that they got C# and .NET onto iOS and Android was they basically used the JIT Compiler and then just ahead-of-time compiled it. So, if you could get some form of like JIT compilation if it's, say, via PyPy and you just don't JIT it, you just fully compile it for the machine and then drop it there, maybe that would actually be a good path.

56:36 Nick Coghlan: I don't know what the state of PyPI pre-compilation caching is 'cause, certainly, like PyPy's current challenge, I think, is with start-up time and warming up the JIT. There's a lot of ways to mitigate that and manage that and, in particular, mobile environments where people tend not to close applications down completely, they just suspend them in the background, yeah, that does have the potential to work quite well.

57:03 Michael Kennedy: I don't see anybody pursuing it. But it's still yet one more potential path in the future.

57:07 Nick Coghlan: It's actually one of the interesting things is that I still think that there's not a lot of understanding of how compelling and revolutionary PyPy is as a technology. I think it kind of gets back to the case of so many of us are using Python for orchestration use cases where we were kind of like, "If our Python code becomes the performance bottleneck, something's gone horribly, horribly wrong at a system architectural level." Like it's not supposed to be in the critical path. We really frustrate the PyPy guys by the way. Sorry, the PyPy crew. Trying to avoid the guys to that kind of thing. But Intel wrote a instruction set emulator in PyPy. So I think that was the Pigeon Project that you mentioned. They're just like going, "Hey, without tuning the JIT, we're kind of rivaling QMU for performance", and you're just like going, "Seriously? That's astonishing."

58:05 Michael Kennedy: Yeah, the Intel guys are doing a lot of stuff at the like chip level to optimize Python and PyPy. They're doing contributions back. It's really pretty cool.

58:13 Nick Coghlan: That's been really cool. I've spoken to some of those folks. But the interesting thing is, we haven't yet seen anybody try to write a Java byte code interpreter or a LLVM R interpreter or a JavaScript interpreter in the PyPy technology. The interesting thing is, those are the ones which actually have the really, really heated cross-interpretive performance debates, where it's like, "Oh a new release came out. Well, we will have multiple articles. How fast is it on the competitive benchmarks between the different implementations?" That's one of the things you always see for V8 or new browser versions or that sort of stuff. It's like, "Oh how does it do on the benchmarks?"

58:58 Michael Kennedy: Exactly, "We ran this JavaScript benchmark, it's slightly faster than V8 now, so take that." Yeah, things like that.

59:06 Nick Coghlan: We just don't have that kind of competitive performance mindset in the Python world.

59:11 Michael Kennedy: I think that we're headed down that path a little bit. You look at the work that Victor Stenner has been doing to optimize things, sort of around the Python 3.5, 3.6 timeframe, was like, "Look, performance is a feature and we're now going to get serious about making this faster." I think there is a lot of work being done there, but you're right, there's still a long ways to go.

59:30 Nick Coghlan: Yeah, but it's just one of those things like having been in the vendor space as well. It's like you never had customers coming to you and say, "We want you to make a Python code for us to", and so where customers aren't actually banging on vendors' doors, saying "We want you to make this faster," then it doesn't happen. Whereas, in the JavaScript world, we have the driver of browser vendors wanted people using their browser so that they could get their browsing data and it's like, running JavaScript faster meant more responsive websites, which meant people enjoy using the browser more, which then meant that they would use your browser, which meant you could get their data.

01:00:07 Michael Kennedy: Yeah, you're at the end of that line, that funnel by the way. But I think it's really interesting that say, Google, for example, who really doesn't care how you use the web. They just want you on the web more, doing more web stuff to a large degree. It's like, "We're going to build V8 and make this super fast, so that we can make these more engaging apps. So you're just on the web and you might do more searches. So we get to our ad money. We can target you."

01:00:31 Nick Coghlan: "We can show you more ads more quickly."

01:00:32 Michael Kennedy: Exactly. Yeah, that's a pretty interesting thing. So we're kind of getting short on time. So, let's maybe do just a little bit of conversation about how the standard library and the language evolved. 'cause when people think of evolution of Python, they might think, well that means a new library to there's new syntax or some other comprehension I haven't even imagined.

01:00:52 Nick Coghlan: This is what people like think of when they go how Python evolves. So the biggest thing is, essentially, CPython's issue tracker. So one of the interesting things about Python is we haven't gone the direction of actually defining a formal international standard of what it means for something to be Python. Instead, what we have, is we have a informal language reference as part of the CPython documentation. Then, CPython itself is the reference interpreter. I should actually probably say what I mean by CPython because for a lot of people, they go, "What's CPython? We just use Python here."

01:01:31 Michael Kennedy: "I type python, it goes, I don't know what the CPython is."

01:01:35 Nick Coghlan: This is one of the interesting things is, So there's actually two different things. There's Python the language which is the thing you actually type into a text file, which then needs to be interpreted by something or compiled by something. Then the thing that actually executes when you type python at the command line, we call imaginatively Cpython because it's Python implemented in C. In truth, the code base is actually more Python than it is C, but the core engine, like the compiler and the eval loop and the built-in types are written in C.

01:02:06 Michael Kennedy: The core heart, the byte code, is handed off to C, eval.C. There's a for loop and a switch statement in C and that's kind of where the execution happens.

01:02:14 Nick Coghlan: That's where the magic happens. We started using CPython more deliberately and more consciously in more of our documentation actually after the 2010 language and VM summit, which was when we got a bunch of the implementers of different VMs together so Cpython, Jython, IronPython, PyPy and basically talked about how can we essentially help alternative implementations to grow and reduce the barriers to use? Turns out the biggest barrier to use is C extension ApI Compatibility.

01:02:51 Michael Kennedy: Yeah, that's definitely true, yeah.

01:02:52 Nick Coghlan: That's--

01:02:54 Michael Kennedy: That's both the cursing and the blessing of it. Because, without that, the scientific computation stuff just wouldn't happen here.

01:03:01 Nick Coghlan: Yeah, and that's right. So that's been a ongoing challenge for a long time. We're working on that, which gets us back to how the interpreter and language itself will evolve. The core of this is the issue tracker at bugs.python.org because that's actually not just bugs, it's also enhancement requests. So one of the categories there is enhancement. That becomes a case of, "Oh, we think this API should be added. We think this API could use another flag on it." That basically becomes a case of, "Hey, can we make peoples' lives a bit easier once they can change their baseline version of Python more easily?" One of the other things that's making this more desirable and have it happen more often is when we're getting more and more organizations now that have automated testing regimes that are sufficiently robust that updating to a new version of Python is no longer scary.

01:03:56 Michael Kennedy: Right, things like tox and whatnot that can do multi-version targeting and stuff, right?

01:04:01 Nick Coghlan: Yeah, but also I think when Python 3.6 came out, I think Facebook had upgraded their production infrastructure in less than a week.

01:04:09 Michael Kennedy: Yeah, yeah. They're like, I remember the tweet, I think it was from Jason Fried. It was something to the effect of, "Python 3.6 came out on Tuesday. We're now running on Python 3.6 in production." It was like Thursday that he sent that message out. It was incredible, yeah

01:04:22 Nick Coghlan: Might have been Lukasz maybe.

01:04:24 Michael Kennedy: Oh yeah, yeah, could have been actually, yeah, yeah, could have been.

01:04:26 Nick Coghlan: Then someone replied going, "I just thought about the sheer scale of that. That's nothing short of astonishing." But, the thing is, with CI auto-deployment pipelines it becomes that thing of, you submit the PR that changes the base version in your docker image, and if CI passes, well, you have just as much confidence in that change as you do in any other change to your code base. You're no longer talking about, "Oh rebase means weeks or months of manual QA anymore, a rebase just runs through the same CI as everything else."

01:05:03 Michael Kennedy: Well, and you also have these sophisticated deployment techniques I'm sure places like Facebook use for their, they don't necessarily switch everything. Maybe 1% of the traffic hits the new one, and then 20 and then 100%. They can gradually throw that out to the world before it hits millions of people and see what happens.

01:05:19 Nick Coghlan: It's that thing of, because automated testing has gotten so much better, rebasing to new Python versions is easier, which means that they can more quickly get to the point of, "We got the enhancement into the core. That means we can get rid of our workaround for that capability not being there." The payoff for that is like within the couple of years that you can plan around. You can say, "Okay, we'll do the hacky way now. We'll get the proper fix into the core. Then we can throw away the hack in several months' time." That gets a lot more attractive. Whereas, in more traditional environments, you may be supporting old Python versions for five, eight, 10 years, which kind of kills your incentive to say, "Oh I need this in the standard library." You go, "Well, no, I really don't. I need it in a library that I can upgrade."

01:06:11 Michael Kennedy: Yeah, you got to be able to pip install that 'cause you're not changing the base runtime. Yeah, very interesting.

01:06:17 Nick Coghlan: So, getting back to the enhancement requests. Filing the enhancement request is kind of the first step. It's like, hey, that can be, so you can either do that directly or you can post to the Python-ideas mailing list and say, "Hey should I file an enhancement request for this? How's it likely to be received?" Enhancement requests, it's easiest to get a good review for modules that actually have an active maintainer. So, in the Python Developer Guide, we have a page called the Expert's Index. Essentially, the Expert Index, as core developers we can add ourselves to that in particular areas. Essentially, when we add ourselves, we're saying, "I feel both confident and entitled to make design decisions about this module or about this part of the interpreter." Quite often, the biggest problem that folks with enhancement requests face is that they're not being explicitly told, "No." It's that nobody's telling them, "Yes, we're going to do that." Quite often, the reason nobody's telling them, "Yes." is that nobody feels both confident and entitled to say, "Yes that's a good idea."

01:07:19 Michael Kennedy: Right, exactly. 'cause it's sort of out of their little specialty and so, it's just floating out there.

01:07:25 Nick Coghlan: It's just like going, "Well, it might be a good idea." I think, for a long time, there was a proposed improvement to MIME type handling in the standard library. It just kind of sat there forever because we didn't actually have any MIME experts on the current team and it was a huge change that combined, it didn't clearly separate a massive refactoring of the MIME handling module from, "Here is the bits that are actually wrong that need to be fixed." At that point, you just kind of end up at an impasse because you're just like going, "Well, we're not confident enough in the change to say yes to it. But, at the same time, we're pretty sure the status quo isn't right."

01:08:05 Michael Kennedy: Right, that's tough, but yeah, I see it. All right, so how about the language? What if we want a new feature in the language? I want a triple slash to mean something. I want to put that in there.

01:08:15 Nick Coghlan: Okay, go to the triple slash. Okay, so that actually starts the same way. Either on the Python-ideas mailing list and that's, basically it's very hard to go wrong starting with the Python-ideas Mailing List. You're just going, the main way people go wrong is they present their idea with the implication that it's an obviously good idea and we're clearly idiots for not having implemented it already. That tends not to go over so well. But so a lot of these--

01:08:44 Michael Kennedy: So how do you win friends and influence people right?

01:08:45 Nick Coghlan: Yeah, that's right. So long as people come in with a genuine questioning mindset of, "Would this be a good idea?" Or, "Might it contain the seeds of a good idea?" That tends to be a much better foundation for discussion because either it will not be a good idea. There's a comment along the lines of, the number of ways we can make Python worse is unbounded. The number of ways we can make it better is a relatively limited subset.

01:09:14 Michael Kennedy: Or is always better in a language. I feel like there are some language designers, you know I'm thinking like Swift and the C# team. They seem to just be like, "Well, we have a job as language designers, so we're going to continue to design the language. What features are we adding this shipping period?" It's like, "Well, there don't necessarily need to be more features. You're just making it worse now, all right? It's getting complicated." So I really like that Python is cautious about that.

01:09:38 Nick Coghlan: Cognitive burden is something we think about a lot. Because every time you add to an API or add more keywords or anything, you are necessarily making things harder to learn.

01:09:49 Michael Kennedy: Especially if there's multiple ways to do the same thing. But there's like a slightly better, newer way, it just, it makes it confusing.

01:09:56 Nick Coghlan: When the new way is just obviously better in every way, those are the ones you're really happy about.

01:10:01 Michael Kennedy: Right, like f-strings perhaps, maybe.

01:10:03 Nick Coghlan: F-strings are exactly the example I was going to bring up. Because they're not only the most concise way of formatting strings, but when you can use them they're also the fastest. This is something not a lot of people realize is that with both % formatting and the .format method, Python has to interpret the formatting string at runtime. So it means it has to scan through it, find all the fields, calculate the field substitutions and it's all just kind of horrible and slow. The beauty of f-strings is because of their syntax, you can get the compiler to help. With f-strings, we do all of that thing of breaking it up into segments at compile time.

01:10:44 Michael Kennedy: So, in the byte code or the pyc file, it's like already sort of partitioned it.

01:10:49 Nick Coghlan: In the compiled form, all you have is an alternating sequence of text segment, format operation, text segment, format operation, text segment, format operation. It can basically, all of that string-parsing code happens at compile time and so it's not only the nicest to write and the easiest to read, it's also the fastest.

01:11:14 Michael Kennedy: That sounds like a winning feature.

01:11:15 Nick Coghlan: Yeah, so it was like, "Cool." Then what it means is that then all the other runtime formatting options, they're all still there and you still have all your different tradeoffs between them for when you might want to use them, but for straight-up text formatting, you don't need them anymore. Those kinds of ideas that kind of wean on all the boxes and it's like, those are the ones most likely to get approved. That basic enhancement proposal process of proposing things on Python-ideas or on bugs.python.org, essentially we have an escalation mechanism for those. So if it fits in somebody's personal area of expertise, we may just approve it on the issue tracker and say, "Yup, that's a great idea. It's an area I'm confident making decisions about. I'll just approve it on my own authority, and merge it." So those are wonderful from a contributor experience point of view. It's like, "Hey, I made a suggestion. It was accepted. Cool, I made a proposed change to Python." Those are kind of the exception rather than the most common case. What happens when that doesn't work is we may ask that a suggestion get taken to Python-ideas if it's relatively vague, or to Python-Dev if the suggestion is clear and the bit that's unclear is should we do it or not?

01:12:23 Michael Kennedy: Right, it needs debate.

01:12:24 Nick Coghlan: Python-Dev is mainly for yes or no type questions. Python-ideas is for, "I don't even know what the question is." What should the question be is kind of a useful way of thinking of those two mailing lists. But, sometimes, that's still not enough to resolve the question. In those things, we escalate to the Python Enhancement Proposal process. What that gives us is, it's essentially designed as a way of focusing discussion. Because, one a mailing list thread explodes, you need a lot of time to be able to follow the entire discussion and that, basically, then ends up excluding a lot of people who just don't have time to track everything that's happening in the discussion threads. The idea of the PEP process is to provide a document that summarizes the discussion, summarizes the trade-offs that have been discussed and nominates a particular person to make the final decision, which is basically yes or no or let's put it off and reconsider it later. By default, that's always Guido as the lead language designer. But, we have a delegation mechanism in place where any core developer can say, "I'm happy to make the final decision on this." Basically be responsible for the fallout.

01:13:45 Michael Kennedy: Yeah and that can be wide ranging but, yeah. That's interesting.

01:13:50 Nick Coghlan: In a lot of cases we also use the PEP process when we're like going, "We're happy with the idea in principle, but there's a bunch of lower-level details to work out before it becomes actually implementable." Those cases, there's usually arbitrary design decisions that need to be made along the way. It's like, "It doesn't really matter which way you go. You just have to pick one and stick with it." The BDFL and delegation process is useful for that as well because that's when you just say, "Look, if there's an arbitrary decision to be made, this is the person who makes it." The beauty of this is that it gives us a way to say yes to complex suggestions. I think the record for getting a complex proposal through from proposal to implementation was something like eight days to add the matrix multiplication operator from the point where Nathaniel submitted the PEP to when it was actually implemented. That was an interesting one. Because that actually came out of Nathaniel researching the history of operator proposals to Python and it turned out nobody had ever actually suggested, "Let's just add a matrix multiplication operator." They'd always just gone, they'd all been the case of, "Let's add the ability for users to define their own infix operators." They'd always failed on the basis of not adequately demonstrating the use case. Then what Nathaniel did was, he went and looked and talked to all the scientific community and said, "What are we actually feeling pain for about? He went, "Well it turns out, we're really only feeling the pain for matrix multiplication because you need a way to spell element-wise multiplication and you need a way to spell matrix multiplication." Python just simply didn't offer enough infix operators to let you do that, like you needed, so you had to choose and it was all very complicated. Nathaniel really did his research, understood the problem, wrote the PEP and said, "This is the problem. This is what we want to do about it. This is why we chose the symbol we did." Guido went, "Sure!"

01:16:08 Michael Kennedy: Yeah, that's awesome. That's a real blueprint for other people who want to do stuff like this.

01:16:12 Nick Coghlan: It's still my favorite enhancement proposal to this day because it was just a beautiful example of researching the problem, understanding the need and explaining it clearly to people that weren't in that environment and weren't regularly writing scientific software. One of the cute things was that it would have been even faster except that there was a question in there about left associativity versus right associativity where the description in the PEP was, "We didn't ask for this because we assumed you'd say no." Guido went, "No, no, no, I might say yes if you have a valid use case for it." It was like, "Oh, okay. We need to go discuss that on the scientific mailing list to figure out what we actually want then."

01:16:58 Michael Kennedy: "We'll get back to you."

01:16:59 Nick Coghlan: Yeah. There was an extra couple of days in there when they went and figured out, "Do we actually want that?" They came back and said, "Well, we don't actually want it."

01:17:07 Michael Kennedy: That's cool. That's a really nice example. All right, we're totally out of time. I want to still get you with the last two questions as I always do. So, if you're going to write some Python code, what editor do you use?

01:17:17 Nick Coghlan: I use VSCode these days and I used Katie's Kate Editor for a very long time and it was only the VSCode has better Python plugins.

01:17:26 Michael Kennedy: I think VSCode with the Python plugin is a really nice option so I definitely like it as well. Notable PyPI package. You've seen many.

01:17:34 Nick Coghlan: Notable PyPI package. Oh...

01:17:37 Michael Kennedy: Maybe something that somebody doesn't know about. Not the most popular, but like, "Oh, they should know about this thing that they probably don't."

01:17:43 Nick Coghlan: Hang on, that's a different question. One that I'm really, really pleased that it exists is NiPy, N-I-P-Y. That is neuroimaging data manipulation. I personally have no use case for it. I'm just really, really happy that it exists because it exists.

01:17:57 Michael Kennedy: Yeah, that's awesome.

01:17:59 Nick Coghlan: That's just really cool. So one that I really, really love using for writing command line applications, is Click. So Click for writing command line applications. I think a lot of people have heard of that one.

01:18:11 Michael Kennedy: But it's still a really nice option.

01:18:13 Nick Coghlan: Yeah, it's just, as a way of writing command line applications that are easy to test, easy to compose, easy to write in the first place. The fact that it puts your command line parsing right next to the function that implements a given sub-command is just a really nice way of doing things.

01:18:31 Michael Kennedy: Very, very good. I definitely like those recommendations. All right, so people are excited. They have ideas for improving Python at many levels. They want to get in touch with you. What's the final call to action? Not you in particular, but you as a group of people who make these decisions.

01:18:43 Nick Coghlan: Python Developer Guide is a really worthwhile document to read. We had a lot of common questions about how do I get started hacking on Python? How do I make suggestions for changing the language? Essentially, we try and make sure the Developer Guide answers those. Does make it rather large, but it's a complicated project. The other one I would point out is that posting suggestions to Python-ideas is almost never the wrong thing to do. Just make sure they're phrased as suggestions, not as demands.

01:19:15 Michael Kennedy: Yeah, you're asking a favor, so approach the situation that way, right?

01:19:18 Nick Coghlan: Yes, exactly.

01:19:19 Michael Kennedy: Yeah, awesome. All right, well, Nick it's been really great to share your perspective on all these changes at Python. It's been great.

01:19:26 Nick Coghlan: Okay, awesome. I've had a great time. Sorry if I rambled a little bit but I really enjoy talking about this stuff, so--

01:19:33 Michael Kennedy: Yeah, it's really interesting. So, thanks for taking the time. Talk to you later.

01:19:36 Nick Coghlan: Okay, thank you very much.

01:19:38 Michael Kennedy: This has been another of Talk Python to Me. Today's guest has been Nick Coghlan and this episode has been brought to you by Linode and Datadog. Linode is bulletproof hosting for whatever you're building with Python. Get four months free at talkpython.fm/linode. That's L-I-N-O-D-E. Datadog gives you visibility into the whole system running your code. Visit talkpython.fm/datadog and see what you've been missing. They'll even throw in a free t-shirt for doing the tutorial. Are you or a colleague trying to learn Python? Have you tried books and videos that just left you bored by covering topics point by point? Well, check out my online course Python Jumpstart by Building 10 Apps at talkpython.fm/course to experience a more engaging way to learn Python. If you're looking for something a little more advanced, try my Write Pythonic Code Course at talkpython.fm/pythonic. Be sure to subscribe to the show. Open your favorite podcatcher and search for Python. We should be right at the top. You can also find the iTunes feed at /itunes, GooglePlay feed at /play and direct RSS feed at /rss on talkpython.fm. This is your host, Michael Kennedy. Thanks so much for listening. I really appreciate it. Now get out there and write some Python code.