The Quick Python Book

Why is it better to start with functions before going into classes when learning Python? Join Naomi Ceder, author of "The Quick Python Book", and Luciano Ramalho, author of "Fluent Python", while they talk about the things they love in Python. They explore the new developments of the language as static functions and concurrency, and chat about the reasons for which the language is so popular. They also touch on a business version of Python.

---

Intro

Luciano Ramalho: Hello everyone. This is Luciano Ramalho, I am the author of "Fluent Python." And today I have the honor to interview Naomi Ceder, who is the author of "The Quick Python Book," the third edition, which is now in the third edition, the book. So, Naomi, please introduce yourself.

Naomi Ceder: Yeah. Hi, I'm Naomi Ceder. As Luciano said, the author of "The Quick Python Book," and also another live project series from Manning called "Explore Python Fundamentals," which is a hands-on sort of project series on Python basics. And I used to be the chair of the Python Software Foundation.

Luciano Ramalho: Awesome. Now tell me, what's the format of that live... What's the name? Live with Manning?

Naomi Ceder: "Live Projects."

Luciano Ramalho: Live project. Is it a video?

Naomi Ceder: It's a combination. The "Live Projects," started out being sort of a more static series of projects where like you would read the text and then you would solve the problem. But one of the things...

Luciano Ramalho: Oh, interesting.

Naomi Ceder: We added videos. So basically there are still little groups of projects, like exploring how variables work by doing these things, but we have demos on the video to get people started. And then we go through all of the exercises with at least a version of the possible results. I mean, the idea is people will do their things, so they might not do the same thing I do, but at least they would have a reference.

What's new in the third edition?

Luciano Ramalho: In the last chapters you talk about, they are more project-oriented, and what was your favorite project among those in the book?

Naomi Ceder: I guess that's kind of a hard one to answer in a way. The thing that I've always sort of done a lot with is the sort of processing files, and I don't know the whole process of ETL and all of that, it's kind of a boring, basic process, except that it holds so many problems and so many possible solutions that even though it seems like it must be the same thing over and over, it never is the same thing over and over. If it were automated, we wouldn't have to think about it anymore. So it is always a different problem.

Luciano Ramalho: Exactly. This whole domain of ETL, right? Which is extracting and transforming. And what's there for, I forgot now. Anyway, it has to do with the process...

Naomi Ceder: That's load.

Luciano Ramalho: Oh, yes, load. Exactly. You have to take data from somewhere, sometimes reshape it or convert it, right? And then loads it somewhere else. It is a whole class of programs for which Python is extremely well suited in my opinion. 

I like that part of the book. The next chapter talks about data over the network. So you explain how to use Python to get data from an FTP server, which is something that's too widely used in science, right? Scientists like to exchange...well, of course, they started doing that before the web existed, right?

Naomi Ceder: True. Well, and it's also kind of a least common denominator because even in my current job, there are departments where maybe they're not quite as sophisticated in terms of responding to APIs and things like that. But pretty much everybody understands how to do FTP and all the tools will do some sort of FTP or SFTP. So, yes, it's still a common thing.

Luciano Ramalho: Then you talk about APIs, and data formats like JSON and XML, and then scraping data from the web. I think you use "Beautiful Soup," right?

Naomi Ceder: Yes.

Luciano Ramalho: That's a neat project that maybe doesn't have an awesome SEO because of the name, I don't know. But it's really, "Beautiful Soup." Yeah.

Naomi Ceder: It is. And it's, again, something that we use, my team at work, and something, I don't know, for many years, it's been the go-to.

Luciano Ramalho: Then there's a chapter about saving data, which I like the name, and it's about databases and covers relational databases using the Python database API with SQLite, and then MySQL, and then SQLAlchemy, which is cool. And then no SQL databases, in which you have examples with Redis and MobileDB. I used to work at...

Naomi Ceder: Of course nowadays...

Luciano Ramalho: ...when there's no SQL movement. Go ahead.

