The PEP Talk

Hello, and welcome to podcast.init,

the podcast about Python and the people who make it great. You can subscribe to our show on iTunes, Stitcher, TuneIn Radio, or add our RSS feed to your podcatcher of choice. You can can also follow us on Twitter or Google plus and please give us feedback.

You can leave us a review on iTunes so that other people can find the show, send us a tweet, send us an email, send us a message on Google Plus, or leave a comment on our show notes.

I would like to thank everyone who has donated to the show. Your contributions help us make the show sustainable.

For details on how to support the show, you can visit our site at pythonpodcast.com.

This episode is also sponsored by Zato.

Microservices,

ESB, SOA, REST, API, and cloud integrations in Python.

Visit zato. Io to learn more about how to integrate smarter in the modern world.

I would also like to thank Hired, a job marketplace for developers, for sponsoring this episode of of podcast.init.

Use the link, hired.com/podcastinit,

to double your signing bonus.

We'd also like to put out the call for any

Pythonistas out there who may have disabilities.

If you are blind, if you need some other kind of special adaptation to program in Python,

we would love to talk to you. We think that would be a really interesting window into

the

awesome diversity in the Python community. And so please get in touch with us at hosts@podcastinit.com.

Yeah. We would love to have a show so that other people can find out about your stories.

And we're recording today on December 7, 2015.

Your hosts, as usual, are Tobias Macy and Chris Patti. And today we are interviewing some of the editors of the PEP process. So, Barry, could you please introduce yourself?

K.

I'm Barry Warsaw. And,

I've been involved in Python for

a long time, over 20 years.

I currently work for Canonical,

and, they're the makers of Ubuntu Linux.

So I work on the Ubuntu

engineering,

team on the foundations team.

And, so I do a lot of,

foundational work, in Ubuntu and, in Debian on

trying to make the Python stack,

you know, keep it healthy and improving

as we go along.

So if there's a bug in Ubuntu or Debian with,

Python, then I'm probably the guy to blame.

And, Chris, could you introduce yourself?

Hi. Yeah. I'm Chris Angelico.

I'm the the newest pet editor.

I teach prep Python programming online,

so, I tend to see a lot of what people are doing in the real world with

new programmers.

And, for the rest, I basically nerd out about Alice in Wonderland and Frozen and stuff like that.

So, yeah, I love editing pets, because they've quit playing with words and text files in my life.

I live on GitHub,

pretty much.

Great. And what about you, David?

Hi. I'm David Goodcher.

I'm best known in the Python community as the creator of the DocuTails project, which includes Restructured Text.

I'm originally from Montreal, Canada, but I'm currently living in Minnesota

in the U. S. In a suburb of the Twin Cities

of Minneapolis and St. Paul. I work at Medtronic as a systems engineer.

I'm an avid cyclist and really enjoying the fabulous cycling around the Twin Cities, but I'm also mourning the,

the end of the cycling season, unfortunately.

So, how did you folks get introduced to Python?

So, let's see and

the interesting thing is in early 1994,

I saw complang Python, the news group, the Usenet news group actually get created. And, you know, I've always been interested in languages,

and technology. So I checked it out and,

I got bored pretty quickly because

there was very little language stuff and a lot of Monty Python jokes, which you know, I love Monty Python. I'm a huge fan,

but I didn't quite understand why there would be Monty Python skits and jokes in a comp lying news group.

So I sort of lost interest,

until

later in

1994,

I got hired by the Corporation For National Research Initiatives,

CNRI.

And,

we were doing a project called NoBots which is essentially software agents that,

are able to move around the the network to do various tasks or learn various things.

And we started looking at,

objective c on the old Next machines, if anybody remembers the old Next machines. They were Love those boxes. Yeah. Yeah. They're awesome.

And we we really liked Objective C. I've used Objective C years before that in a previous job.

And

so we were sort of going down this track and

some of my old colleagues at the National Institute of Standards and Technology,

NIST, it's a they're a

federal government research lab up in Gaithersburg, Maryland,

had sent me an email and saying, hey. We're get we're getting this guy over to the states to give a talk about this language called Python. And it sort of rejogged my memory about the this news group. So I thought, okay. Well, that's pretty cool. You know, I'll go see some of my old friends and and sit in on this workshop. And we did a little bit of research, and we saw that there was some really interesting objective c Python bridges that people were developing. So we thought, hey, at at the very least, we can kind of, pick Guido's brain and see what he thinks about this these objective c Python bridges. And

so the workshop,

if I remember correctly, it happened in, like,

November of 94,

and there's about 20 of us. My colleague at CNRI, Roger Massey, was there.

And some of the other, you know, a few other people that you probably recognize from the Python community. Jim Fulton was there. I think Skip Montanaro was there.

And we just we just

totally fell in love with

Python

at this workshop.

The 1 thing I remember

we

designed at the time were docstrings. I don't know if anybody remembers Python before docstrings, but

that was 1 of the features that I remember, having been developed at this workshop.

So it was about 3 days. We really enjoyed it. You know, Guido, of course, we we just, you know, really,

clicked with him.

And then,

he went back to the Netherlands and we went back to work. And sort of over the next couple of months, we

we sort of bandied about the idea of trying to actually hire Guido to see if he was interested in coming to the States and to work on

this objective c Python bridge in more detail.

So we kinda brought him over. We interviewed him. Bob Kahn who, you know, is an Internet luminary,

1 of the founding fathers of TCPIP.

He ran, he runs CNRI

and,

he really liked

Guido. And so,

Guido kind of was ready to come to the US at the time, and it just sort of all worked out. And I think he came over in April of 1995.

And,

we sort of, over the next 8 years, moved

all the Python infrastructure

to the US

mailing lists and,

we upgraded from CBS, I think, at the time to Subversion,

you know. So we just sort of pulled all the Python infrastructure, and I got really involved because Guido was, you know, in the queue next to me within throwing distance.

That's that's kind of how I got, involved in Python in the early days.

That's a very interesting story and a great peek at some of the early history of the language, so thank you for that.

Chris, how did you get introduced to it?

I first met Python Deck sometime in the nineties, late nineties,

on OS 2.

My dad knew about

a lot of things that were happening in computers, and he introduced me to this language. And I looked at it, and I thought, oh, okay. What does this give me that Rex doesn't already give me? And the answer was basically nothing at the time, because I didn't need any of its features.

So Python sort of got left behind, and I kept on doing things with the languages I already knew.

Then about,

2, 004, 2005,

I needed a scripting language to embed in

a project I was doing at work,

and I turned to Python.

And I spent a few months putting together the the necessary embedding work that we needed for this particular project.

And

then I said to the Python community

I came to the Python list and said, hey, we've done this and I'm not sure whether it's going to be enough or

not. Can people have a bit of a look at it and tell me whether they can

take control of the system by providing Python scripts?

And I think it took about 20 minutes before someone had completely taken control of that box.

Alright. What about you, David?

Okay. Well,

I guess it was in the late nineties. I was in I was living and working in Tokyo, Japan.

I was working at a small company and I I was using Pearl intensively,

for a couple of years, and that almost burned me out.

And then, I first learned about Python there, and I moved back to Canada in 98,

Picked up a book. I think it was the original,

Python book, from O'Reilly.

I taught myself the language and loved its expressiveness, you know, how it's

closest to executable pseudo code.

I learned about docstrings and searched for a tool to extract docstrings

a la literate programming and that eventually turned into restructured text and docu tools

which, Georg Brandl incorporated into the popular,

sphinx tool that uses it.

And along the way, I got involved

in the Python community and eventually ran a couple of, Python conferences, the 2 that happened in Chicago,

and, various other things like the like being a PEP editor.

Very interesting.

I thank you all for that. So for anybody who isn't familiar with them, can you explain what a PEP is and how they influence the Python language?

So a PEP is an PEP is an acronym for Python enhancement proposal.

And,

it's really the way that the Python language and more than the language, the community and the way Python is developed.

That's that is the central place where,

the where all these things evolve. So for example, when

new features are to be proposed for the language we,

we write a PEP which describes how this feature will work, what the

backwards compatibility

issues might be,

the design of

the of the feature, how it might interact with other features.

It'll have

a

discussion

about,

alternatives that maybe were discussed and rejected,

and it'll usually have links to,

implementation,

example implementations that people can play with before the, the, PEP is accepted. So it's really, you know, the the the main thing is for, language development for new features, but there are a few other types of PEPs involved, and I I guess we can talk about those later.

Yeah, I think 1 of the reasons for the beginning of the PEPs, I mean, Barry was there right at the beginning. I'm this is David speaking. I came in a little bit later,

but I think 1 of the the the reasons for it was to,

was to capture

requirements and capture ideas

so that people didn't have to keep on talking about them over and over and over again on the mailing list because that's what was happening. Right? I mean, somebody would introduce a feature and everyone would sort of back behind their own screens would groan and say, oh, not this again.

So PEPS came around to

write all that stuff down and say, hey, okay, you want to add that? Okay, go and write it. We'll add it to the repository. It'll be up on the web. And from now on, whenever anybody wants to,

propose it, we can just say, oh, yeah. That's that's pep number,

you know, you know,

that's pep number x.

Go see that. And they can either,

they can look at it and say, oh, it's already done. It's already been rejected,

or they could pick it up and run with it and maybe finally get it implemented. You know, some option.

But it it it would save people time and stop people from having to,

you know, reinvent the wheel every single time and redo the discussion every single time.

And as soon as anyone says

that this

is this is going to be a wonderful, wonderful thing, instead of having 50 people saying, but what about this, but what about this, but what about backward compatibility,

all those sections will be there in the PIP.

Yeah. I think we were really trying to solve a couple

of problems.

You know, email

is the primary way that people discuss,

new features for example.

And there's lots of mailing lists to do that on. But and mailing lists are great for those kinds of discussions, but they're really terrible for capturing what the current state of the design is. Because you have to go, you know, people reply and then and the subjects, you know, they

the the threads don't always match up and the subject headers sometimes ramble. And so, you know, it's really difficult to go through, you know,

an email thread that may have a 1, 000 or at least several 100 emails on it.

And figure out, okay, well, so what have we decided

right now? And that was especially true of Guido who was,

really being pulled in I think a lot of directions. And he had a really difficult time

sort of following the discussion. Okay. So we've just we've talked about this and we've talked about that, but what did we decide?

And so

the

PEPs, and I actually found the original email message where I announced the PEP process. It was in it was on July 13,

2000

to Python Dev.

And so what we tried to do is we said, okay, well we're gonna have a document with as little

formalism as we can get away with. So we really wanted it to be very, very lightweight, but we wanted it to capture the current state of the of the discussion

so that Guido wouldn't necessarily have to read every single email in the thread. He could go to the PEP and he could he could read the PEP and he could understand what the what the design

was,

proposing. And then he could,

give his feedback on that, give a thumbs up or a thumbs down once he was ready to pronounce on it.

So and then the other sort of

point was that we wanted to capture that in a document that was in a version control system so that we would have a historical record of,

of this of the evolution of that, language feature. And so that's really what the the PEP process was about. Now the the other interesting thing was that we

we were all working for CNRI at the time, and CNRI was running the IETF,

which is the sort of, you know, Internet standards body.

And so we looked at, the RFC process as

a model for how we wanted the PEPs to work,

but we wanted it to be

much more lightweight and and agile flexible

for

us. So,

the other the other thing is that, I tend to come up with these backgrounds. So I actually, like, like many other things, I came up with the word pep first and then

I retrofitted the

the acronym into it. But it seems to work. It caught it's caught on and,

interestingly enough, I've seen sort of the same idea

adopted in a lot of other communities like Debian has DEPS, you know, for Debian enhancement proposals.

Yeah. I remember the the first 1 I think I heard about was was GLPPS or something. I think it was, Gen 2 Linux.

I think that's right. Yeah. Yeah.

So so, Barry, would you say that we are the pep squad?

Yes.

We certainly are very peppy. Do you all have a bit of pep in your step?

Yes. Every step has pep.

And so taking that a little further, what are the requirements for a PEP to be considered for approval, and what does the overall process look like to get it finalized?

Well, I can take this 1, I guess.

So for it to be considered for approval for it to be considered at all, it has to basically

fit

the template and we've got 2 PEPs,

I think they're PEP 9 and 12 I think are the templates,

And,

so people can just take those and and

fill in the blanks basically.

And it's it's very simple, it just has to have

the some minimal requirements and you send it into

the PEP mailing mailing list,

peps@python.org,

and it comes to us. Oh, and by the way,

people, anybody listening to this, please don't try to subscribe to peps@python.org.

We'll just reject it. And I'm the 1 who always gets to do that. So please don't do that.

So you just send in the PEP and if it

fits, if it works, if it makes sense at all, we'll give it a PEP number and then the real work begins. Then you've got to convince the community

if you haven't already been trying. You put it up on the mailing list and you try to convince everybody

and try to build consensus

and once consensus is built

then you've got to get approval and ultimate approval comes from Guido

or he might designate

a

deputy

for

some section for for you know PEP by PEP or area by area of the language.

And there's a lot of details

and they're all spelled out in PEP number 1.

You can go go from there.

And is there any sort of time limit or a lifetime on a PEP once it gets submitted before it can be finalized?

Is there some sort of minimum time frame for comments or any maximum lifetime within which a PEP can be approved?

No. Not really. They I'm sure there are PEPs that are out there that that are still, you know, awaiting

final decision that are

years, if not decade old. And there are some that go through, you know, right away. It depends on what kind of momentum you have behind it. Mhmm. So that's 1 part of the RFC process that you decided not to,

emulate.

That's right. That's right. And actually, subpeps, you know, they kinda languish for a very long time, you know. It's, it's a bit of a gauntlet to get your pep approved.

So it's definitely not for the

faint of heart.

The Python community can be, you know, I wouldn't I I would say they they they really care

deeply about,

you know,

new features. So,

you know, some some things just aren't the time isn't right, and they'll just sit around until,

you know, somebody else gets really fired up about it and will bring it out of retirement or,

whatever and,

and resurrect it and have maybe even, you know, sort of a new perspective on on a particular feature. And that might be just what it needs to make it over the home.

Well, how long did matrix multiplication

hang around before it finally got for implemented?

The the idea is a new at operator.

That's been around for a good while.

Yeah. Yeah. That that's a lot that's an old 1.

Well, some PEPs need a a champion, right, who had to to

push it through

and other PEPS just need the momentum to build the the community.

It needs, like, the collective mind of the community be to be changed and

and and directed in the right direction. That sometimes it takes time. Sometimes it happens very quickly.

That's really interesting,

specifically, with regard to, you know, some PEPs tend to hang around for a while and and some PEPs kinda go go through more quickly.

When you said that I thought about a number of years ago when I was more in tune with the Java community,

how they said there was a really serious problem with the the Java community equivalent of a PEP, the JSR, or at least that used to be the case. I'm not sure what they use these days.

They were they had a real problem with, you know, significant numbers of JSR is going essentially moribund

and just kind of hanging around forever,

years years,

never making progress, never and and, like, a really significant number of them, not like a mix. It was like, you know, for a long time, people sort of started

kind of, you know, sniggering at the JSR process behind its back, you know, saying that nothing ever happened there. So it's interesting that

this model really seems to be working in the in the Python community.

Well, it it's definitely,

evolved

over the years. I mean, some of the early PEPs that we sort of added to the, you know, assigned numbers and added them to the BCS

were very

sort of hand wavy

and not really complete. And I think we learned pretty quickly that, you know, a PEP has to be,

you know,

to be submitted, it has to be pretty solid to start with. But 1 of the things that we've done

since then, and and certainly, the other guys can can talk about this as well,

we won't just sort of

accept PEPs out of the blue.

I mean, I think that that doesn't quite work as well. So,

a few years ago, there was a new mailing list called Python ideas. Right? So we have Python dev, which is where sort of the

focus of Python development occurs. But Python

ideas is is the crazy,

you know, pie in the sky sort of, you know, hey, wouldn't it be cool if we added, braces and semicolons, you know?

Kinda kind of change.

And

so,

if so we we typically, I think,

encourage people to go to Python ideas

and flesh out these ideas. And if it sort of makes it through that

process favorably,

then people will be encouraged

to take that idea really, you know,

codify it into a PEP and and submit it as a as a PEP.

And that's helped a lot, I think.

You're essentially dovetailing into what my next question was gonna be. So I'll just throw it out there and we can continue this discussion. How has the pet process evolved to meet challenges posed by changes in the Python community? And it sounds like this is the perfect sort of lead in to what you guys were saying. Go ahead, Tobias.

I was just gonna say that,

this whole process of PEPs and also seeing which ones get accepted or

rejected or

sit nascent for a long time would be an interesting area of anthropological

research to see sort of

what overall trends are happening in the language community and the broader programming community as a whole, just to sort of mine that information, both for PEPs and also possibly other

analogous processes in other communities.

Well, the cool thing about that is that the just about the entire debate

is recorded in the mailing lists

and in in the version control, isn't it? So there's a there's a case for an anthropologist in the future to come back

and base her dissertation on the PEP process, and

everything is there.

What else do you want?

I think the other the other,

change that happened,

I don't know how long ago, that I think helped out a lot,

because I got I got personally kind of burned out on being a PEP editor at some time. And fortunately, we had, you know, great people like Chris and me and David to to really take over.

But once

the we sort of opened up the repository, the version control repository,

to a wider audience, you know, now I mean, it used to be that all the PEP numbers had to go through an editor to be assigned. And I think it's pretty much the case that if you're a core developer, you already have commit access.

You can pretty much self assign

a PEP,

just pull the next PEP number and just self assign it and and check it in without That's right. That that's a decision we made some years ago because there was just too much noise going on. Too many too many people that we already trusted. I mean, the trust

they were already vetted by getting,

the commit bit for the for the our version control system for the the the core code. And if they were

okay to write there, then no problem writing to the repository. So, yeah, just go and get the next

number and do it yourself.

Yeah.

And I don't think I mean, I can't remember an instance where I I remember 1 or 2 cases where we might have had to reassign a number just because

either we were reserving that number for some

silly reason or

or there might have been a collision or something like that. But it's very rare that I think we have to go going and and

make a change to something that someone has committed for themselves.

And that, raises a question for me anyway.

Just curious what sort of tooling you have in place in the PEP repository

for assigning those numbers or if it's just a text document that happens to hold the the last assigned number or, what sort of processes you might have in place for that? No. We just look at the we just look do a file listing.