Naomi Ceder: No, I was just going to say, and nowadays, of course, I think both Amazon and Microsoft with Azure around flavors of no SQL databases as well, but they're all pretty similar. 

Luciano Ramalho: It's funny because they are similar in some ways, but they are also very different in many ways. So I have a slide when I used to talk about most SQL databases when that was, the topic was springing initially. I had a slide showing four cars like there was a Cadillac, a Volkswagen Beetle of the old type, what's the name of... Is it, you know, that's one of those tiny cars that only fit two people, that they did in Europe? And the fourth car is, oh, I forgot. Anyway, oh, the fourth car was like a very low-cost Brazilian Sedan, and those four... So those are cars, all right? So, of course, they are different things that the Cadillac had certain characteristics, the Beetle is excellent to park, which they won't put on the road.

It's sort of the same kind of comparison that you can do with Oracle and Postgres, and MySQL, and, I don't know, maybe Microsoft SQL server. But then when you look at this scenario of no SQL database, I have another slide in which I show the lunar rover, one of those vehicles that, I know an aircraft tractor that you see in airports, right? A backhoe. So they are all like four-wheeled vehicles, but they are very specialized and you wouldn't use one for whatever the other one does, right? This just doesn't work.

Naomi Ceder: That's a fair point.

Luciano Ramalho: And with SQL databases is kind of like that. Many of them are very specialized, like Redis for instance. But then MongoDB, in my opinion, is like one of those Volkswagen buses. In Brazil, the Volkswagen bus was extremely popular as a small van for everything, for carrying people, for carrying cargo. There were millions and millions and millions of those in Brazil. And so it's a very versatile thing. It's not excellent in any role.

Naomi Ceder: True.

Luciano Ramalho: With MongoDB, you won't go too wrong by adopting it, but there's probably a very specific case. That kind of reminds me of a joke about Python that people do, that Python is the second best language for everything, right?

Recommended talk: MicroPython & the Internet of Things • Damien George • GOTO 2016

Naomi Ceder: There you go. Right. I think that's fair. I think it's fair with no SQL databases too. I think actually, I chose Mongo because it is used for so many things and is popular in that way. I think I chose Redis because it's so popular, particularly if your key value stories and memory, it's so popular for caching applications and things like that.

Luciano Ramalho: Yes, exactly.

Naomi Ceder: So, those were a couple of popular things that are worth mentioning. 

Luciano Ramalho: That's right. Some people use Redis for some kinds of cues also, right? I think.

Naomi Ceder: Yes.

Luciano Ramalho: Then the last chapter is about exploring that, and then you go a little bit into the data science ecosystem with Pandas and Jupyter, that's real to have in a Python book, I think, these days. Because this is a very good book to get started. I want to say that to everybody who's listening. I love this book and I always loved it. I read the first edition, the second edition, and the third edition. And it was always from the start, like 20 years ago almost, a very good first Python book, in my opinion, if not the best at the time. There are other books that people used to read to get started, but they were of a different style. But this is good. And then talking about projects...

Naomi Ceder: I've heard from various people that it's the book they used to get started and they then went on and got like their first job in Python. So things like that. 

Luciano Ramalho: No, that's a very good kind of testimonial. Yes. Congratulations. And you deserve it. Then we were talking about projects and then the book ends with a pretty good, I mean, extensive, right, like 15 pages of a case study, which is interesting, right? About a case study involving parsing data, about the weather, and so on. Yeah. It's really interesting. I also look at the end of the... Go ahead.

Benefits of limiting classes

Luciano Ramalho: There's so much good stuff here. I like very much your approach of covering functions in a part of the book, which is like the essentials you call it, you cover functions very deeply talking about even local and things like that, all the good stuff about parameter parsing in Python, which is very flexible. And then you go to talk about modules in Python programs, and then you have advanced language features, and that's where you put classes. Can you talk about this idea of putting classes in an advanced language feature?