We just update our low our local copy and do a listing and say, oh, well, the last number is x, so you get x plus 1. That's it.

And then the index is automatically built. I wouldn't wanna build that manually.

Yeah. That's right. That's right. That's a that's a great help. Yeah. And we started out, you know, writing pep 0

manually, and that clearly didn't

scale.

So I don't remember who wrote the script to, to generate cut 0, but,

I don't know. Do you work do either of you remember?

Right? I'm sure we can find out. I think

it was,

what's his name? I don't know.

Sorry. It's like slash f or some f.

Oh, was it, Frederick Lund?

Yes. Yes. He wrote f bot. Yeah. F bot. That's right. The f bot. He wrote it, and originally, it was a script that would

just turn the

the old style, the the original style PEPs, which were just plain text documents.

It would just

locate, I think, the

section headers and turn those into like h 2

HTML H twos or something. The rest of them were just literal blocks of, you know, pre blocks in HTML.

And it would and it would extract the PEP number and the title and the authors

and make the list out of that.

I eventually

took that script and modified it to

to process the the restructure text PEPs as well.

But,

you know,

the initial work was done by the FBOT. That's right.

Yeah. I think that was a but by the way, I have to say that,

adding the rest format was really awesome. I mean, that was something that you did, David, and I think that really

helped a lot. So,

well, it made them much more expressive. And finally, you could do things like add diagrams

and

and and that type of thing.

It it chain changed it from basically typewriter to

HTML. Right?

Yeah.

Not that diagrams are particularly common. Of recent PIPs, I can think of exactly 1 that actually has them,

which is the

the whole thing on daylight saving time and all the misses that that entails.

So how many reviewers are there, and how did each of you end up in that role? And, also, is there a set number of editors that must be maintained? And if that is the case, how did you arrive at that number?

No. There's no set number. I think there's probably about 9 of us on the mailing list and

maybe half of those are active. I'm not very active myself. All I do

personally is is,

handle moderation on the mailing list itself. That's pretty much all I'm doing,

and I think

the the number of PEP editors we need

is

at least 1 active.

Yes. I think that's what I mean. As long as we have 1 active PEP editor, then we're good.

And if we don't, then eventually

somebody will notice and say, hey. We need a new PEP editor, and and then we'll

we'll drag in a new, Vic no. Sorry. Editor.

Which is how I got involved. Yeah.

You you you were press gamed into it?

Yes. Yes. Guido says, hey, we need more pet services.

And I go, oh, well, maybe I could. He goes, yep. Yep. Right. You're in. Done. Grab.

I saw you raise your hand.

So what mistakes have other communities made when creating similar processes, and how has PEP learned from those mistakes? So the reason I asked that is because of of exactly I I already kind of referred to this earlier, the horribly broken JSR process of a number of years ago. I don't know I didn't know if you folks had seen some of those missteps and said, well, we're not gonna do that, but it sounds like you kind of, you know, it was a case of simultaneous evolution. You guys come up with your

own ways of handling things that have been obviously been quite quite functional and successful. So that's good news in and of itself.

I think it's I think it's the case of the classic lazy

programmers. Right? You do the the minimum

possible that will pass that can work, and that's basically what it is. It's a little bit more than the minimum, but but not a whole heck of a lot more.

I think you're right. Absolutely. I mean, it's and any changes that we've made, because if you look at, like, PEP 1, you'll see that there's been a few steps and some, you know, over the years added as some headers added and a few things like that. And that's really all just organically

done. I mean, you know, once we I think someone will say, you know, well, the PEP process doesn't handle

informational PEPs or process PEPs. So let's add let's allow for a new PEP type that will be

that will describe the process for releases or something like that. So

it's it's very organic, and I I think we've settled in a in a really nice place where we get done what we need to get done without really a lot of overhead and and,

you know, and burden. So

Yeah. Indeed. I mean, the the PEP started out we started out with 2 types. Right? Standards track PEPs. That those are the real meat of the that's most of the PEPs. Those are the ones that describe a new feature

or implementation,

some standard that we're gonna implement probably.

And then, of course, being programmers, we had to add a level of of indirection on top of that. So we have to have PEPs that talk about PEPs, and those are the informational PEPs. So like PEP PEP 1, which describes the process, and PEP 0,

which is just the list of PEPs. And then

later on, it was a few years later that we discovered that that we needed a third type of PEP which was the process PEP. So those are the,

those are the documents that describe

the processes

surrounding Python,

or, you know, they proposed changes to the process. And those didn't really fit as informational

PEPs. They were,

like, actionable.

They weren't just information to read and and and and acknowledge, they were actionable. But they weren't gonna be implemented in the language, they were gonna be implemented

in the community.

So those are the 3 types we have now, and I think that those pretty much handle everything. I haven't heard of any that any anybody who's asked for something that doesn't fit into 1 of those 3 categories.

And have you considered renaming the informational PEPs to be MetaPEPs?

No. But I think they are under the MetaPEP heading in PEP 0. So the PEP 0 you'll see is organized sort of

by

PEP types, I think, and then but and then there's another section that just numeric listen numerically.

So we have a little bit of organization around the numbers,

and I think you're you may ask about that later on. We could talk about that. Yes. That that's actually the next question, so feel free.

Well, there you go.

So I know that we

I remember that we had talked about trying to keep like

the meta peps in the lower numbers.

And the other interesting thing I I did not remember until I went and looked at that first announcement email was that the first

handful of peps

were

pep

20201,

202, and 203.

And PEP 200

is the 1 that described the Python 2.0

release schedule,

which Jeremy Hilton, who who was a Python Labs guy,

owned because he was I I believe he was the release manager for Python 2.0.

So

we sort

of kind of established

that PEPs and, you know, those early PEPs were, you know, features around 2.0,

Python 2,

And, when we were when Python 3 was sort of a dream, I think, in Guido's

mind or maybe a nightmare. I don't know.

You know, we we said, okay. We're gonna throw all these because the the joke was sort of Python 3 k or Python 3, 000, which is like, it's a it's a dream. It's way off in the future,

you know, and we were still working on Python too. So we said, okay. Well, all the peps that are gonna describe new features or changes for Python 3, we're gonna go in the 3 1, 000. So if you see if you notice, you'll see

a bunch of peps in the 3 thousands, and those were the early Python 3 peps. And then once Python 3 became a reality,

we just folded all the new stuff back into the normal numeric,

sequence.

Yep. That's right.

So, you know, we did we played some some games

here and there.

That's about it.

And there's a couple, I think,

that fall outside that, you know Yeah. A couple.

Now, like, there's there's PEP 401, for example,

which where where the numbers had a small significance.

There are a few jokes in there. Yeah. There's a few jokes in there. Few jokes in there. Yeah.

I just realized that the pep, 160 is the Python 1.6 release schedule

as as well. So

I think it was the idea to to sort of match. So 160 would be 1.6,

200 would be 2.0.

But by the time you got to like 2.1,

you're already way past PEP 210

in terms of of standard tracks. So we we couldn't keep on doing that.

So,

that sort of went out the window.

But but then for for Python,

3, which was Py 3 k, so we went, oh, let's just go to 3, 000, that'll be fine.

And that that that was way off in the distance. So there's a huge jump between, I think, the the highest,

is probably in the 4 or 5 100 right now, and then then the next 1 is in 3, 000.

How does the PEP process maintain its sense of humor, for example, PEP 20, while being sure to be taken seriously where it really counts?

Well, you know, look, the language is named after a British comedy truth. So, you know, there's gotta be some humor in there somewhere. I

mean, I I remember in the early days, I I had gotten this really awesome

2 volume set of the,

I think it's called Monty Python all the scripts or something like that. It's it's Only the words.

Only the words. Only the words. Yeah. It's great. And I have a copy of it myself. It's a back to back paperback. You have to turn it, flip it over, and it's got, like, the half of it in in 1 direction and half it's got 2 front covers.

And

and, yeah, I have a copy of that

on my shelf,

or I used to have it, you know, on my shelf above the computer, and I would pull it down anytime I needed

variable names

or

example names or anything like that. So rather than Foo and Bar,

you know, you'd get, you'd get spam and ham and and eggs and bacon or something like that. Albatross.

Yeah. Albatross.

Exactly. When we were when we had

name machines, you know, you you always come up with these naming themes, and that's what we did. We just cracked the book open and we would see Albatross

and Jimenez and,

Biggles and you know? So we would we'd mine those scripts for,

the the original

Python package index,

and some of us still hold dear to this name, is called the cheese shop. That's right. Because,

you know, it has no cheese. Yes. Has no cheese.

So so perfect name. So You you know what was a really discouraging

moment for me

was when I was

organizing,

the PyCon

and

I and I asked

the

assembled, I don't know, a 1000 Pythonistas

there,

How many of them understood

the Monty Python jokes that we were talking about? And fewer than half, maybe like only 20% put up their hands. It's like, come on, guys. You gotta know this stuff. This is integral to the to the culture and the community.

But fewer and fewer people know about it now.

The good news though is today, they've released it all on YouTube free and clear. So

or at least a significant chunk of it. So the bottom line is now you can say, here, have YouTube links. Go watch this. It's required education.

Oh, you should absolutely watch every single episode and movie because they're all brilliant.

Yep. Yes. I I have the, the box set and a couple of the movies. I don't yet own all of the movies, but I intend to remedy that. So I think I think humor is not the problem. I mean,

sometimes I feel like, you know, we've gotten a little humor challenged.

And I suppose you have to be kinda careful these days about, you know,

the jokes that you make. But,

you know, I mean,

you have to you have to I think you have to have a lightness about

all this stuff because if you don't, you can easily get bogged down. I mean, everybody's been involved in, you know, flame wars and and and massive threads that get you know? And I think a lot of that is because people sincerely

care about

these

systems that they're building. I mean, people people are passionate about Python.

You know? We we all love it very much.

And, so you can get serious, but gotta keep that lightness. Otherwise, it just gets it gets overwhelming, you know? So.

Definitely.

So along the lines of humorous peps, can you share the story of PEP 401, which you have alluded to previously?

I guess I should take this 1.

Yes. Yes. You should. Okay. So here's the story for PEP 401. So,

it turns out, I think in 2009, I don't remember where the Python conference was in 2009.

Maybe 1 of you remember, but 2009 was Chicago. Chicago. Okay. So you probably were the

the,

the organizer for that. That that's right. So I remember,

that

we realized that April 1st was gonna fall within the in the sprints, I think.

Yep. So

I figured, okay, April 1st, right, at least the way that we write the date in the US is 0401.

So I had reserved 401, and I was gonna write

a humorous pep.

And

we weren't we had actually talked about it for several years.

A few of us, Guido and, Brett Cannon and myself had been talking about doing a humorous pep, but April 1st never really fell within the Python conference. So, anyway, in 2009, it did. We said, well, we gotta do it this year.

So,

I think 2 days before or maybe the day before, I stayed up all night and wrote this pep.

But,

I had come up with another backronym which I just was, like, throwing ideas around and I came up with this funny word called the fluffle. I just thought it was it sounded funny. And then

I backronymed

the

friendly language uncle for life. And the thing is, I wrote the PEP,

for Tim Peters,

okay?

Because Tim, we I don't know how many I hope a lot of people,

you know, know Tim. Tim was

a very early adopter of Python. I mean, even before I even before me, he was probably involved from, like, day 1

or very, very soon after Guido originally released Python. And then he kind of fell off for a while,

and then when we split off Python Labs,

he came and joined us. So he was a colleague of ours for many years. And I think he's kind of

he he crops up every now and then in some of the discussions. But, anyway, Tim

is a great guy,

very, very smart,

really understands. He channels Guido very well.

And so he was

this real figure in the Python community.

And so,

but everybody called him uncle Tim for who knows what reason. We just, you know, he's just a lovable, huggable guy, Right? Oh, he's he's

our curmudgeonly

uncle. Right? Yes.

Exactly. So I wrote the pep

with

Tim as the fluffle,

and I sent it off to Guido and Brett, and I said, you know, it was probably like 4 in the morning, it took me a while. And I and I said, well, what do you think? Is this completely stupid or is it funny? You know, is it appropriate? I heard nothing

back. So, like, all the next day, nothing. And I started getting a little bit a little pissed, like, you know, hey, I worked on this thing and I think it's I think we should go for it. And, you know, they were like,

nothing.

So,

then on April 1st,

they released it, but they had

just like in the Monty Python script, they had scratched out Tim Peters' name and wrote my name in

instead.

They scratched out Tim Peters and wrote Barry Warsaw in crayon.

Exactly.

Exactly. So

and I didn't know it's people like started coming up to me at the conference and calling me the fluff 1. I was like, oh, no. You didn't. You didn't do it.

So

that's a story. It became a it became a meta prank, didn't it? They turned it around and and aimed it right back at the prankster.

And the prank lives on in Python 3. So for anybody who isn't aware, if you import

if you do from future import berry as fluffle, you get the diamond operator back.

That's right. That's right. Because see, I I had the happiest arguments with Guido, not

arguments but discussions. I really wanted him. I mean, I understood why in Python 3 that we were gonna get rid of the the 2,

inequality

operators, but I like the I like the

diamond operator. So I was like, wait a minute, you should really just go for it. And so then when he chose the, you know, the not equal or the bang equal, I was like, ah, well, that just destroys Python. Everything's, you know,

everything's over now. It's a terrible language.

And so I incorporated that into the PEP. I was like, well, Tim's gonna take over and, you know, and and and fix that. And then

so I think

and I don't think it was for them, but they actually it was I I thought it was hilarious that, you know, not only is it in the pep, but it's actually in

in the future module.

So you can actually say, I want

the the diamond operator and and use it.

It's not just in the future module.

It's built into the language interpreter, isn't it?

It is. It's I mean, the future module is just a thin layer on top of,

you know, it's just it's just a way to get something out of the the the language itself.

Yeah. I think it actually changes the the parser.

Yeah. Yeah. Yeah. Yeah.

And as we found out recently,

this makes a great test for programs that are used for future import

because suddenly they want to import everything

except various fluffles.

We had this discussion on which was, whether I can't remember,

I think it might be Python. Maybe Python dev. Yeah. Python dev, I think. Mhmm. So that's

there's your there's your PEP 401 story. Alright. Well, thank you very much for that. Indeed. Yeah. And there are a couple of other interesting PEPs. Like, there's PEP 6 66, for example.

There's a few in there.

Yep. 404, I think, is a is 1 of my favorites.

PEP not

found? Yeah. It's it's,

that's the,

the unreleased schedule. Yes. The Python 2.8 unreleased schedule.

That's great.

So how does the PEP process strive to prevent an undesirable level of control

by any 1 company or other special interest group?

Anyone can ride a PEP? Yeah. Anyone can ride a PEP, and it has to be

agreed to by the community and ultimately

Guido or his deputate.

So

anybody can write 1, but,

good luck getting it passed if we don't like it.

It's really interesting, and that dovetails into the next question. But I I just wanna say, your responses to all of these kinds of questions are just

are are

brilliant. They they are a prime example of

why sort of Python is the kind of community that it is. And it's sort of like, you know, well, we don't have to do any of that stuff because it all just sort of works. Everyone just sort of plays nice, and there's no there's no issues. I mean, there there have been you know, speaking in terms of other language communities, there have been instances where there are these bitter turf wars between these major companies that wanna influence a language in 1 way or another,

And it's just it's wonderful that,

in in Python's case, these things just don't happen for for all the reasons you mentioned.

So I have 1 other interesting story about that. You know, at the first Python

workshop that I mentioned earlier,

we had 20 people there, and we had

a few

who we were not allowed at the time to advertise that they were at the workshop because

they were using Python as an integral part of their business, but it was their secret weapon.

So they didn't want their competitors to know that they were using Python. Right. If their competitors found out about it, then Then then exactly. So it's always been I'm

driven.

So kinda dovetailing what you just said, how much control does Guido have over the PEP process?

And has a PEP ever countered Guido's wishes? How did it turn out?

It got rejected. I think I've I've seen quite a few of those, actually.

Well, I I wrote pep463

about exception catching expressions,

and he said in 1 of his talks somewhere, yeah, this this is not the sort of thing that the passing

language needs. So, yeah, the PEP is not getting approved. It's that simple.

Yeah. Yeah. That that's part of it. I I think

the the maybe the meta answer to your question is Guido has as much control as Guido wants to have,

and he divests himself of as much

as he possibly can.

There's there's certainly,

lots of peps that

are

covering areas that he really doesn't care about, you know. And he I I would say he he doesn't care, but he also has a trust that

the people who do care about that in the community will eventually do the right thing. And so he'll just say,

you know, I'll I'll, you know, let you guys handle it or let let you folks handle it. And, you know, you'll find the right pep czar, the pep the, delegate. And, you know, we usually, I think, try to get Quito to at least not

disapprove of the

of the delegate.

But, you know, if he if he cares

enough about a particular thing, he's gonna chime in

and have a say. And,

you know, I I think 1 thing that's actually pretty good is that

for the most part, if Guido says this is not a feature for Python,

that is enough to shut down the discussion, which,

is really important to also not

continue

to discuss things that really aren't gonna have, any chance of being added to

Python.

Right. Yeah. It's really interesting. You know, I was just thinking as you guys were talking about another

kind of example in the same vein in terms of in the Ruby community, you know, Matts is kind of the

I I don't wanna say equivalent because they're 2 very different languages and 2 very different communities, but he's sort of the benevolent, you know, dictator for life, although no 1 has has explicitly

elected him, but,

as the Python community, as Guido.

But he he basically runs the the, you know, CRuby,

team,

and that defines the behavior of the language. And there's been actually,

you know, a fair bit of frustration

because you have these

sort of alternative implementations of Ruby, and they're just trying to sort of make sense of how Ruby should work.

And there's, you know, been quite a lot of back and forth around, you know, what are the behaviors of the language, how will they change, what you know, It just feels

like Guido,

as part of, you know, the benevolent aspect of his role,

has done a really good job in the sort of you know, yes, he the the buck stops there. He is the ultimate decider,

but he also makes it really easy, it seems to me, for people to work with him

and

to have, you know, alternate Python implementations

that

behave well and and are relatively compatible.

I just think it's a a really you know, he deserves major props for

being able to guide this community in a relatively harmonious way,

you know, without having seeing that kind of strain.

Yeah. You know,

so just 2 thoughts

on that. I mean, Guido, you

know, Guido has an amazing