Naomi Ceder: Yeah. It might be partly that I started programming a long time ago, and sort of before objects became all the fashion. So maybe that's part of it. But I think it's also...that's also maybe that I spent, I don't know, like 15 years teaching in a high school, teaching programming. So I had a good chance to see how people learned and what they had struggled with. So, when you think about it, you can do a lot with functions and functions are fairly easy conceptually for people to grasp, not super, super easy but if you, you say, look, you're going to put some of your code in and in the effect of making new command, a new thing that you can tell the language to do.

Luciano Ramalho: That's nice.

Naomi Ceder: Yes. They get that. There are always things where beginners maybe have some wrong assumptions or whatever, but they get that, and they can start doing things. And once you have functions, then you can start making some programs that do quite a few things without confusing yourself. Again, I remember starting in BASIC back in the '80s and it was, I think there was a ghost up and you could sort of do functions, but nobody ever did. There was always long, long, long, and very confusing. So, yeah. So this is a way to manage that.

And as I think we've talked about before, I did a frequency count on most of...on a lot of my everyday code on what things show up most. And after if statements and loops and things like that, functions were what I used most for everything, and classes were very few. I think if you look at a lot of people's code unless they're working on a massive, massive project, if they're working on something small to medium size, you're gonna be using functions a lot more, unless maybe you learned Java first in where you're told everything had to be a class. So Java programmers moving to Python use a lot of classes that they don't need to. So, that's why I would call functions a basic thing and classes an advanced thing. Certainly, many good things to be done with classes, not saying you shouldn't use them, but there are many more things that you can do with functions, in my opinion.

Luciano Ramalho: Yes. If you ask anybody really to stop and think, you can only get one feature, will it be functions or classes?

Naomi Ceder: Yes. Right.

Luciano Ramalho: Well, in fact, classes can't work without functions, right? Because the methods are functions Indeed.

Naomi Ceder: It is. I have a lot of fun when I teach people like intermediate Python and we take a bunch of functions in a dictionary and turn it into a class. And if they're new to Python, this is shocking to them. I didn't realize it was that simple. Yes, it is. And I think too, classes are much more complex by nature conceptually because you're not just tracking functionality, you're now tracking functionality and state within that object, which isn't the same as the state of the overall program. So you're now tracking in effect the nested state, which just is hard for beginners. Certainly, if you've done it for a long time, you get better at it, but it's hard to do that and keep track of things. 

Luciano Ramalho: Totally. Yeah. That's very true. Yeah. I think one of the things that people are learning is about the limits of classes and the benefits of limiting classes. So, for instance, one of the most successful languages of the 21st century, created in the 21st century is Go, and Go... Well, they do have classes, but they don't call them classes, they call them struts and they have methods, which to me look very much like a class, and the strut can have private views and so on. It's a class, except that it doesn't implement, it doesn't support inheritance, which is a big problem. I think one of the problems of teaching programming in general and Python also, is to overemphasize classes at first, which is something that unfortunately happens a lot, maybe because of the influence of Java, as you said, or maybe because of some kind of academic bias, I don't know.

Recommended talk: Live-Coding a Dashboard with KSQL, Python & JavaScript • Kris Jenkins • GOTO 2021

Naomi Ceder: Yes. Could be that.

Luciano Ramalho: Right? People who like abstractions, like to think in terms of categories and subcategories, that's very appealing, but turns out, not very useful, right? So, I have a poster...I have a poster in my office of the Java class library, there was an earlier edition and a later edition, but it's very interesting if you look at it because it's a diagram, the poster is a diagram of the class hierarchy, and it's very shallow. It's so shallow that the poster is written in six columns. The only parts that are kind of deep in the diagram are the ones that have to do with GUI, which interestingly, was the setting where small talk was created in all the terms, the idea, the name of the concept of classes, and a lot of the... Well, even the name object-oriented was created by that team.

Naomi Ceder: That's a good point. That does make a lot of sense in a way.

Static typing in Python