language design sense. I mean, you know, I think he'd admit that, you know, he doesn't always get it right, you know. And I think Python 3 was an attempt to sort of rectify some of the biggest warts.

But

he gets things

right

a lot of the time, most of the time. And I think that that's really garnered

respect of the community because, you know, honestly, you know, if I think if people didn't respect Guido, you know, Python

wouldn't be the language that it is today and the community wouldn't be the community that it is today. It would it would have fractured long ago.

So, you know,

I think that every the people who come into Python and really like Python

are seeing

Guido's,

you know, the the manifestation of Guido's language design sense. And for the most part,

it's been it's been really, really good,

and everybody just gets behind it. So it's not so much a matter of voting for Guido or not voting for Guido. It's just that, you know, he's it's

it's his vision, and we all we all like it enough that

it just makes sense for him to

be the person that continues to do that.

Yeah. It makes sense. It makes perfect sense.

And it's it's a design

issue, and we all know that design by committee doesn't work. I mean, you can you can have proposals by committee,

you can have implementations

by committee, whatever. You can hash things out by committee, But it So he dropped off again. Yep. But you can't really even have a proposal by committee.

Even a proposal needs its 1 champion, ultimately. Yeah. Yes.

If I if I might add 1 other thought, because what you mentioned about Ruby and the,

the alternative implementations.

So the interesting thing was that,

you know,

many, many years ago, Jim Huguenen,

I don't remember exactly where he was at the time, but he was a researcher

who was involved

in the Java language. And

he started a discussion,

and I don't remember exactly where. It might have been on the mailing list or it might have been a private,

email

about this idea that he had to build an implementation of Python on the JVM.

And my recollection, which could of course be completely faulty, but was that Guido said not only don't do it, but it's impossible.

You can't do it.

It can't be done.

And if anybody knows Jim Huguenen, you know, that's

a challenge, right? He's like,

nope, Okay.

Them fighting words. Them fighting words. Exactly. So,

Jim did it. You know, I mean, he

he implemented,

Python on the JVM and that's why we have, you know, at the time it was J Python and turned out to be Jython later on.

But 1 of the things that that forced Guido to do and I think it was really

critically important for Python's

success was to

come to grips with this idea of what

parts of Python

are implementation

details for any specific,

you know, language implementation and which are the definition of the language, which, you know, what things can you have or not have and still call it Python?

And you know, Jim I remember, because eventually Cinar I hired Jim and,

I remember I remember, you know, discussions about, you know,

these corner cases of the implementation of the CPython implementation. Like for example, how

under under Dells might get called when an object goes, you know, what is the lifetime of an object? Can you define,

you know, because CPython, of course, has a reference counting implementation, whereas the JVM is built on top of the garbage collector,

the JVM garbage collector. So

what

parts of that

lifetime of an object is part of the Python language definition and what are implementation

details

that the implementations can take care of, you know, can do whatever they whatever makes sense for them. And

and a lot of those discussions,

you see them in Iron Python and you see them, you know, in Pypy. You know, those are things where, you know, it has to have this to be called Python. And maybe they're, you know, version or 2 behind and maybe they're, you know, CPython tends to be the 1 that is the trailblazer, but, you know, eventually,

they all have these features and these semantics. Otherwise, they aren't Python. You you can't call them Python. And that was something that really important that I think Guido realized

and embraced.

And he, you know, he was sort of forced into that position of trying to define what's implementation and what's language definition.

Well and and moreover, as you say, he was actually willing to do the work. I think that's a really key distinction because that is exactly some of the frustrations that we're seeing play out or, actually, they've kinda died down now because the alternate implementations kinda just gave up. But,

1 guy in particular, the maintainer of Rubinius, I forget his name,

you know, really had this huge effort saying, let's let's create a specification for the Ruby language. Let's create a test suite so that all the alternate, you know,

implementations

can conform to the spec and play nice.

And the, you know, prevailing opinion on the Ruby core team is basically we don't wanna be tied down that way.

We our implementation defines

the behavior of the language and and kinda that's it. And

and I think it it really hurt Ruby. I think I think that these alternate, you know, implementations still exist, but they kind of

a number of them basically said, well, we're just not gonna work quite as hard to be

compatible with the main line. And I think I think that has hurt

adoption of those alternate implementations.

I think you say the same thing in the Pearl community,

you know. The

the implementation of

of Perl is the definition of the language.

We're and I think you're right. I think in Python, you know, there's lots of people who use

Jython,

you know, and

there's lots of people who use PyPy and Iron Python. And a lot of the code that you can just go out and get from the package index or a lot of the applications

that run on CPython

with,

you know, here and there changes, they'll run on those on those,

alternative implementations. And I think that really has helped Python get into

areas that it wouldn't have gotten into

had that not been the case.

Yeah. It's it's like the

it's like what was always said about Java. Right? Write once, run anywhere.

It never seemed to work there, but it works in Python, doesn't it?

It does. It does.

So

redirecting the conversation a bit, I suppose. Thank you all for that great conversation about Python and its implementations and histories.

So what is your favorite PEP and why? We'll go in the order we went before. So Barry why don't you take it first? Uh-huh.

Well, I think I think my favorite PEP is PEP 20. I mean,

you got to go for that 1, right?

That's the 1,

that

Tim,

once again, you know, Tim Peters

channeled Guido so well

and codified that and it just, it was just the kind of thing where he wrote it and everybody was like, Yeah.

You know,

someday,

maybe I'll tell you about the funny story about import this and PEP 20. But,

anyway, I really like 20 quite a bit.

Well, I do know that the import this module is actually if you go and look at the source, the text is actually wrote 13 and quote coded, and there's a wrote 13 decoder built into the interpreter to be able to print import this.

So Yeah. Yeah.

And the Python div do not want anybody tampering with that, no matter how many neat features you might want to add to it. I know, but go after that 1.

Well, it's actually PEP 20 because if I remember correctly, there's actually 19,

zen.

Zen cones and aphorisms. Yeah. Exactly.

And but Tim, I think in his original

email, said that there's sort of this

slot for the 20th 1, but it's undefined, and it will always remain undefined. So that's why it became PEP 20. It's it's it's left for future expansion.

I got if if I if I'm if you might indulge me for just a minute, I'll tell you about, import this. Absolutely.

Please do. Please do.

I again, I don't remember which

workshop. I I tend to think it was 1 of the,

before they were before they were called PyCons.

But we were looking for a slogan,

it's a slogan for the

t shirt.

And

so this was when we were Python Labs. So we're a small group,

5 of us, 5 of us, I think. And so we put out a call and we said, hey, If you have an idea for, you know, a slogan,

send it to us, and then we'll, you know, go through them and and and pick the pick the 1 we like and then maybe have a vote on it or something like that. And so we really didn't think we were gonna get that many. And we got

100

and 100

of submissions, and most of them

were really bad,

really bad.

So,

as sort of a team,

I think I'm sure Guido probably checked out like right away. He was like, I want nothing to do with this, you know,

And, eventually, it kinda fell to Tim and myself to call through all these

all these

submissions to try to pick the 1 that we we we were gonna go with. And Tim, of course, had the brilliant idea that we were just gonna do

a bisection.

So

Tim would take the list and he cut out half of them and send the list to me, and I cut out half of the remaining. And figuring if we did that enough, we'd end up with the 1 that won.

So we went through this process

and,

we ended up with 1 we ended up with a cup 1 that said something like, let's we study

Python programming. It didn't make any sense.

It was, you know, submitted

probably by a non English speaker, but we just really enjoyed it. It was just so enthusiastic and funny. So. Was that in the days of Can I Has Cheeseburger maybe?

No, I think it was before that actually.

And 1 of the ones that didn't make the cut was import this,

for whatever reason, it just, it didn't, and we ended up with 1 which wasn't either 1 of those 2

that once we finished the bisection, we just didn't like. It just we just didn't wasn't very good.

So Tim and I went through a couple of those last few and we just we we latched on to import this and we said,

that's great. You know, I think at the time, Michael Jackson, you know, we just had these images of Michael Jackson, you know,

dancing and grabbing his crotch and saying import this, you know.

So whatever it was, it was really funny and we liked it. And we thought what we can do

is we can actually make it a module.

And

if I remember correctly it was like right before

Python

21 or 22

was released,

and so what we did is

we

turned off

the version control system notifications,

and

wrote the ROT 13,

and

checked this thing in as an Easter egg. Import this as an Easter egg. And then we released Python with this Easter egg in it that nobody knew about. And so we figured, man, somebody's gonna find it. Right? You know, because we actually had published PEP 20, and we had this import fist that nobody really knew about,

and

nobody found it. And we we actually I think we we went to the whatever workshop or PyCon it was at the time, and nobody said anything. So, clearly, our Easter Easter egg

worked. And so we actually had to go back and tell people that, you know, there's this Easter egg in Python,

and and if you import it, it prints up PEP 20.

So

that, you know, it was just, like, 1 of those crazy things that, that, you know, happen if you're locked in a room together.

And and there have been some other Easter eggs that have made it in since then. The the the 1 that I'm thinking of right now is the import anti gravity from the xkcd comic.

Yes. Yes. Yeah. And import anti gravity

refers to import this, doesn't it? I think it does, doesn't it?

Maybe I'm mistaken.

I know there are 2 xkcd references.