Luciano Ramalho: I want to ask about your opinion about typing, static typing, because I didn't see anything about static typing in your book, and I'm not criticizing it because of that. I like the book. I also like very much Dave's business book that came out only a few months ago called "Python Distilled," which also does not cover types. But what do you think of this new whole area of growth impact?

Naomi Ceder: So I think I'll start meandering off, but I promise I'll get to the point. I think one of my favorite tweets that Dave Beazley, just to speak of Dave again, recently was that he said that what he didn't like about the way Python was going was the fact that it switched from solving problems with Python to solving problems with Python. That is we're worried more about the language than we are about what we do with it these days.

Luciano Ramalho: About fixing the language, right? I'm doing triple quotes here, triple quotes.

Naomi Ceder: Right. Yes, absolutely. I understand that we have a certain number of big enterprise projects now in Python, which maybe we didn't use to have. And they certainly like the idea of having sort of a more typing language. With my team at work, we've got a medium-sized project that we're putting in a few type-ins as we go. But I'm not a huge, huge fan of typing.

I think there was a recent discussion on the Python dev mailing list where somebody made the point, I do not want to decide features based on whether or not they will make typing easier. And this was just in the past couple of days somebody said that, and I was like, I 100% agree. I don't think that static typing should be an essential feature. I don't know that it should decide language features at all. The people who need it will certainly figure out ways to do it. And those tools will continue to develop, and that's fine, but I'm very, very leery of anything that will make people who do not need it have to, or feel obligated or whatever, to do typing, because I think that is...it goes against the readability of the code, honestly. As much as people might say it's wonderful, when you read a function signature and you have to parse out all of the types, that is intellectual overhead that I don't think we need much more time. So I'm kind of a slow walker on that.

Luciano Ramalho: There are plenty of pathological examples, right? I helped fix or improve the type hints for the max and mean functions, and new things. On Typeshed, I found... I was studying the subject for my book and I found a bug report there, that the signature of the max function was too permissive, so it was letting bad data get in, or...well, actually it's not a runtime check, and the way I said it makes it sound like it. But anyway, it wasn't detecting when somebody was passing a list that could have an outlier inside. And if there's an outlier inside, then max doesn't work because it has to sort. It’s not comparable with numbers, for example. So that blows up. When I went to look at it to try and fix it, there were already three or four lines of overloads. And when I was done with it, which took several days, I was helped by [inaudible 00:27:13], who is one of the most prolific contributors of Typeshed and typing in general, he helped me a lot. The first Pi I made to fix max or the typings had eight overloads and he showed me how to simplify it to only six.

Naomi Ceder: There you go. Wow.

Luciano Ramalho: And that's one very pathological example of a function that's not hard to understand what it does in practice. If you go read the documentation, okay. You know, everybody's able to use max very well. I never heard anybody saying that max is super complicated to understand. But with the type hints, it becomes unreadable, but it is a pathological example. Sometimes I do think that the type hints make code easier to read, but that's only when they're very simple, which happens a lot. For instance, in some interesting applications like FastAPI, and by a pedantic framework that allows you to create little classes that have types that are run-time checked, I think that's neat. The type hints are usually very simple because they are concrete data. There's no reason to be fancy with them, right?

So it's a good use case, but interestingly, it's not a use case that is most concerning to the huge enterprise users of Python. They want the static checking, right? Because they have millions and millions and millions of lines of coding, whatever they can catch before going to production is going to save them a lot. But they were moving in a direction that was making it harder for FastAPI and pedantic to do their job, to make it easier for the huge enterprise users to use static typing. That was the whole thing about delaying the valuation of the type hints and so on.

It was something that solved the problem that only really huge companies have because it was affecting performance when starting a system that has type hints. So there was this cost that is only meaningful if you have a lot of lines of code, hundreds of thousands, right? So this is a little bit concerning to me too. I sometimes think that maybe it would be healthier if they came out with an enterprise Python, EPython, epython.org. Then they're gonna release it...

Naomi Ceder: It might eventually happen.

Luciano Ramalho: I don't know, because...The thing is, this is what...of course, there are other reasons, but it's also a good reason for doing what Microsoft did with TypeScript, right? So this is not JavaScript, it's TypeScript.

Naomi Ceder: True. So it is true that leaving out typing was a deliberate choice because as I thought about people who are coming into the Python world, I just felt, that this is not going to be something that they need to deal with right away. Or perhaps if they do, then they're on a team where there will be other means of doing that.

Luciano Ramalho: Exactly. What I think is the community is very big, right? And it's very diverse, one of the things that I've always loved about Python, is the diversity of the community in all dimensions, in terms of nationalities, genders, applications, and professional domains where people work, right? So, if you are an analyst, like a financial analyst that uses Python as a tool, who doesn't put systems in production, then typing is not a great investment of your t, time, in my opinion, it's better to learn Windows better, learn other things like that.

Naomi Ceder: Or the people doing data science or even scientific computing, they probably aren't worried about that. 

Luciano Ramalho: Exactly. Yeah. And the kinds of data, because types have to do with data structures in OEO, right? The kinds of data that they use are already very well defined, right? These are ways, sometimes there are records. Their libraries already provide everything they need to do that, right?

Recommended talk: It Really is Easier to Ask for Forgiveness (than Permission) • Naomi Ceder • GOTO 2019

Naomi Ceder: Well, I mean, and it's kind of interesting too, particularly scientific computing is what is... I don't know, I guess you'd almost say conservative. I've got a good friend, we've been friends since we were children, who are research physicists. He does things like analyzing gas composition, he's done a lot of climate science and things like that. His tool of choice is still Fortran. I mean he will use other languages, but if he has the choice, yeah.

Luciano Ramalho: Another thing that I like in the book, still in the basic part, which like we were talking, it makes perfect sense, you know. Before you go on inventing classes, which is probably what people need about testing Python mostly knowing how to inherit from a class when the framework requires, right? Like you're doing a journal app, you need to do a subclass of models. But usually, I don't think it's a very good idea to come up with your classes unless you're doing something already pretty big. Most of the classes you're gonna have initially are just something that classes that represent tables, right, in the database or collections in mobile or tables in both using SQLAlchemy.

Naomi Ceder: And I always remind people in that kind of situation, if you write your class, you then have all of your bugs to fix, whereas if you can use in data type, then somebody else is responsible and has probably fixed those bugs.

Luciano Ramalho: Yes. This is something that I always tell people who are getting started with Python. Python is very well done and is extremely high quality. And so as a beginner, it's extremely difficult for you to find a bug implanted, right? Because the parts of the language that everybody uses are industrial strengths because they've been refined over decades, right? They are used in very large contexts, but then I like the fact that before teaching classes, you already explained how to create programs, right? Programs, scripts that people will run and you show how to run on Unix and Mac and Windows. This is cool.

Naomi Ceder: I would like to think that if somebody was in a hurry, and they only went through the essentials part, they would be able to, in most contexts they would be able to be productive. They might not be everything, but they would be able to be productive.

Standard functions before regular expressions

Luciano Ramalho: Yes. It's very good, it's very pragmatic, your approach. I congratulate you. This is cool, including distributing Python applications, which is interesting also, right? Because sometimes that's what you need. Sometimes you are in a community, maybe scientists that belong to a certain research community, and somebody creates a program that does ETL of some science data, and you want to distribute that to labs that may use it. So this is very good. You also cover... But then in the advanced language features, which are good after classes, regular expressions. What's the famous phrase by Jamie Zielinski, you know?

Naomi Ceder: Oh, right. It's sort of like, you've got a problem and you want to use regular expressions, and now you have two problems.

Luciano Ramalho: Yes.

Naomi Ceder: It's true. It's not the first tool I reach for, but so many times it ends up being maybe the solution after all.

Luciano Ramalho: One thing that I think is interesting is to tell people about functions in the Python standard library that you can use instead of regular expressions for certain use cases, right? I think Python has a lot, for instance, starts with, ends with our stuff. Those are two simple ones that in many other languages, people have to use a regular expression to do, right?