There is another 1. There's 1 somewhere about geolocation.

Oh, there there's more than 2 xkcd references to Python.

No. Xkcd references in Python. Oh, in Python. Oh, no. No. I see. The anti gravity module has a geohash

function.

That's where the other 1 is. Uh-huh. Okay. Yeah. If you import antigravity,

it

it pops up the k xkcd

that,

in your browser that, talks about Python and Yes.

Yeah. I was in I was running the the I was the the conference chair

when that came out. And we were we were, like, you know, the the biggest decision of any conference is what do you put on the t shirt. Right?

And

so we were debating what we're gonna put on the T shirt. I can't remember if it was 2, 008 or 2009. It was 1 of the 2. And then,

Randall Munroe published x this x kcd number, what is it, 357?

And

and within seconds,

you know, I got it on my feed. I read it. I thought, oh, this is it. And then within seconds, my email started going out. Bing, bing, bing, bing. Have you seen next? Have you seen next? We've got to get it. We've got to get it. And somebody was able to to contact Randall Munro

and we got an original pristine copy. He draws them out on paper and scans them in at high resolution.

And I spent several hours

removing all of the little noise bits

from the original high resolution copy,

so that, we could print a really nice copy on the back of the t shirt.

Wow. Awesome. That's amazing.

Alright. Chris, what is your favorite PIP?

PIP 479,

definitely,

because Guido asked me to co author that with him,

and

I got to basically work

closely with

1 of the greatest people in the community

on this proposal

to

deal with a recognized problem.

And it was after that that I was invited to become a pet well, not physically invited, but

it was opened up, we need more pet editors and I put my hand up and Gwidow said, yeah, I was hoping you'd volunteer.

So it was pretty much invited to become a pet vendor, sir.

And and pet 479

is?

It's changing the handling of stop iteration inside generators.

So, if a generator would leak a stop iteration exception,

it becomes a runtime error instead.

Yep. I remember that 1. I think I probably had to fix something in in, Debian that,

might have had a some package. I don't even remember which 1.

And, that's Well, until your shipping price in the 3 point, there's it, and it's not necessary.

Right.

Alright. David, what's your favorite PEP?

Well, I guess I could say that it's PEP 257

docstring conventions, which is where I've got,

co authorship with Guido. And basically, all I did is

rip the doctrine convention

section of an essay that he'd written and made it into a PEP. But I've got to go with PEP 20 also. The Zen of Python,

that's the best thing out there. That's something that, you know, what other programming language has

it the philosophy

of the design of the language

built into the language

as an Easter egg. That's just it's just genius.

And

something that's bothered me for a long time,

and I've actually done some talks at local user groups about this,

is

that people misconstrue what the Zen of Python is all about. It's not the Zen, it's not the rules, it's not the Zen of writing code in Python.

It is

the

philosophy behind the design

of Python.

It's a very subtle but important distinction.

That's an excellent. And,

and and I've had confirmation of that right from the horse's mouth. I wrote to to Tim, and he replied,

which is getting rarer and rarer, I think, these days. But,

it's true. So it's the zen of

Python, the design of of Python, the language, and not not how you're supposed to write

code in Python because, come on, how many of our programs have

namespaces

implemented

in the program itself apart from the ones that we inherit from Python. You know? Mhmm. Mhmm. So Yeah. And and it's often misquoted. I I can't even count the number of times I've heard people say, you know, refer to Python and saying, oh, there's only 1 way to do things. And that's not in all the spirit that was intended. Every time I hear that I cringe. Yeah.

And and and just for clarification to everyone listening, what it says is there should be 1 obvious way to do things.

And as a parenthetical remark, I don't remember if it's specifically in the zen of Python, but the parenthetical remark is that there may be many, many ways to do things but there should be at least 1 obvious way of doing it. Yeah. It's written there should be 1 and preferably only 1 obvious way to do it. Yes. Yeah, although that way may not be obvious at first unless you're Dutch. Yes.

And if you look carefully at the text

you'll notice

that

the they're they're m dashes, double dashes used to separate it out as syntax. And if you look at the poem, the double dashes are done in 3 different ways.

And that is entirely

intentional.

I did not know that. Thank you for that. Yeah. You know, it's really a shame that there's no humor in the pipeline community. Yeah.

Okay. And so

taking a slightly different direction, what in your opinion has been the most important or far reaching PEP whether it was approved or not?

Let's go in reverse order.

Okay. Oh, you're gonna put me on the on the on the hook this time. Oh, I don't know.

I don't know. I don't even follow these things anymore to tell you the truth.

The most important, most far reaching

In in your opinion or in your experience, and again, whether it was approved or not. So it could be just something that introduced an important idea that

fostered some conversation within the community.

Well, being being forced into the first slot, I get to take the easy answer and I get to answer. Hey, it's pep 20.

It's it's the pep that that encoded the philosophy behind the design of the language.

So anybody steps out of line all you have to do is point them at PEP 20 and say go read this, read it read it over and over and over again until you understand it, until you understand why what you're why we're not going to add braces to the language or or why we're not going to do this or that.

Because it just,

it's not beautiful, it's not

simple,

it's not flat, it's not sparse,

it's not readable,

you know, whatever the case may be.

That I think is the most important part of the language, it's the philosophy behind it and PEP 20

writes that all down. It's all it's all there. That's my answer, and I'm sticking to it. Thank you.

Chris, what about you?

I'm going to pick a slightly odd choice here. I had to go look up the number that it's set 466

where network security enhancements for Python 2.7

gets muted

because it's

a strange pairing

of backward compatibility

with

security improvements

in a Python that

a Python version that represents the promise of Python dev of stability.

This is not okay well you're going to have to change your code because Python 3.5 is changing something,

this is your code should keep running, but we're going to make it more secure.

That 1 had a lot of debate around it

and people saying things like, well, what if we just

bite the bullet and release the hypothesis point 8 and various other options around it.

But I think this is the right way of doing things.

It's a case of practicality

beating purity, isn't it?

Alright. So I'll just hide back in with PEP 20. There you go. Everything does. All all the roads lead to PEP 20. Yep.

Pep 8 leads to pep 20 as well. Yes.

Well, pep 8 was gonna be my choice.

Yeah. I I agree. That definitely is a very far reaching and important 1 because I think between PEP 8 and PEP 20, they beautifully encapsulate what it means to be a Pythonista.

Yeah. It's interesting because, you know, I have very mixed feelings about PEP 8 as well,

because I think

in similar ways to PEP 20, people

take it the wrong way. Yes. You know, they they misinterpret what PEP 8 is is trying to say. So what is PEP 8 again? PEP 8 is the style guide for for Python code.

So

but the important thing that people forget is that it's the style guide for Python code that goes in the standard library.

It's not it's not

what it was. It's certainly originally meant to be

the,

guidelines for all Python code in the entire universe, you know.

And we have tools like, there there are there's an actual pep 8 tool that will go through and try to, you know, say, oh, you violate this rule and you violate that rule. And,

in some sense, it's it's good that you can that you can kinda walk up to almost

almost any Python code and read it.

I think more of that is based on Guido's

what I think is Guido's

genius

observation, which is that code is written a lot more, way more than it's,

it's it's read way more than it's written.

So,

you know, you know, people read Python code

a 1000 times more than they write it. And at least at least I do. And

so to make

Python readable,

you know, and to design a language that is meant to be readable

is is great. Now, of course,

there's a lot of differences in, you know, how, you know, the style of Python should be written.

And there's tools, and I think that that kind of can,

can constrain people too much. And it certainly can make certain projects kind of not not so much fun to be involved in, but it was really originally designed to be, you know, if we're going to add this module to the standard library, here are the coding conventions.

And and this is, you know, this is the style for the standard library,

Python code.

You know what, though? I think there's a a a lot

of really good evidence out there that says that even if this was not originally designed to be the overall style guide for the for the language,

that there is a great deal of

good

for any given language in saying

this is a standard format

into which source code,

if not must, then perhaps should be placed. Right? Like, I feel like

languages like go and this is a, you know, an example. There is 1 way to format go.

And many, many people feel very strongly that that is to the language's benefit. Right? And I feel like the fact that PEP 8 has become the de facto standard for how to format your Python, such that if you use PyCharm or emacs or even Vim or any number of other tools, you can just basically say, yeah, make my code PEP 8, you know, and it and it will just sort of automagically

do the right thing and thus be more readable to other people.

You know, agreeing on standards like this, it's bound to annoy virtually

everyone, but I think there are there's a lot of evidence out there that

says that having something like this

is a real net win that we're all better off with it as opposed to without it. Yeah. It it definitely provides some consistent

expectations for anybody coming into a Python codebase.

And it definitely is useful as a guideline, though I definitely agree people

can often be too dogmatic about it. And Raymond Hettinger did a wonderful talk about this at the PyCon 2015

You know, PEP 8 is useful, but

it's not gospel. It's not the letter of the law. It's just a suggestion.

Yeah. It should, not

must. And and I think the other important thing about PEP 8 is what it doesn't say as well. And there have been lots of discussions about, oh, well, should we

add this particular

style question

to PEP 8 and settle it once and for all. And there's been, you know, as many things

where we've said,

no, that there's it's not appropriate to go into PEP 8, and people should be able to do what they want there as,

you know, prescriptive,

rules added to PEP 8. So it's it's