Naomi Ceder: The string translate is another one for people cleaning data.

Luciano Ramalho: Oh yes.

Naomi Ceder: Sometimes that can save you a lot of trouble.

Luciano Ramalho: Exactly. I also like your coverage of Python libraries from a user perspective. So what's the story with the cheese shop?

Recommended talk: Taking Machine Learning from Research to Production • Robert Crowe • GOTO 2019

Naomi Ceder: I think you've been around Python for several years and so have I, and it was interesting back in the old days, they had several libraries or repositories, I guess, places to get Python code. Wasn't there like a Starship Python or something like that and various other things? But then for a while, they were calling the Python package repository, the cheese shop, which it was, you know, Monty Python jokes are common, but this one, I think a lot of people pointed out. It always struck me as odd too, because you remember the point about the cheese shop is, that there's no cheese in it. Maybe it's just as well we moved on.

Luciano Ramalho: No, I think it's a great name because if you think about when it started, there were no, or very few, you know, it was nothing compared to CPAN, right?

Naomi Ceder: True.

Luciano Ramalho: Yes.

Naomi Ceder: And that was I think years ago, I think maybe even in the second edition of this book, I may have said something about how Python has a really good set of libraries and everything. It's not CPAN, but it's still pretty good. And these days I think I would switch that around. But maybe I didn't say it in the book, but I know I've said it in talks and things like that.

Luciano Ramalho: That's right.

What’s the secret of Python’s success?

Naomi Ceder: These days, I think it's different. I mean, and that's kind of what's happened though, hasn't it? Because in the early days, Python always looked at Perl kind of with envy, and Perl was sort of like the mean big brother who sometimes made fun of us and thinking, I remember Larry Walls, like, "I'm not worried about Python." And now I think maybe the tables have turned.

Luciano Ramalho: Although Larry Wall, did bully a little bit in an interview they gave a few years ago. Did you see it? There was an interview with some language inventors, and they were both there and Larry was kind of moving with the web. Python took over the world. I don't think it's meaningful to say whatever language is the number one, because depends on how you count, it depends on a lot of things, but it's certainly...

Naomi Ceder: It does.

Luciano Ramalho: It's a tremendous success. We did a tremendous job in the community after him. So I wanna ask you, what do you think is the secret sauce? What caused Python to be so successful?

Naomi Ceder: So I think there are some things related to the language, as we've talked, you and I have talked about this in the past, but I think the fact that Python is kind of centered around an aesthetic idea of how things should look, beautiful is better than ugly. You know, regardless of how we define beautiful and ugly, I think that's a powerful thing. And I think, part of the beauty in the Python context is readability, which makes it easier for people to deal with. So, there are technical reasons.

I think over the past decade, I think there have been community reasons as well, in that, I've had many people say, "Ah, gee, I know I'm doing whatever language it is," I don't wanna mention, but I think for the community, I think I'd rather be doing Python. So, I think that's also a driver behind it. I think that's maybe what has led to all of these like data science picking it up. Well, sure. It's a good language, but maybe there was also, we were more welcoming than other languages as well. 

Recommended talk: How to Leverage Reinforcement Learning • Phil Winder & Rebecca Nugent • GOTO 2021

There was that same thing for science. There probably are other languages that would do scientific programming quite well, but we made it very welcoming for people to do that. So, I think maybe it takes both. Technical virtues alone, we've seen just the technically superior product fail many times. So that's in itself, I don't think that's it.

Luciano Ramalho: Yes, no, the community is always the key I think because... It's the community that builds the whole ecosystem, right, that makes a language successful. 

Naomi Ceder: I think so.

Concurrency in Python

Luciano Ramalho: I'm also curious about another topic that is also, I don't know, it's... One thing is when there's a community that drives a product like Python, which is community-driven, here's the thing about what different groups within that community consider important. Why do people consider something important I think has a lot of different reasons. Practical reasons are very important, but also sometimes a person is interested in a certain domain, right? Somebody is interested in, for instance, Dave Beazley is interested in concurrency, right? He loves to talk about that. Has given many talks and tutorials about that. And what do you think of Python's concurrency story these days?