it's certainly an influential

document that really has,

you know, spread far and wide.

And I think it's important to keep it in perspective. It's use it absolutely,

you know, when when it's appropriate. And,

you know, don't worry so much if there's things that doesn't say. You know?

I think that makes a lot of sense.

So what was the strangest or most extreme PEP proposal you've ever seen?

Okay. Probably, I would have to say at least a recent time,

the proposed enhancement

to the S swing

interpolation

that allows automatic escaping

for whatever concept it might happen to be in.

Again, I had to look this 1 up because I didn't know the number, but 501.

And there's

this system of

allowing shell quoting, SQL quoting, HTML quoting, etcetera

and you just magically include

these tokens

and something somehow

knows to escape them appropriately in whatever way.

It's a nice idea,

but

it's

it is so different from what we currently have that

I suspect this one's gonna be the next thing that lies around for 10 years.

It sounds like shades of tickle, honestly.

I think it's in 36, isn't it? I think it I think it got accepted and

The the basic

format things did and, actually, I've been using them sometimes because I run 3 6 here.

But the

the extended thing that automatically escaped

shell or SQL or something, that's deferred.

Yeah. I remember seeing this pep show up on my radar, and I was actually

fairly excited about the f strings.

I didn't notice the bit about the escaping, but being able to automatically interpolate variables into a string just by having the f prefix, I was quite interested in because there are certainly some times where

having the full dot format method call can be unnecessarily verbose.

Yeah. I agree.

Alright.

So Barry, how about you?

Well, I I think that's an excellent example because it is very different than, Python,

or what people are sort of used to Python.

I I don't know. I I

I think there have been some pretty extreme ones that haven't made it into the repository.

So,

but,

I think the 1 some of the ones that I think,

are are

out of the ordinary but could be just as influential are some of the recent peps about changing

the workflow.

I'm thinking,

pep, they're in the 500. It's 501,

maybe, and

507, something like that.

You know, 1 of the things that I I think we're we're sort of struggling with is how to,

you know, keep Python vibrant for the next 20 years. And

so much has changed about software development

since Guido released

Python. That if we don't

continually,

question how we're building Python and how we're accepting contributions

and, you know, what version control system and where we're hosting things and all those kinds of questions,

you know, we're we're not gonna keep,

you know, getting new blood,

into into the community. And and that's vital for keeping any especially an open source language,

vibrant.

So,

you know,

some of us old timers, you know,

we need the young blood to come in and, you know, and help us,

you know, keep Python alive for the next 20 years. And I think those

peps are the are really critical to

making things, welcoming

and open,

and, embracing some of the newer newer,

workflows that people are used to in creating open source software. So

Yeah. And I think that that's 1 of the great things about Python and its community is that as a whole, we're all very pragmatic

and open to

accepting that, you know, the way that we're doing things now isn't necessarily how they should always be done far into the future. And that in order to maintain viable, we do need to make sure that we remain welcoming and that we

continue to accept new ideas and incorporate them into the language so that we can continue to use this wonderful language for, you know, throughout our careers and the careers of those to come.

Yeah. And there's controversy as well because, you know, people, you know and nobody likes to change their workflow, something that their fingers are sort of comfortable with. But, you know, so how do you how do you make it so that, you know, people who are used to doing things in a certain way won't just give up in frustration because

everything's changed.

It's a it's a tricky balance.

Alright. And, David, how about you?

I think I'm gonna propose PEP 666,

reject foolish indentation.

And the number should give you a clue here. This was a PEP that was submitted

with the intention

of having it rejected

just to shut some people up.

It had to do with the mixing of,

tabs and spaces in Python code.

And just to say, you know what? Do what you wanna do and don't and and just

leave us the heck alone. And

and here it is. It's encoded. It's it's it's all spelled out, and let's just reject the damn thing and move on with our lives.

I like the way that it was that the the system was sort of subverted,

and used

in this way

without any intention of having it actually implemented. It was just like

propose it, reject it, move on.

Yeah. That that's a great way to short circuit a lot of,

anger as well because rather than doing any sort of attacks on anybody or finger pointing, you're just saying in a very non confrontational way, you know, this is silly. Let's move on.

Exactly.

So before we move to the picks, are there any questions that we didn't ask that you think we should have or anything that you would like to bring up?

Mine's a blank. Okay.

Alright. So with that, we will move on to the picks. And so for my first pick today, I'm going to choose the Wagtail

CMS from the developers over at Torchbox.

It is a Django module that has a lot of really great CMS functionality

that

seems to be really well designed and well thought out. I'm actually in the process of using it to rewrite the site for this podcast. So I've been enjoying it so far. The documentation is very well structured and put together. So I'm excited to

get to the end result and start actually using it in my day to day workflow for the site.

For my next pick, I'm going to choose the Disney Pixar movie Inside Out. I just watched it recently with my kids and it's just a really well done movie, great storyline,

really interesting treatment of a lot of psychological

principles

and personification

of our emotions.

So I I highly recommend it. It's got something in it for everybody.

And my last pick today is the Spark podcast from the Canadian Broadcast Corporation.

It is a podcast that does a really good job of

sort of doing a reality check, particularly for all of us working in technology

and just taking a step back to see

what kinds of effects all of our

rapid innovation is having

on us, you know, socially, politically, ecologically,

and seeing, you know, extrapolating into the future what kinds of effects these different technologies will have going forward. So it's very thought provoking, very well put together, excellent,

production quality. So I highly recommend everybody listen to it. And with that, I will pass it to you, Chris.

Very cool. I just wanted to quickly second Inside Out.

My wife and I went to see that, and I'm usually the 1 who runs around gushing about the latest Pixar film, but it was really nice to see her actually recommending that movie to people. And we noticed at the end that it was made

with the Institute of Mind Studies.

It's it's it's definitely a thought provoking movie. We talked about it for a few weeks afterwards, and it still comes up from time to time. It's definitely don't disregard it because it's an animated movie. It's it's as Tobias said, it has something for everyone.

So my first pick is in the same vein. It's a movie. It is a movie that is out now in theaters called Trumbo,

and it's about a writer who

really sort of bucked the whole blacklist

House Un American Affairs Committee trend

during that really dark era in America's history.

And I feel like given a lot of the discussion that's going on now about some of the,

you know, trade offs between,

keeping us safe and, you know, our individual rights. I feel like it's really important for people to recognize that

these things can happen here. It's not totally factually accurate, but that should not get in the way of you going to see it because it it definitely tells the story very well in my opinion,

and there's some great acting there. My next pick is a YouTube playlist called Kivy crash course.

I am a huge fan of Kivy. I like, it's 1 of the things when people look at me and say, well, what's so big about Python? You know, what's the big deal? It's just another scripting language. And I pull out Kivy and and show them how you can create really truly cross platform UIs across desktop and mobile and, you know, in a few minutes flat. It's it's a really impressive piece of tech that really showcases the power of Python, and this series of YouTube videos is just a really great sort of gentle introduction to using it that shows you how to build an app and build it for the various platforms very easily.

Good stuff.

My last pick

might strike some people as kind of odd.

I personally have been very, very

concerned of late that we are we here in America, in particular,

are becoming a fear driven society.

I think that would be that's a huge mistake, I think, as opposed to

just sort of, you know, being awash in this in this media

craze of, you know, images that cause people to,

you know, live their lives constantly worrying about what might jump out from around the next corner.

Let's sort of educate ourselves and actually understand the situation, what's happening, what some of the motivations are, and and how what we,

as individual people, can do to make our society a better place.

So it's a podcast called the Jihadology

podcast,

and it really goes into some interesting depth in

the,

Islamic Jihad movement around the world and all the individual groups, not just ISIS, that make up a part of it,

and what some of their motivations are, what some of their history is. And I just feel like, you know,

know thy enemy,

is is an important thing to keep in mind.

So that's that's it for me. Barry, what do you have for us for picks?

Well, my my first pick,

I suppose a lot of people may know about, but I'm kind of surprised at how many people aren't really aware of these tools that, for me, writing Python code

are are absolutely,

like like, the first things I add to any empty, you know, Git repository. Right?

And that is, talks and knows too.

And,

I think they're they're really

great tools. Talks is a tool that sort of sets up virtual environments and runs the code

testing in each of those virtual environments in a really convenient way.

So if you're gonna write a library that you're gonna say, hey, this is gonna be Python 27, 34, and 35 compatible,

You can you can set up your environments,

so that all those virtual environments are are managed for you and your tests run-in all on on all of those. And,

I that's I have to write a talks dot any file that, you know, kind of like as the first thing after a setup dot pi. And, I'll put up and the plug for nose 2 is really,

for me,

you know, there's lots of different test runners. I like those 2 because I really like the,

the plugin,

system, and I use that to, have a really rich,

both doc test and unit test

environment. So,

and then I'll just put in another plug for, hey,

port to Python 3, you should be doing this, this is really, you will love Python 3.

So,

my second pick

is,

the show,

Jessica Jones, which is on Netflix. You can you can binge watch it and I've been binge watching it. I'm not quite done with the the the first season, but I've really really enjoyed it. It's

been,

quite entertaining.

It's

sort of based it's in the Marvel world of superheroes, and I I think,

the the acting is excellent, and there's this sort of

darker,

more introspective

side to

to the plot and to the characters that

you don't always see in a superhero based

movie or or TV show, and I'm really enjoying that. And,

the the main actress,

was,

Jesse Pinkman's girlfriend in, Breaking Bad, and,

you'll see a cameo by a Doctor Who in there as well. So it's really quite

a fun time.

And my last pick is,

something that

my brother-in-law actually

loaned me, and I've been listening to these

and just devouring them in the car.

It's

a 5

sort of

series set where each series has,

20,

CDs,

and it's called The Joy of Science.

It's taught by, it's

basically an audio lecture,

and each lecture is about 20 minutes, 25 minutes, so easily consumable.

It's taught by Professor Robert Hazen, h a z e n, from George Mason University.

And it takes you

through

the very basics of science, like the scientific method. And then they talk about, you know, everything

from, the discovery

of electrons and electromagnetism

and thermodynamics

and

then the different models of the atom, the Rutherford model of the atom and then the Bohr model of the atom, which is

closer to observable

phenomenon.

And all the way up through,

special and general relativity and quantum mechanics and chemistry,

and

the lectures just build in such a way that

I think they really, you know I've always been into those kinds of topics,

but there's been a lot that I've learned as well about, you know, what

is chemistry? You know, how

do the different phases of matter,

manifest themselves in in our everyday lives? So I I really enjoyed this this CD set, and, I highly recommend it for any anybody who's into that kind of thing.

So so just real quick,

we just watched the first episode of Jessica Jones, and it is awesome sauce. We really like it a lot.

And and with regards to the joy of science, I just wanna make a note that you are the second guest that we've had in recent times to pick a 1 of the great courses. Because when I just looked up the URL for that, I saw that it was it was part of that series. And,

we just had a guest just a couple of episodes ago pick the ancient history,

course in the great courses.

So, obviously, there's some really amazing stuff there.

So, Chris, what about you? What what do you have for PICS?

Oh, I have a a favourite place that I point people to anytime they're confused about Git, which is the Git name page generator.

It

uses Markov training

to generate some remarkably

plausible

man pages for git subtler.

I strongly recommend

at least browsing it for a little while.

When you think you understand everything,

there's proof that you don't.

Yeah. I've taken a look at that, and it's definitely quite humorous.

Oh, yeah.

And,

my second pick

is dailymcg.com,

where,

you get articles about Magic the Gathering.

The design articles by Mark Rosewater

actually tie in very well with good design in software. As well. He's talking about game design

of something that is easily as complicated as a full size Python project

and it's

it's great to read a slightly different

look at design.

Oh, and I'd also like the second recommendation for Inside Out. It's

awesome. David, what do you have?

Okay. Well, I'm I'll third the Inside Out. I just saw it for the first time on Saturday, and it was really good. No spoilers. No spoilers. No spoilers. No worries. It's very good. But as for my picks, okay.

I'm sure that a subset, if not the entire set of my picks, has been on here before, and I'm ashamed to say that I haven't listened to every single 1 of your episodes. I have listened to many of them, but not every single 1. Okay.

My first 1 is

a documentary called Tim's Vermeer.

It's a mind blowing documentary about an inventor named Tim Jenison.

He's the man behind the video toaster and light wave 3 d. And it's about his obsession with the paintings of the 17th century Dutch artist,

Johannes Vermeer.

So

Tim Jenison, he noticed things about these paintings

that along with his expertise in video and and graphics, computer graphics sort of

cause an itch

in his mind, and he set out to scratch the itch. He set out to replicate the process by which Vermeer may have created

his incredibly photorealistic

paintings, I mean, 100 of years before photography was invented.

And,

when I first saw what he came up with,

the very crude initial version, my jaw just dropped to the floor.

And so this is a documentary narrated

by Penn Jillette and directed by Teller of Penn and Teller fame.

So that's my first pick. My second pick is a novel

called Ready Player 1. It's a science fiction novel by Ernest Cline that incorporates a plethora of references to 19 eighties,

pop culture, especially video games. It's great fun. It's an absolute blast of a read.

A film is currently in preproduction

to be directed by Steven Spielberg and is scheduled for release in 2 years, December 2017.

But I'd highly recommend reading the book first because chances are the movie's gonna be a dud. And if it's not, then

you'll still benefit.

I have a 3rd pick. It's another documentary

also by,

partly by Penn Jillette. It's called the Aristocrats.

It's a documentary about a joke told by comedians amongst themselves.

It's the dirtiest,

filthiest,

most obscene,

and funniest thing I've seen in a long time.

The joke starts, a man walks into a talent agent's office and says, have I got an act for you? And I don't say anymore because everything else is it would be working blue.

It goes downhill from there, but it is drivable. Oh, it's so funny. It's so funny. You'll be laughing.

If you can handle obscenity,

and this is obscene. Okay? It is. It's incredibly obscene. If you can handle obscenity, then it's really funny. If you can't handle obscenity,

avoid it like the plague.

And I have a couple of more quick little ones.

1 is something I just discovered today. It's it's called scientific songs of praise

at, scientific song dot com. It's basically classic Christmas and holiday songs

be written with secular scientific lyrics.

And they've got YouTube videos. They're releasing them 1 every day or 1 every week or something until Christmas. And then they're gonna release CDs and I'm gonna get a copy for myself. It's really cool. I I mean, rather than,

oh, holy night, it's oh, satellite.

And the video for that, I mean, I just teared up watching it. It was really cool. And my 5th and final pick is another podcast called Hollywood Babylon.

This is a regular listen for me whenever they pull it out. It's also,

obscene, I guess. It's it's got some foul language, but it's really, really funny.

It's Kevin Smith

and Ralph Garmin. These 2 guys who just who just go to town on Hollywood stuff. It's like,

Hollywood,

not, what was it? It's Hollywood Babble On, babble,

On.

It's it's like Hollywood gossip, and they take no prisoners.

It's a lot of fun. So that's it for me. Wanted to add 1 1 interesting

thing. You know, you mentioned Ready Player 1, which of it's it's an excellent book.

If I remember correctly, the music of the Canadian rock band, Rush, is featured fairly prominently in that book. It is. Yes. It is. And just today,

Neil Peart, the drummer, announced his retirement.

Oh, no. So Russia's probably done with.

They're getting on in 8 as all all the rockers from the seventies.

Yep. Yep.

Your mention of the scientific songs of praise reminded me of a piece that I came across recently, Steve Martin singing his hymn for atheists.

So I I added a link to that in my picks. Oh, thank you. I have not heard of that 1, and I love Steve Martin. He's he's a funny guy. He is.

So I just wanted to mention, Tim's Vernier. I actually haven't seen that documentary, and I'm totally gonna hunt it down because I'm a video toaster fan from way back. I mean, I I remember the new tech demo.

It it's funny because earlier on when, Barry, I think you mentioned the next next and next step, And Chris, you mentioned OS 2. All I thought to myself is, now I need someone to mention the Amiga and my retro geek, you know,

past will be complete.

And, David, you came really close. You didn't mention it explicitly by name, but you mentioned, you know, Tim, the inventor of the video toaster, which ran. It was a a coprocessor

card that ran on the Amiga platform, so we're gonna call it a trifecta and and and deem it a win.

Alright.

Well, this has definitely been a lot of fun. I really appreciate all of you coming on the show to talk to us

and banter about the PEP process and various other things. So

for anybody who wants to follow you and keep in touch with what you guys are up to or learn more about the PEPs, what would be the best way for them to do that?

Oh, wow.

Well, if you're specifically interested in the PEP process, I I would make sure and I'm sure most the people who are listening to this are subscribed to Python Dev and Python Ideas.

That's really kind of, I think, the best way to to stay in touch with the, Python community. All the other thing I'll mention is,

I forget what the email list is, but

all new

bugs that are opened on the tracker get sent to an email,

to a mailing list. And if you want to stay in touch with what's happening in the Python world,

get on that mailing list

and get on, Python dev and Python ideas or follow them through Gname because,

that that you'll have your finger on the pulse of everything that's happening in the Python world.

If you wanna stay in touch with me personally,

I rarely blog. But when I do,

it's we fear change dot org. All 1 word.

That's awesome.

And, Chris, what about you?

I also don't blog a huge amount, but when I do it's rosuav.blogspot.com.

That's rosuav.

If you really want to know what I'm doing, then you could follow me on GitHub or something because there's a lot happening there,

but,

I don't think there's

much of particular interest.

Alright. And, David, what about you?

Well, I've been intending to start a new blog for several years now and just haven't had enough around to it.

But, let's see. I guess you could

to to see

links to everything that I am and that I have done,

You could go to, david.goodger.org,

and that has links to everything else if they move around.

My main website is on, python.net/goodger.

So,

squiggly tilde, you know, the 1 just under the escape key on your keyboard.

Goodger. And and that's but that's linked to from david.goodger.org.

I don't I don't tweet.

I don't blog much lately. I don't Instagram.

I'm, asocial.

Alright.

Well, again, thank you all very much. It has been a lot of fun. I really appreciate it. It's been a lot of fun. Thanks so much. Thanks, man. Thanks for putting out a really good podcast. Thank you.

The Python Podcast.init

Summary

Brief Introduction

Interview with PEP editors

Picks

Keep In Touch

Links

The Python Podcast.__init__

Summary

Brief Introduction

Interview with PEP editors

Picks

Keep In Touch

Links

The Python Podcast.init