Naomi Ceder: I don't know. I think, going on how to help it. It was always in the past the thing where I don't know, when asked to talk about it I would say all sorts of things like the way the language is designed, it's not going to change overnight, etc. I think it's become increasingly urgent. I never did think it was an insoluble problem. I think maybe for a while the community as a whole felt it was an insoluble problem. It was sort of like the four-minute mile. We're never going to go faster than that or whatever other impossible problem you want to choose.

I think that maybe kept people from attacking it. I think that... I always felt it was just a matter of time until somebody just decided they weren't going to leave it alone. And sort of done it until they found something that might work. It seems to me that both the concurrency and the performance story for Python are kind of at that point where we have several people who've decided they're not going to leave it alone until they get a better answer. And I think we're already starting to see a few cracks in that problem. So, I'm optimistic now that we're going to see a new generation of Python in the next, certainly within the next five years that will not be our father's Python or whatever, you know, that we'll have a better story to tell about that. You know, has been in the past one of these things where it's like, you wanna do threads? No, you probably don't, just don't. It was usually my advice for people who wanted to do threads. Unless you're smart enough to have a reason why to argue with me, just don't. But I think that's going to change.

What are syntactic macros?

Luciano Ramalho: Mark Shannon, who is, by the way, somebody who is working with speeding up the title, with increasing the speed of interpreter with their team over there at Microsoft. And he is super smart, I am a big fan of his ideas in Python-dev, and he has this PEP called "PEP 638," called "Syntactic Macros" posted in September of 2020. Can you explain to the people what the feature is, what Syntactic macros are, and whether that would be a good idea or not for Python in your opinion?

Naomi Ceder: I remember that discussion a little bit. I'm not up on the specific details except that the idea of using macros in a programming language is a way to, what should I say depending upon conditions you compile may be different pieces of code. You have different pieces of code based on something you can tell the compiler at run-time, let's say. And I think the basic idea of that PEP, wasn't it to allow language feature changes sort of to be added more easily?

Luciano Ramalho: Yes.

Naomi Ceder: To allow people to try things out without going through the painful process of in effect rewriting the chunk of the code.

Luciano Ramalho: Exactly.

Naomi Ceder: I have to admit, as I recall that discussion, it got into the weeds to the point that I think I may have just put it on mute after a while. So I did not follow all the ins and outs of that. But I was quite attracted to the basic idea. If it can be done without disrupting everything else, having a platform, having a way to make those experiments much more easily, it might be opening a Pandora's Box, who knows? I mean, you might have all sorts of competing things flying around. But I think that it would be a way to practically handle a lot of the discussions that go on in terms of modifying Python. Somebody says, "Oh, this would be a great idea." And somebody else says, "Oh, that would be a terrible idea." And neither side has any data to base that on other than a feeling or...

Luciano Ramalho: Totally.

Recommended talk: Artificial General Intelligence in 6 Minutes • Danny Lange • GOTO 2020

Naomi Ceder: So that's why I would support that. 

Luciano Ramalho: Just for the listeners who may have not seen this, not a feature that's very common in languages, Syntactic macros, but they would allow people to implement async/await in a library, the keywords, async/await, not the library, but actual keywords. And also, for instance, match, the whole match case statement that was introduced recently could have been just a library thing instead of a deep change in the interpreter, right? Well, Mark suggested that and then he went into this whole...he got interested in the performance problem, and so there's not been any evolution that I've seen from the PEPs, it was just posted, and there wasn't a whole lot of discussion.

Naomi Ceder: It's still draft status, I believe. 

Luciano Ramalho: All right. So now I think we can wrap it up. Thank you so much, Naomi Ceder.

Naomi Ceder: Thank you.

Luciano Ramalho: It's a pleasure. Naomi Ceder: Always a pleasure for us to have one of our talks.