Do you or your team maintain a large Python 2 code base?
Would you like to move to Python 3, but there's just too much in place keeping you on legacy Python?
Then you will definitely enjoy the story from Jason Fried.
He created a grassroots campaign to move Facebook's massive Python 2 code base over to Python 3.
And he made Python 3 part of Facebook's culture today.
There are lessons here for every listener.
This is Talk Python to Me, episode 185, recorded November 10th, 2018.
Welcome to Talk Python to Me, a weekly podcast on Python, the language, the libraries, the ecosystem, and the personalities.
This is your host, Michael Kennedy.
Follow me on Twitter where I'm @mkennedy.
Keep up with the show and listen to past episodes at talkpython.fm.
And follow the show on Twitter via at Talk Python.
This episode is sponsored by Linode and Rollbar.
Please check out what they're offering during their segments.
It really helps support the show.
Jason, welcome to Talk Python.
Thank you for having me.
It's great to have you here.
We've been working on this for a while, haven't we?
It's been a long time.
It's one of the more drawn out, sort of getting a guest on the show.
But I think people are going to be really happy about it.
I think it's a great story.
And the timing is perfect around the move to Python 3.
Yeah.
Yeah, it's going to be super fun.
So we're going to talk about how you've done this at Facebook.
And you didn't just start.
It's a long journey.
But before we get into all that, let's start with a little bit of your background.
How do you get into programming in Python?
I didn't have anything to do with Python until I moved to Facebook.
So before that, I was a Perl programmer.
I'm kind of ashamed now.
But I used to love Perl back in the day.
And then that was not socially acceptable when I moved to Facebook in 2011.
So I had to learn Python.
And surprisingly enough, I picked it up very easily.
And because I'm a little obsessive, so I dug into it enough that I started helping people.
And that kind of started...
I guess I thought of myself as an expert.
But even today, you always get better and better as you get.
And you look back at some of your old stuff.
And you're like, yeah, I used to write code like that.
It doesn't matter how much of an expert you are.
There's still plenty you don't know.
And there's still stuff that you look back.
You're like, whoa, I did that.
That was bad.
Yeah, you're like, don't look at that old code, please.
It's like my skeleton, so my closet.
Exactly.
Well, it shows you're making progress, right?
Yeah.
I do think it's highly interesting that you were one of the driving forces for this entire
sort of transformation at Facebook.
And yet, you walked in the door going, Python?
Is that the one with the space?
Or is that a different language?
Yeah, I played with it before.
But I didn't really know how to write it.
You didn't come in as like...
It's not like Guido von Rassum came in.
It's like, all right, we're going to change things.
We're going to fix it.
Like, basically, more or less a beginner, a newcomer, was the driving force.
And I think that's an interesting part of the story.
Yeah, I don't think it's like...
So, I guess I came in like the end.
It was October of 2011 on Halloween.
So, I really didn't get involved in the whole community of Python at Facebook until 2012.
And we have internal Facebook.
And there's like groups and stuff.
So, there was a Python at Facebook group.
And there was a lot of people learning Python.
And because I picked it up, I guess, quicker than they did, I was able to help them out.
And because I was helping them out, people just assumed I knew what I was talking about.
That's interesting how that happens, right?
Yeah.
They don't know you that well, right?
They're like, oh, this guy's telling me stuff.
So, he must know it.
And because I'm like, you know, I think I know what I'm talking about.
I go and fix things.
And I start fixing enough stuff that I start touching stuff all over the code base and different projects that I'm not involved in.
Because I have to touch like either one thing and I don't like the way it looks.
So, I'm going to go fix it.
And, you know, you somehow turn into before you know what people think of you as the subject matter expert.
Yeah.
That's really interesting.
And I guess in some sense, you sort of fulfill that prophecy by doing it enough until you know.
But there is that weird middle ground where people see you that way and you don't really see yourself that way.
But you kind of are.
Yeah.
Interesting.
So, what do you do day to day these days at Facebook?
So, I'm on a team we lovingly call the Ministry of the Silly Walks.
Initially, it's called the PE Python Foundation.
But it's an internal team.
And we are taking care of Python as a runtime at Facebook.
So, it means ensuring that we update it in a timely manner that we're going to have 3.7 something released in the next couple weeks.
That we're going to look at those shared libraries that have existed for 10 years.
And nobody like to make sure that we're doing best practices instead of, oh, yeah, well, Ted wrote this in 2008.
So, it's still good, right?
And you're like, no.
Yeah.
Maybe we shouldn't be rewriting our own thread pools everywhere.
Maybe we should just use concurrent futures or stuff like that.
Yeah.
Yeah, exactly.
Like, that's built in.
Let's not reinvent the world.
That's quite interesting.
I'm sure there's some old stuff like that.
So, I guess one question to the extent that you're allowed to answer it.
I don't want you to talk about anything you're not allowed to.
But when I think of Facebook, I think of PHP.
What's the story with Python at Facebook versus, I know Instagram joined, but there was Python at Facebook before Instagram was part of Facebook.
The software engineers that run the front end, it's all PHP.
But in the back end, people who are like SREs and these system administrators and ops people, they love Python.
Or they did back then.
So, they wrote all these scripts in Python.
They were all these things to, like, push the front end in Python.
So, you end up having this infrastructure to keep the site running all written in Python.
We've talked about this all the time.
So, like, if you have, if your service throws an alarm of some kind, there's another service that reads that alarm and starts running these remediations people have written in code.
Well, that code is Python.
And it's all written, the service to do it is Python.
And the service that distributes that is Python.
It's like, basically, it's we filled in the glue was with Python in the back end.
Where all the cracks were, it's been filled with Python.
Exactly.
Interesting.
Okay.
How interesting.
So, I guess that's probably a good segue to your main topic.
And because one of the things you started creating in Python 3 there was this infrastructure stuff.
So, maybe let's get started by, you know, I just wanted to ask you, I have my own strong opinions about this.
But do you believe that there's any debate about whether you should use Python 2 or Python 3 these days?
Or is that, I mean, several years ago, that was a solid debate that was raging.
Do you think it still is?
I don't think it's a debate anymore.
Like, there's a site, I don't happen to know, but you could probably find it, that it's the scientific Python packages.
And it's like them signing off to drop support for Python 2.
Yes, that was, it's like called the Python 3 statement.
Yeah, it's crazy.
It's done by Matthias Ossier or something like that.
Yeah.
And there's tons of these projects.
I also don't know the name of the URL.
Sorry.
Yeah.
But there's tons of these projects that said that, oh, people just assumed they would always be Python 2.
And they're like, no, we're going to get rid of our Python 2 support.
Yeah.
I think it really changed when, I think when the Python death clock went up.
Also, I don't happen to know.
But Guido was like, look, let's just make it January, January 1st of 2020.
Yeah.
Let's not.
Yeah.
I think it was on the mailing list.
He said, let's don't miss words about when this might be.
We're going to make it January 1st, 2020.
Not, you know.
Yeah.
I think the only other really good option.
Yes, exactly.
The other possible one could have been PyCon.
So it could have been like a party like right then.
But I feel like the sooner the better, honestly.
Yeah.
It's like, I know we don't have this debate at Facebook anymore.
We've won that debate.
I do a new hire training class.
And it's like, well, if you're already on the fence of whether you're going to use 2 or 3, you're a little late to the debate here at Facebook.
We won that debate in 2014.
Exactly.
You need a time machine to beat that one at this time.
Yeah.
And there had been a lot of conversations around, well, this library doesn't quite support Python 3, so you can't quite move yet.
And all I've seen in the last year and a half is here's one more amazing library that's Python 3.5 or 3.6 because it's using certain types of type annotations and async and await and so on.
It really feels like the argument and the evidence has shifted that you're being left behind with all these cool libraries, not stuck because of these cool libraries.
So the URL that you're looking for is python3statement.org.
That's a good one about the scientific ones.
Okay.
I agree with you.
I think that's great.
I remember, I think this was you.
I saw this around on Twitter to the effect of when Python 3.6 shipped, you said within two days, Facebook was running Python 3.6 in production.
Was that you?
Am I remembering that right?
It may have been Lukash.
It may have been Lukash, yeah.
I may have said that, but we were very aggressive on 3.6.
We've slowed down a bit because it's gotten more complicated, but we're going to be 3.7.
And I'm trying to push internally that we get these things released quicker than the external release schedule so that we don't build up that layer of, oh, people have snuck in internal patches or something.
One of the things you talked about that I thought was interesting is basically people get stuck on the idea of this is going to be an impossible problem to solve and we just can't do the switch.
But once you've made the switch from 2 to 3 and then 3, 4 to 3, 5, like this starts to become a habit.
You're like, oh, yeah, we just do that when a new one comes out.
Is it sort of feeling that way now?
Yeah, we've gotten to the point because we don't support multiple versions of 3 at Facebook and we never supported multiple versions of 2.
You just kind of you got moved along whatever the slow pace that the compilers on the team would push things out.
But for 3, it's just if we break you going to 3.7, it means you need to fix your code.
It's your problem, right?
Yeah, it's your problem.
We're going to let you, we're not going to do it by purpose.
Like on purpose, we're not going to like, we'll let you know, we'll try to fix it.
But if we can't, we're going to involve you because we don't support multiple versions of 3.
We're all going to be pushing forward.
You know, we don't want to be, we don't ever want to be stuck in a situation like we were with 2.
Right.
I think it's a really interesting lesson.
You were like, well, we were badly stuck.
And so now we're going to be very aggressive and never getting stuck again.
So your original talk, so you've given two presentations at various PyCons about this, one at PyOhio 2016 and one at the latest PyCon US in 2018.
Your original one was entitled Rules for Radicals.
Why the radicals identifier?
What was radical about all this?
You know, when you're trying to think of a topic, the name of your talk, you try to want to get something that will make the conference team get it.
And then you have to kind of get it approved internally.
And I think I had three different topics.
I think one of them was, we used to call it like lies.
And there's basically about lying to people to get for their own good.
But like, yeah, Tom's like, you can't say that.
I was like, okay, well, how about Rules for Radicals?
Because it's like that.
I've never read the book.
I've read Epsirps from a little ago.
But it's like, it's all about making change.
So I was like, what?
It's kind of perfect for my talk.
My talk's kind of about like driving change from a position of no power.
Right.
I think that the no power aspect is one of the super interesting aspects.
So many companies and people tell me that like at our company, we can't, we're still on Python 2 because no one has decided.
And one of the really interesting things is the Facebook engineering culture and this aspect of sort of earned authority, I guess.
Like you don't really have authority, but you start answering questions and helping people.
And you're like, oh, that person knows.
So I'll listen to them.
So maybe talk a little bit about the culture and how that worked there or still does.
Yeah.
It's a very, it's a great place to work.
So if you're on the fence about working for Facebook, just work for Facebook.
It's great.
But the thing is, it's like it's engineer led.
So a manager or someone in leadership never comes and says, oh, we're going to use this technology.
We're going to use Twisted or we're going to use Django.
No, it's usually, it's engineers say, you know what?
If we use this module and they convince their engineers next to them that cross the hall down the street in Dublin, Ireland, and they all start using this thing, we start using it.
And it's like you have to build up consensus by having a good idea because nobody has the like dictatorial thing.
Like we're going to do it this way.
Right.
There's not an on high statement that we're going to be using this technology or that technology.
It's just like, all right, you all are smart engineers.
These are the problems.
These are our goals.
Make it happen.
Exactly.
It's like this is, and then I go to these engineers and be like, look, I can have an argument.
This is what I think we need to do.
And if, and you're like, we should, you know, we should go to Python three because it is, it is looking this way.
It's going to be the future.
And at the time it was very sketchy.
Like it may not have been the future, but now we're no, we've, we clearly made the right decision.
It's like, once we like, look, do we want to be stuck in the old age or do we want to be able to keep moving forward?
Cause it's like, if we don't make a decision now, we need to like prepare for the other case.
Right.
And by the time that argument gets settled, it could be really painful to turn a big ship of technology like Facebook.
Right.
Yeah.
So we needed to get started early.
This portion of talk Python to me is brought to you by Linode.
Are you looking for bulletproof hosting?
That's fast, simple, and incredibly affordable.
Look past that bookstore and check out Linode at talkpython.fm/Linode.
That's L I N O D E.
Plans start at just $5 a month for a dedicated server with a gig of Ram.
They have 10 data centers across the globe.
So no matter where you are, there's a data center near you.
Whether you want to run your Python web app, host a private Git server or file server, you'll get native SSDs on all the machines, a newly upgraded 200 gigabit network, 24 seven friendly support, even on holidays and a seven day money back guarantee.
Do you need a little help with your infrastructure?
They even offer professional services to help you get started with architecture, migrations and more.
Get a dedicated server for free for the next four months.
Just visit talkpython.fm/Linode.
What are some of the things that you felt like came out in Python 3 that subsequently came out and you're like, oh, this is one of the things that were really important to us that we didn't know, but we knew things like this would be available if we did this.
Well, you know, it's like, I think early on, because like when we were wanting to go to Python 3, it was still Python 3.3.
It was still, most people don't consider Python 3 worth anything at all until like 3.4 or 5 came out.
And some would probably say 3.6.
But I think I was even on the fence to a certain point.
I was very much in the two only school.
But I went, I was really in, because, you know, we all know Python, we have this GIL.
We, unless we're doing IO bound work, we're really handicapped in the single thread or multi-thread for CPU bound tasks.
And I was, being a new person in Python, I wanted to solve this solution.
So it was like async.
Async's the solution.
And at the time, I was a very big G event person.
You know, I looked a little bit about Twisted, but Twisted, I was still new to the language, and it was just too confusing for me.
Right.
It is a little different, yeah.
But I went to a talk by Guido when he talked about Tulip, which is what we call asyncio, or what was called asyncio now.
And I just like had this epiphany, like all this stuff, because like I'm writing, I'm writing libraries for people to use internally.
And if they have not, if they have decided to use Twisted, they couldn't use my library if I wrote it in G event.
Or if I wrote my library in Twisted, they couldn't use it in G event.
Or they had to like kind of make a religious decision about which framework they were going to use, because they were very opinionated.
Right.
So all of Python's async capabilities was like these random grassroots projects.
Yeah.
And none of them had anything to do with each other.
None of them talked to each other.
Right.
Exactly.
And I had this, it was like, wait, if this is in the standard lib, and people can use it, and they will, because it's easy enough to use, that means that we could all standardize around it.
And I think the day after, like Tornado, which has got an async framework around it for doing these websites, it posted abilities to tie into the event loop.
And then it was like, well, if Twisted did it, and now we have Twisted, you can run your Twisted application or run async.io on a Twisted event loop and vice versa.
So you can like, we're in this magic world where I, as the library writer, don't have to make the religious decision for the application writer, that they can decide to be like natively twisted.
Right.
Because that's the wrong direction.
Right.
And I was like, we need to go to Python 3.
We have to have async.io.
You know, because I knew async was the future, but there wasn't a clear path in Python 2.
But in Python 3, there was a path.
Yeah, and I feel like the async story in Python is getting a lot better.
I mean, you talked about async.io, and then we have like a cleaner API with async and await.
Yeah.
We have a bunch of these cool web frameworks coming along based on things like UV loop, which, you know, replace the async.io event loop and all sorts of cool stuff happening there.
Yeah, there's like even reimagining of async.io using async await.
There's two competing frameworks for async.io.
And someone has already written compatibility drivers so you can basically patch them to each other.
So if you have a library written in the email, you can use them.
And I was like, that is the future that I saw back in 2013.
Right.
And I think it's coming to play.
And that was what I really, I was like, oh, we have to do this because, you know, I'm tired of making these janky geovint libraries nobody can use.
I want to make so that people can actually start working with.
Yeah.
And I can definitely see that at Facebook.
Like you're building these libraries and you want people to adopt them.
Well, you know, you don't want to have that be a real small group.
You had an interesting.
So I think some of those additional reimaginings are probably Trio, Curio by David Beasley.
Trio, Curio.
Someone has already written compatibility to make them talk to async.io applications.
And I don't know if they can talk to each other, but I've seen one that talks to either or.
Right.
You can probably chain it through like.
Yeah.
Go to async.io to Curio or whatever.
Right.
Yeah.
All right.
So I think one of the really interesting parts of this journey is to sort of go through the years because kind of like we started off, like the view of Python 3 now is really different than the view of it five years ago.
Exactly.
There's absolutely advocates and people pulling for it, but it was a different world.
So want to take us back to 2013 and sort of start there?
Yeah.
I think like it was like back in 2013, there was a big movement of the let's just stay in Python 2 forever.
Like I guess that I think there was this undercurrent that the core team of Python, of CPython had lost their minds.
And then Python 3 was ridiculous.
And it was a very, I think I may have, I was new to the language.
So I just like, I just picked whatever everybody else was using at Facebook, which was 2.6.
Well, and you look around, like on Stack Overflow, there were people saying never move to 3.
Like that's just a waste.
I mean, there was a lot of that sentiment happening.
People were like, oh, don't bother learning Python 3.
And you're just like, you know, and then when I learned it, it was just like, why did we, you know, it's not that bad.
Honestly, I feel like the differences are so small.
Sort of modern 2.7 and Python 3 is like, well, you put parentheses on the print statement and like a few other handful of things that they're, none of them are like massive conceptually differences.
Right.
It was the libraries.
Yeah.
The libraries.
Cause like, especially cause in, in 2.6, like we had to change the way you did exception catching.
The change, I don't, I don't even remember what it was, but I remember we had to fix it because it was like, it got deprecated by the time 2.7 came out.
It no longer worked.
So it had to fix stuff, but it was like, there were so many old crusty things that had been running on like Python 2 for like 10 years.
So people were just like, no, I don't want to do it again.
You know, they were just like.
Well, and maybe the person who wrote that part is not even at the company anymore.
No one wants to touch it.
Exactly.
They don't want to, they don't want that thing to become their problem.
Right.
They just want to work on their stuff.
It's the same for a lot of third party, third party libraries that the person maintaining it just disappeared.
We don't know if he's dead or she's dead.
We just, they don't respond to emails or, you know, and their project is just kind of withered away.
Yeah.
People use it.
Retired.
They don't care about it.
Maybe they've moved on to Node.js or whatever.
Right.
But for whatever reason, they don't care.
And the crazy part, some of these modules are super popular.
Yeah.
Like the MySQL driver.
Yeah.
That one, that one, that one became basically unattended.
Yeah.
Wow.
How interesting.
I can certainly see like maybe some burnout as well.
Right.
You're just like, I just got to take a break.
If no one else is going to help, this is just going to sit here.
Cause you know, you gotta, gotta live your life.
Right.
Your goal is not to just provide software to the world.
You're a human.
Right.
Exactly.
All right.
So you said back in 2013, you're kind of like, I would love for this to be a thing to use Python 3, but I don't think it's going to happen.
Right.
You actually had access to Python 3, theoretically, as an option.
But in practice, it was all messed up, right?
Yeah, like the binaries were there for Python 3.
You could run them and get the interpreter.
But we have kind of a complicated environment.
We have build systems that go and build C++ dependencies for compiled modules.
And they kind of make PEXs, which is basically, it's like an archive of all your code that
you can distribute to a machine and just kind of run it like a binary, but for Python.
Right.
It's like a hacked zip file that's executable.
Exactly.
And it bundles up all your definencies.
But it does not bundle up the Python runtime, right?
It's effectively like a virtual environment, kind of.
Yeah, it's a deployable virtual environment.
And the system that we had that built that didn't work.
So it would call out to Python 2 to run, to basically import your code and do a .compile
using the compile module to get the PYC.
And then we would just pack up the PYCs to make this PEX thing.
And of course, it was like, you would give it Python 3 code and the PyTor compiler would
blow up on it.
And you're just like, great.
And then once you fix all that, it's like, you get this PEX and you run it and it just
seg faults.
Or not just seg fault.
It just stack traces like in the early guts where we're setting up the environment.
You know, you're like, oh, great.
It's deeply down broken.
This is not my problem, but it's not going to run, right?
It's like deeply broken.
And it's like, I could have just thrown my hands up at that point, but like, this is
never going to work.
And I may have for a week or so, but like, once you figure out that nobody's going to fix
it.
You do talk about that sort of be the change you want to see in the world.
And eventually you're just like, well, if no one else is going to do it, it's going to
have to be me, right?
And it turns out, yeah, like if you want something to change and you wait around for
someone to do it, it may never happen.
It likely will never happen.
Yeah.
Likely will never happen.
So I started fixing it and got like, I would get it to compile and then I would, I put up
a diff and have to like go chase down people to like, who knew kind of the system I was
messing with to do the building.
Like, Hey, could you review this code?
Be like, here's my unit test.
You know, I built some Python three stuff and it ran like, okay, let's land it.
You know, and then, then the thing that would happen is like the next week, somebody would
have committed some other Python two only code and you're just like, Oh God, this is never
ending.
Yeah.
So you talked a little bit about one of the challenges is you've got to convert the libraries
you depend upon that are internal Facebook libraries to be two and three compatible.
Yeah.
And then you also talked about like this regression problem, like constantly challenges you.
I guess that wasn't until the next year, but that was a problem, right?
Like you would, you would make your stuff work.
And then somebody would change a base library that wouldn't work.
So in 2014, like 13, like people didn't care about Python three.
So like, they knew that we've kind of, like, we kind of said that it's probably the future.
We should move to it.
Like, I think people all kind of had this sense that eventually we'll have to move.
Like, if you want to Python three support, they would be like, well, we don't have the
roadmap for that.
Like, we don't have the manpower to work on that right now.
So you just go and fix it.
Right.
We can't stop for six weeks and like rewrite or six months and rewrite this.
Right.
Well, most libraries, it wasn't, it was like, it was a handful of things you would fix.
Yeah.
And then just like, oh, they're handling, it's like bytes and string doing wrong, but
you would fix it.
And people would, no, people aren't running against Python three, so they just break you.
So I figured out, it's like, well, you know, that's what I think I really got.
I really accepted the, the concept of unit test driven development was that when I went
out and fixed these things, I immediately inject that, I immediately put a test to make sure
they stayed fixed.
Yeah.
I'm not going to fix this again.
And that, that really stemmed the bleeding because when the next, when the next person
came to write a code against this library and change something, they would immediately break
my unit test.
They're like, oh, well, let me fix this.
Right.
Yeah.
So that's one of the things that you talked about is basically, instead of you playing
whack-a-mole and constantly chasing these problems around, you, you sort of found a way to get
the build to work better.
And somehow you managed to get the build system to, to verify Python three behavior without really
the authority, just kind of like, yeah, this is for code quality.
We're going to do this as well.
And people are like, okay, great.
Yeah.
So we had like, everybody knows about flake eight.
It lints your code and it, you can run, like we already had a PEP 8 linter.
We actually had our, you know, we were kind of organized.
We actually made sure that all of our Python code kind of looked the same.
We would hit, pepe.
People may not, but argue, heck, how do I fix this?
But, to make the campaign happy, but some various teams would just run their own linters.
And I noticed myself, I would commit code and maybe like I had to fix something during code
review and I forgot to run the linter on it and it would make it into, into production.
And it would break a test immediately because it was like a syntax error or something silly.
And, you're like, oh, it's so stupid.
How did I miss this?
I was like, well, we're not running linters automatically, but there are linters rather than language like
PHP or P bus plot.
There's no space that these linters that ran.
I was like, well, like we're using fabricator, which is this open source code review tool.
And it had a thing to tie into, flake eight.
So I, I went ahead and set it up and I was like, well, if I can run flake eight under Python three and under Python two,
I would know if people, if I made like an obvious break to two or three.
And I did that and it was probably, it was really hell for a while for a lot of people.
Cause you were getting double the amount of flint warnings in your code review.
You'd get them for both two and three.
And I spent a lot of time to tell people it's like, okay, explain to people what's going on and why they shouldn't go secretly disable my linter.
And, because it was like, this will make our code better quality and people like, they were already running these linters.
They were like, oh yeah, this is great.
Can we actually make them to do?
Woo gosh, did that.
And that was, that didn't happen to like 2016.
I don't think.
But right.
And now you're almost to the point where you do it by turning off the version two one.
Well, no, like I think, well, gosh, basically if the messages were the same, he didn't print it.
They're like, he didn't print the version.
He said, pie flakes.
This is the message kind of thing.
Yeah.
So another thing that you talked about doing is using the dunder future module to at least stop writing only Python two code, right?
Like you imported the print function and division and so on.
But this was like one of the early, early things, even when there was not actually a path, right?
Yeah.
We had a linter, someone, he wanted to prolong the use of his two eight.
He wanted to keep writing two eight and hopefully it live longer than he thought.
Like maybe we switched to three and like the next year.
He didn't really know, but he wanted to, he wanted Python two to behave more like three.
And that was pretty wise actually.
And that got us very far at Facebook.
And he set up a linter to force everybody to do it.
And it caused a lot of pain at the time, but people just fixed.
Like if you make it like this, like a commit hook or something, people just try to make it happy.
And if they can't make it happy, then they complain.
That's pretty interesting.
Yeah.
There was no real message from on high to say we're using Python three.
But when the linter says, oh, this doesn't work right because of Python three.
Well, all right, we'll just fix that.
Yeah.
It's like, oh, why, why does my import not work?
Oh, well you're using, you can't use these relative imports without being explicitly relative.
And yeah, it took a while.
The Unicode literals thing probably ate up a lot of time, but we solved that back in like Python two.
And people internalized it.
It's like, if you wrote good Python two, you were using the future imports.
Right.
Yeah.
That's really cool.
Another thing you did back in 2012, sorry, 2014, when this was kind of a still just a little micro project was in the build system or just all the environments.
You made sure that six and two to three were sort of omnipresent.
What was the story of that?
Well, we had these linters in place and people were always like, well, how do I fix this thing?
That would spend a ton of, a lot of churn on the message board was like, okay, I understand this is a problem, but how do I fix it?
And it's still working two and three.
And it was like, well, you can do this extra code or, hey, there's this thing, this module called six or this module called future that you can import.
And it does.
So, and people like, well, okay, so I have to go add this to my build dependencies.
And you're like, or they would get mad.
It's like, oh, it's not there automatically.
So it's like to make it easier to like lower that barrier.
I just, I tripped the system into injecting it to everybody's build configs so that your pecs that when it gets produced would have six and the future module.
That's really cool.
So that was, they could just do this code and then they have to change anything about their system.
It was like, it was just, that was the way you could write it.
It was like, it was part of the standard lib.
That's great.
Maybe for folks who don't necessarily have battle scars from the Python two days, tell them what six is.
So six is like the first link, the first library for converting two to three.
It allows you to do things that are completely different from either language.
Like if you're setting a meta class on a class, it's different.
Like the syntax is different, Python two and three.
So six provides you a decorator you can call that you can wrap your class with and it'll, it'll set the meta class.
And six has a thing where it like, cause there are modules that moved between two and three.
And six has a thing where you can import from a certain move location.
And there was also this thing called Python.
It's called the future module.
From that, you can, it's, it's kind of like six, but it's a little different.
Sometimes it's, sometimes it's nicer code.
Sometimes it doesn't.
I use both.
So I don't have to force that decision on people.
You know, it's like, I just want to make people happy.
Give them all the tools.
All the tools.
You want a crescent wrench.
You want a socket wrench.
Whatever.
Just get it to run a load.
Before six, you would have to write these if statements where you would say like, if sys.version.
Or info, like, cause it's the main topic, like offset zero equals three.
You would do some code.
Like, this is a lot of garbage.
And six is like, oh, just say from six import pi three.
And you say, if pi three.
And you're like, oh, that's better.
You know, so.
Yeah, it's much better.
This portion of Talk Python to Me is brought to you by Rollbar.
Got a question for you.
Have you been outsourcing your bug discovery to your users?
Have you been making them send you bug reports?
You know, there's two problems with that.
You can't discover all the bugs this way.
And some users don't bother reporting bugs at all.
They just leave, sometimes forever.
The best software teams practice proactive error monitoring.
They detect all the errors in their production apps and services in real time and debug important errors in minutes or hours, sometimes before users even notice.
Teams from companies like Twilio, Instacart and CircleCI use Rollbar to do this.
With Rollbar, you get a real-time feed of all the errors so you know exactly what's broken in production.
And Rollbar automatically collects all the relevant data and metadata you need to debug the errors so you don't have to sift through logs.
If you're using Rollbar yet, they have a special offer for you and it's really awesome.
Sign up and install Rollbar at talkpython.fm/Rollbar.
And Rollbar will send you a $100 gift card to use at the Open Collective, where you can donate to any of the 900 plus projects listed under the Open Source Collective or to the Women Who Code organization.
Get notified of errors in real time and make a difference in open source.
Visit talkpython.fm/Rollbar today.
You had sort of summarized each year your thought about how likely this Python 3 world might be.
In 2013, you said, not going to work, not going to be a thing probably.
Yeah.
2014, you're like, highly unlikely.
So then one of the really interesting things that caught my attention about your talk was in 2015, you started getting involved with teaching Python at Facebook to new hires.
Yes.
Talk about that.
So, yeah, we had this class because we've already talked about we have this kind of complicated environment we build.
We have the PEC system, the fake zip file with the binary on top of it.
And we have all the C++ that's compiled in with you.
And we have a whole process for getting external libraries into it so it can be linked with those C++.
There's a lot.
And coming with just an open source knowledge of Python, you would be lost.
So we have this class that all boot campers, at least for touch engineering, can learn about Python and learn, hopefully get rid of all these roadblocks so that they can hit the ground and just produce some Python code that does some more work.
Here's what Python at Facebook looks like.
Here's how you work with our infrastructure from Python.
Stuff like that, right?
Because that's where they're going to learn that, right?
Yeah, we'd warn them about the linter.
They'd be like, oh, yeah, the linter's going to hit you.
And this is how you fix it.
Like, we talk about the four futures.
And that was already in there when I started teaching classes.
Like, what if we start teaching people that we expect them to write Python 3?
And secretly, that was my secret.
Because it wasn't really true.
But the new hires didn't know that.
Right.
And it was feasible.
Yeah.
Like, they could write Python 3 at this point.
You'd done enough work to get the infrastructure in place.
So it would work.
Yeah.
So it's like we say, oh, you're expected to write Python 3.
And if you have any issues, feel free to fix them yourself if you can.
Otherwise, reach out to us.
And it was like there was like a couple friends, friends of Python 3.
That was like a secret group that we were trying to push it forward at this point.
That you could reach out to us and we'll help you.
Or post in the message board.
And we'll help you with your problem.
That's awesome.
We were gathering like a wiki.
Yeah.
And to be clear, when you say if you run into a problem, just fix it.
That isn't with your code necessarily.
That's like you try to use one of the libraries.
It doesn't work in Python 3.
Well, you're expected to go kind of try to make that dependency that we have work in Python 3.
And just get them to sort of own the foundation of all the Python, right?
Yeah.
At Facebook, there's this saying.
It's like nothing is nobody else's problem.
Or it's not something along those lines.
But it's like there's this mentality that something's broken.
You don't just immediately go and find out, oh, well, who owns this code?
I'm going to go complain.
Like, no.
See if you can fix it.
Because if you fix it within like five minutes, you'll be ahead of your schedule if you had to go and like track down a person.
And like complain to them and get them to release something on their schedule.
You can just fix it.
Put up a little diff and keep working.
And if we taught people to just do that, like we kind of were tricking them to do work for us.
Yeah.
Yeah, there's a lot of lessons of sort of distributed responsibility, distributed work in here through the linters and through this education component.
And it more or less worked, right?
People started writing Python 3 code.
Yeah, they would join their teams after boot camp.
And they would say, hey, how come we're not using Python 3?
And the people there, they didn't have a good answer.
And the new people would start writing Python 3.
And so, like all these teams started coming out with like, hey, we're putting out Python 3 for our new project.
Because that's all the new people want to write.
I think that's great.
So, 2015, you dubbed the year of maybe.
Maybe it's going to work.
Starting to look good.
And then 2016, something pretty major happened with Instagram.
Instagram is one of or not the biggest Django deployment.
And they actually did a whole keynote about their move to Python 3.
But that was a big deal, right?
Yes, that was huge.
The thing was like, well, Instagram was Python 2 at the time.
And it was like, do we, does Instagram stay on Python 2?
And we were, it was like me and Lukash Longa were like, he really fought hard for us.
Like, no, you guys have to move to Python 3.
And if you don't move to Python 3, you should just give up the ghost and go to PHP.
And they're like, whoa, whoa, whoa.
They're like, just a second.
We can find it.
Actually, you know, it's at Facebook.
That's a good sound business argument to say.
It's like, you should probably use PHP.
We've invested a lot of money in that.
And it runs like the biggest website in the world.
Like, I think that makes sense.
And they're like, oh, let's just stay with Python.
You know, we don't want to like lose all of our developers.
Yeah, that's really interesting.
There was a keynote, I think, at the 2016, 2017, PyCon, about this.
And it was really, really just such a step-by-step practical way for large organizations to move.
Because it wasn't just Instagram upgraded to Python 3.
They also changed Django, major Django versions.
And they did all of that without branching in production.
Yeah.
Right?
Like, that is just incredible.
It talks to the power of tests as well.
Like, this is all unit test-driven, where they would take a test and they would make it work on Python 3.
Or like, change the code enough to where it would still pass on 2 and 3.
Right.
And I don't know how they did Django.
That was like, that's crazy.
That's another level.
But I think it also involves unit tests.
It must have, right?
But still, that's impressive.
Without branching in production.
Yeah.
That's crazy.
That's really super impressive.
And every time I hear someone say, oh, we can't move to Python 3.
Or it's totally unpractical.
Yeah.
We're too big to move to Python 3.
Yeah.
It's like, well, here's a roadmap and a pretty insane example.
You know, the rest of the stuff is not as visible what you're working on because it's infrastructure level.
But still, you know, also impressive.
Another thing that you said happened around 2016 is it became Python 3 by default.
What does that mean?
Whenever you would, like I talked about their build system, and you had a little script that you would tell it, oh, these are the third party dependencies I need.
These are the dependencies that someone at Facebook has written.
These are the C++ dependencies I need.
And it would, the build system, you would say build, and it would give you the little pecs that you could take to any system of Facebook and it would run your Python code.
That can fit if you just, like, copied what the wikis told you to do.
It would give you a Python 2 binary.
And we had been telling people in the class, a new hard class, that, oh, you should add this thing that says pi underscore version equals three.
And you'll get a Python 3.
And people are like, oh, why do I have to say that?
And we just say, oh, because two, two, I always do default.
It was like, there were so many people every day were saying, oh, we'll release this to Python 3.
That it was like, the only people that were still writing Python 2 code, they didn't have, they didn't really, they weren't like staunch Python 2 supporters.
They were just using the defaults.
So I had this like, well, what if we just switch the default, see if anybody cares?
And so I sent a message out like, hey, I'm going to switch the default to Python 3.
If you think this is a bad idea, say something.
And nobody said anything.
And people were all like, thumbs up, you know, I like this, this is good.
And so I did the switcheroo and I made everybody who's currently in Python 2 explicitly say that they're Python 2 and everybody's Python 3 get rid of their version line completely.
And it was just the default was the Python 3 version.
And nobody got broken.
There was no like major side outages.
It just, that was a very smart decision.
It was like, look, we were probably at like, probably less than 20%.
I think I have a graph somewhere in my talk where it was like, oh yeah, we were way less than 20%.
We were not even like 10, but it felt like we were really high because all the new stuff was coming out for Python 3.
Right.
And then this just, just flipped it, right?
All the people who were not setting things explicitly, they didn't care.
It just, it changed, changed the tide, right?
People who didn't care what version they're using.
They just wanted a version of Python that they could, you know, because as long as it wasn't C++, these guys were happy.
They just, you know, not having to, they didn't care and they weren't part of this fight.
So we just, whatever the default was, they're going to use it.
That's really excellent.
And a lot of the future work, right?
The import, the print function and stuff is kind of what made that work, right?
Oh yeah.
And like, yeah.
So like a lot of the existing modules of people who had already fixed all that future stuff,
some of them just imported fine into Python 3.
Right.
I mean, how often are you like doing crazy, like meta class stuff, right?
Like that's not that common.
More than we should is the case.
Everybody's like, I don't use meta class here.
Like maybe you shouldn't.
But yeah, it's like, I think in most of the major, like heavily used code paths had already
been cleaned up by like me or somebody else.
Cause if, if it's a, if it's a major use dependency, it's already been fixed for Python 3.
Cause by 2016, we already had a services in production, right?
Python 3.
Yeah.
That's great.
So one of the things I think is interesting, there's a quote that you talk about from one
of the engineers that sort of touches on this conception that Python 3 is slower.
And it says something to the effect of, we just did a very basic two to three on our service,
which means they ran the two to three program on the service to just automatically upgrade
it.
Everything just worked.
Now we're using half as much memory and it's 40% faster.
Yes, this is true.
That's a, that's a true quote.
I saw the, I think I may have stamped the diff as being approved and it was like simple.
Like it was just like changing the way they catch exceptions.
Right.
And, cause it's like, I think before it involved, I didn't remember at this point,
I've, I've, I've, I've, that's, that's just lost left on my head space, but it was like,
it was just basic things that you're like, Oh, that that's easy.
Like you didn't even need the tool to change it.
It was like, it wasn't, they didn't really have a lot of code that needed to be changed.
But, so it was like surprising.
There's like, Oh, that's all you changed.
And you, you're 40% faster.
Really?
Yeah.
Which speaks to the different runtime, right?
The different CPython.
Yeah.
And for a long time, Python three was a lot slower.
And I think still there might be some edge cases that are faster and Python two seven.
A lot of it probably has to do with strings, right?
Like the, the different behaviors around strings and bytes and all that stuff.
I think it's gotten faster and three six, like they, they, they really like pulled ahead
to use less memory and stuff with all the different fixes.
But I think that when that thing came out, people were still comparing.
It's like three, two and three, three.
And they just had, right.
That was their argument.
And they just hadn't actually updated their benchmarks to use new version.
Cause they'd already given up a little Python three.
And they're like, Oh, Python three is just too slow.
And then it's like, by the time three, five came out, I think that, or that might've
been out three, four.
But, it was like, it's kind of snuck up and be like, actually the core dev has been
working a lot to make this really fast.
And that work continues today, right?
Yes.
Yeah.
Python three seven bound function calls.
So function methods basically are 20% faster.
Oh, I can't wait.
In most cases.
Right.
Like, and that's just three, six to three, seven.
This is great.
So yeah, it's, it's all good.
I'm hoping for next week.
If, if Lucas hears this, I'm hoping for next week.
Okay.
So you had deemed 2016 Python three by default.
That was good.
And then 27 is sort of overtaking Python two.
And one of the things you highlighted then that happened was now Instagram is running on
Python three.
It has access to this amazing new features that were locked, you know, blocked off like
asyncio and in the typing static, you know, type hints and all that stuff.
Right.
Yeah.
It's like, you can say it's like, Oh, you can use typing in Python two, but it's like
the types in top two or three are semantically different.
Like things that you can do in two, like you may have, they may have different types or
they may have the same type, but they're behave differently.
So it's like your type formation may not be the same between versions.
So we told them to hold off to the winter three.
Cause it just made, we'd have to double the work, but yeah.
Right.
And you don't have it like in the function.
You've got it like in, in doc string type format, right?
Which is not nearly as nice.
Yeah.
It's not as nice.
And or whatever.
Right.
Yeah.
And people want it to be in line.
They want it because if it's a comment, it's gonna like, it's not always going to be correct.
So at least with the type annotations, like you would know, like it would, it's like, Oh,
I changed the name of the import.
It's all going to go fix all the types.
But if it was a comment, you wouldn't know that until you decided to actually run the type
checker in the early days before we even had a type checker.
It was like, we're just putting these types for humans to read.
Yeah, exactly.
So one of the things that you said around this time is that working in Python was fun
again, right?
People were super excited about all the new stuff and the new capabilities and it just kind of
revitalized people's joy, right?
Yeah.
It's like, like, I guess because of the whole two, three problem, like people who were, who
were like fans of Python were like, they were really negative.
They're like, Python's dead.
You know, I guess kind of like the pearl is dead.
It kind of in, in their, in your mind though, if, if you're in your mind, you're not switching
to Python three.
It is dead.
Yeah.
For them.
Well, people have stopped working on this for, since 2008, right?
Like it's, it's just nothing is happening anymore.
But once you're over that hurdle, all of a sudden like, Oh, look, this pool is warm.
It's fun here.
So like all this for a while, it's like, let's go to go.
Let's rewrite everything and go.
And I guess if we had decided to do that, we would still be working on it for, till the
next four years.
But, luckily it's like, people were like, Oh wait, there's all this good stuff.
All this cool stuff in Python three, like Instagram found out with ACCO.
It's like, this is good stuff.
And people would convert just to have that stuff.
Yeah.
And I think that's the main argument now is there was so much that is inaccessible to Python
two.
That is so exciting and interesting these days.
It's just crazy to not just do the simple work to, to get onto that side where you have
that as an option.
Yeah.
And what I would tell people in my bootcamp, I was like, if you're going to write a library
for Python users, don't write Python two support for one, it's going to waste your time.
Cause it's just, it's extra load for you.
You have to make sure it works in both languages.
You won't be able to use the new stuff.
And yeah, I'm not telling them this, but it means that those Python two users will have
to move to three to use your new good stuff.
Yeah, absolutely.
And there's some realistic, reasonable examples for that.
Like the Django team talked about how they, they were able to drop a ton of code.
And the Jupyter team is a NumPy.
I can't remember, but some stuff talked about in the Python statement that we talked about
earlier.
There's significant amount of simpler code and not just less code, but really, truly simpler.
And they say that that helps bring on new people as contributors, right?
They don't have to figure out how to write it in two different languages, sort of versions.
They're like, there's one thing to write.
This is how you do it.
Oh yeah.
The compatibility layers in some of these modules were horrific.
You know, that's why a lot of people were angry.
It's like, because the languages were in certain low level cases, languages were different enough
that you would have something that would be simple.
A couple lines would turn into like 20 lines, you know?
So it worked in both languages.
Yeah.
Like, why can't I just type import this thing?
It's like, well, you see, you got to do the sign.
We decided to rename it.
Yeah.
Yeah, exactly.
I understand.
Okay.
So that was 2017.
And 2018, you have declared victory.
Is that right?
Yes.
Yeah.
At this point, we know what Python 3 has won at Facebook.
And I think it's won in the world.
Like, there's...
I don't think it...
Even like with Guido's retirement from the core team, I think it's a done deal.
You know, nobody is...
There's no strong figure for the Python 2 camp at this point.
Yeah.
I know there are plenty of people hanging on, but I think there's just so many reasons
to move now.
It's much harder to make that as a reasonable argument.
It's just like, well, I just haven't done it yet.
It's kind of a...
It's a hard place to be in.
It's like, oh, it's like, we're going to be in a debt thing.
And, you know, maybe somebody will take care of it.
That's not a good vision for your future.
If you're staking your entire project, somebody has a kind of their heart is going to take care
of.
Yeah.
It's really rough.
So let's talk about this tweet that Lukas Lenga had sent out.
And you had mentioned in your presentation, and it's a graph, like a performance graph of
an app that was written there on Python 2.7.
And then when it switched to Python 3.6, could you just give us the quick summary of that?
Like it's...
Yeah, I probably won't talk about it.
I don't know what this is, but...
Yeah, no, it's not super important.
Yeah.
We traveled to Dublin to help this team out.
We're with them for two weeks, just helping them fix some, like, issues because their code
was pretty old.
Like, it was older than my tenure at Facebook.
So, like, once at the end of the week, we switched, we fixed all their little problems.
They switched over and immediately saw this drastic drop in their memory usage.
There was some CPU.
Oh, wait, no, they had...
Oh, it was half the memory.
Oh, yeah.
It was just half as much memory.
Yeah.
It looks like four times improvement in CPU and half the memory.
So, 2x in memory.
Yeah.
They were just like...
We were just...
I think Wukash immediately copied the graph and tweeted it.
You know, it was just like, this is insane.
Yes, exactly.
And this goes back to what we were saying before.
Yeah, the world seemed to like it.
There's like 1,800 likes or something just like, yep.
This is the kind of stuff that people need to see because you can tell them, like, well,
it's better or whatever.
But it's a whole other thing to say, well, that fleet of servers can be one server that
you don't have a hard time maintaining anymore, right?
Yeah.
Like, that's a much stronger story.
And you don't have to do anything but just make it run here.
Yeah, so this means that they were able to get rid of machines.
Yeah.
Because they're not doing as much work anymore.
And that makes everybody happy.
That makes your bosses happy because they're not spending as much money, especially if you're
like a cloud deployment and you're paying for each one of those nodes that costs you
money.
And it's, yeah, it's like you were saying nobody was saying these things.
It's like there was just this common understanding that, oh, Python 3 is slower than Python 2.
And we had to, like, break that lie that was still just kind of floating out there.
And we, and Lukash, he's talked about this a lot, was that a lot of the, like, core people
that, like, I don't know core people, but, like, people that wrote, like, really hard problems
in Python who had solved, like, kind of the low level, they were very negative.
And it was because they were solving the really low level problems.
But it was like the average, like, Joe or Jane writing Python code.
They're never going to see those issues.
So that when, when somebody comes out and be like, oh, I wrote this, this database driver
and it was a pain to do for Python 3.
It's like they do a disservice to everybody who will never see those issues.
Right.
Because you're, almost no one is natively, deep down at the native network layer.
Yeah.
Except for people writing web frameworks or data access.
You know, like, there's a few folks.
And they take a bit of a beating, right?
But they're also highly respected folks because they're the head of these major web frameworks
or database projects.
And they're like, this was super hard.
This is the hardest thing I've done.
It's like, well, okay, that sucked and we're sorry.
But, like, that is not what it's going to be like for other people.
They still import your thing and call query and it's all good.
Exactly.
Yeah.
That's pretty interesting.
So, I think these graphs, you know, also the story around Instagram, right?
Like, Instagram as a whole was able to turn off servers, was able to use less memory.
Like, they went pretty deep into that in the keynote that they covered that as well.
So, one other thing that you talked about in the 2018 timeframe, which I guess is now,
is this end of life of Python 2 internally.
Like, we know about the Python 2 death clock.
At least it exists.
I don't know if everyone knows about it.
But we know that there's the official external deadline for Python 2 at January 1st, 2020.
But you've also internally announced a deadline for this, right?
Yeah.
We want to make sure that we don't want to push past January 1st.
So, next year is going to be the year that I go around and help kind of, like, go through
and, like, find out those people that are still stuck on 2.
And maybe they've been in a cave all these years and they haven't known that 3 is a thing.
But, or maybe the team just doesn't exist anymore.
The thing's just running on automation.
Because we're...
Why is that website still up?
It's, well, you know, sometimes some things are just written well enough and they have enough
automation around it to keep it up.
It's just, you know, you figure out that, oh, wait, there is no team supporting this.
You know, like, oh, wow.
That's a success story, right?
But, yeah, it's a challenge.
It auto-builds and auto-deploys every month and nobody touches it.
So, yeah, it's like, so I think we're already internally, we're well over 80% of the libraries
are all Python 3.
And I think we're well over 60-something for, like, actually all those PEXs.
Like, the amount of PEXs we ship or Python 3.
So, it was figured, like, well, how long do we want to support this thing?
Because we don't want to get into the situation where we're having to support Python 2 past
the death clock, the deadline at the end of life.
So...
You don't want to be in 2020 doing anything with...
Yeah, so we're telling people that...
Trying to keep it going.
By the end of 2019, at Facebook, we're going to want to make it impossible to ship new Python 2 code.
Just so it's like, it's got, there's got to be some cutoff at some point.
And we're still going to support things that were already written, I think,
until, like, I think we said we were giving people, like, you know, maybe until 2022.
But it's like, at that point, you won't even be able to run it anymore.
It's like, we're going to get Python 2, the actual run times off the servers.
We're going to get them off the, out of the compilers.
We're going to make sure it doesn't exist.
Yeah, all the PEXs, they won't work anymore, right?
Yeah.
They're missing their CPython.
If it's just something that has been built in, like, five years, people still use it,
and it somehow miraculously works, it will stop working.
Right.
And then there'll probably be a little bit of a scramble to patch that stuff up, make it work.
We're hoping we catch all that in 2019.
And I think we will.
Yeah.
Yeah, yeah.
You guys have a lot of automated builds and whatnot.
Yeah, we have a lot of automation that can tell us immediately.
If I say that, oh, people that said they want two are now getting three,
I'll immediately start getting test failures if it's not working.
Exactly.
Just a little reporting, I'll tell you all that.
Okay.
So, Jason, that's a super interesting story.
And I think it's a real success.
And one of the things I don't think we necessarily covered as well as you did in your talk here is just at no point along the way did some manager or organization come along and say to you, like, okay, make this happen.
It's just like you wanted to see this happen and you just started working cooperatively with these different teams until it became a thing, right?
Yeah, at some point, like this was in 2016, when Instagram was moving, it was kind of like, hey, maybe we need a team to help people move or help, like, Instagram.
We kind of escaped the bullet of being the team that helps you move from two to three.
Because we did that for Instagram.
We did it for a couple other people.
But we were like, no, let's be the team that stewards Python for the future.
It's like we want something more lofty than just being the converter, the converting janitors or something.
Right.
That's very much more lofty in the long term, right?
Yes.
Yeah.
Very nice.
So, I guess transitioning, like, this is what you guys did.
This is what you were able to sort of germinate within Facebook.
What would you say to other companies that are stuck on Python 2?
Well, I was saying if they're engineer-led, like Facebook, and there's a lot of – we're in this internet economy, and there's a lot of startups that are out there.
They're very much engineer-led.
The same model works.
You just basically, you know, you can go and attack it through code quality.
I was telling somebody, it's like, I didn't always work in the Bay Area and Silicon Valley and these startups.
I used to work what I used to call real corporations in consulting.
And it's like, there you've got a manager, and instead of convincing other engineers, you just convinced a manager.
And it was sometimes easier.
Right.
There's one person to convince, and if you win that battle, it's done.
Yeah.
Right.
It's coming from on high, and it's just said.
Yeah.
If you can attack it with, like, some of the things we talked about, it's being faster.
Maybe it's going to use less money.
Maybe we'll use less servers.
And you can give them the example of Instagram.
They were able to do it without slowing down.
They didn't stop releasing features to convert to Python 3.
They did it all in line.
Yeah.
I really think that Instagram example, I'm so glad they did it as a keynote with all the clear steps.
Because it's not just an inspiring example, but it's a step-by-step roadmap to how it happens.
Exactly.
It's very inspirational.
So I guess, you know, this is a five-year journey, more or less.
What was easier than you expected, and what was harder?
There were several times where I made prognostications that were completely wrong.
Like, I thought that we would always have Python 2 as, like, the default, and we would still be a French thing.
But it's like, we quickly overtook Python 2 faster than we thought.
Like, I remember we actually had a message in our internal, like, IRC, like, hey, when Python 3 gets to 29%, let's have a party.
And, like, I just noticed it.
Nobody, like, had seen it for a while.
I noticed, like, oh, wait a minute.
We're at, like, 80.
Wow.
So I updated the messages.
Have a party.
We have, like, 90%.
There you go.
Yeah, and that's really something to celebrate, right?
Like, you're pretty much there at that point.
Yeah, so I definitely think we're going to have an internal funeral for Python 2.
And I've already, I was like, oh, no, we'll get, we'll, I was like, we'll get something, we'll make it look like a casket.
And have people talk about the good things that Python 2 did.
And we'll get rid of it.
Python 2 got us to where we are today, right?
Like, it was a major part of that journey, so.
Yeah, we can acknowledge it.
We just don't have to be stuck there.
Exactly.
What was harder?
You didn't actually expect it to work that well.
It sounds like in the early days, you're kind of like, this is a great try, but I'm not so sure it's going to work.
So maybe you just, you saw it as hard, and it actually wasn't, but.
Yeah, it wasn't as hard as I thought it was going to be.
Like, there's still the long tail of stuff.
Like, you know, we're getting to smaller, smaller values.
And I think it's just because we have, like, you know, in every company, you get more, as the company grows, you have more people writing code.
If that code is Python 3, your percentages of two just get pushed down automatically.
Right.
So I think that that is the, so the hardest thing is just to convince teams that, like, give them the, like, there are teams that say they want to move.
Like, everybody has the, like, oh, we want to move.
We just don't have the manpower.
We don't have it on a roadmap to move.
And they have it now because we've said, hey, it's 2019's the year.
You have to do it now or never.
It's going to stop running.
It's going to be a problem.
So that is probably, it's like, there are, yeah.
So it's just, there's some teams that feel hopeless.
Yeah, I can imagine.
It's like, kind of like what I thought.
Yeah, do you have companies that you acquire that bring, like, new Python 2 as another challenge every now and then?
Or does that not happen too much?
I don't know if I'm sure you can talk about that.
But then, like, sure, there's got to be some things.
But I think we kind of, like, there's enough people internally that, like, I guess when you're a good leader, like, and people don't know you're a leader, is that when they start repeating the same arguments that you were giving years ago, it's like coming out of their mouths instead of your own mouth.
I think, you know, you've won.
So it's like these people show up, like, hey, I've got this Python 2 app.
It's not working the way I want it to.
And what's the first from some random person I've never even met?
I'll get some things like, why don't you switch to three?
It has a defect.
Let's fix it.
Yeah, it's like switch to three and then we can help you.
Nobody knows how to do two anymore.
Yeah, yeah, that's great.
It's great.
I like it.
I mean, more organizations should be here.
All right, so I want to get your thought on one final thing and give a quick shout out to something that could help people as well.
So the same guy that put together, was involved in putting together the Sunsetting Python 2 support, the Python 3 statement, started calling Python 2 legacy Python.
Oh, I do like that.
Python 3 modern or just straight Python.
There's Python and then there's legacy Python.
And so the question is, Noah.
We do that internally.
You like this idea?
Yes, we call it legacy Python.
I love it.
I do too.
I have actually used that to identify other things I'm trying to sunset.
That's beautiful.
And I think when you spoke about talking to managers, like if you go to a manager and you say like, look, our entire infrastructure, our entire system is built on this legacy thing that's going to be unsupported in a year.
Like they're like, whoa, whoa, whoa.
That's scary.
That sounds horrible.
We got to fix this, right?
Yeah.
Like if you say Python 2 versus Python 3, you're like, ah, techno mumbo jumbo, leave me alone, right?
But legacy, they know that's bad.
They don't want that.
Yeah.
It's like sometimes we took jabs at Python 2 staunch supporters.
We would just to like make like we would call them blood heights because they didn't like the future.
They didn't like new technology.
So we were like, hey, are you like, are you like, is that how you got to work today?
Exactly.
Like how do you power that computer, right?
Yeah.
Plug it in or you got to puddle the thing or what?
It's like seeing your soul machine base.
Exactly.
Interesting.
Cool.
I'm glad.
That's definitely something I'm trying to push on the community as well.
And I think it's, I think it's resonates with people mostly.
All right.
So then a quick shout out, friend of the show, Anthony Shaw, wrote a cool course on converting from Python 2 to Python 3 over a Pluralsight.
So people should check out his course as well if they want to go along.
But certainly they should check out the keynote at PyCon 2016 or 2017 from Instagram because that really is a, you know, this is the roadmap of how you do it.
2017.
Thanks.
Yeah.
So that's a great one.
All right.
Well, we could talk for a long time, but I want to be respectful of your time.
So we'll just leave it here, I guess.
So I'll ask you two quick questions before we get out of here.
First of all, if you're going to write some Python code, what editor do you use?
Well, I'm Nuclide.
So Adam.
Okay.
The editor.
But it's with Fim mode because I still use a lot of Fim.
And, but if I, if I used to be a real big fan of PyCharm, it's just setting it up all the time was kind of a, it takes a lot of time.
So I always use Adam.
Adam's quicker.
Yep.
All right.
Cool.
And then a notable PyPI package.
Maybe not the most popular one, but something you're like, oh, people should know about this.
Wow.
Let's see.
Click.
All right.
Tell people quickly about it.
What's the, what's the elevator pitch on click?
Well, like internally people write these, they, they want to write these nice, like get style applications that are these sub commands.
And the.
Get add dot.
Get.
Yes.
Exactly.
That kind of stuff.
Right.
Uh, the art parse or opt parse to make that happen is horrendous and it's disgusting.
And people have written modules around these things to make it.
And all of them are awful.
And, and it was like, I was like, look, this is this thing.
I wrote, I used click for one of my projects.
I think the project that was the first Python three project used it.
I was so happy with it.
I just kept telling people you have to use this thing because it means that somebody I get off the street, who's been programming Python and open source, that it will feel natural for them to write an application with us without having to use some internal like CLI parsing.
Yeah.
That's really great.
Yeah.
It's definitely one of the most popular ways to build CLI apps, which is, you know, quite a few of the Python ones.
So very cool.
All right, Jason.
So people are excited.
They want to take their organization on the same journey.
What's the final call to action?
Like, what do they need to do?
You just got to set up, set some goals, set a plan, like, like, you know, demand in the future.
Like, look, we're going to be, we're going to go to Python three.
We're not just going to stay there.
We're like, that's, this is a stop.
We're going to go to, we're going to, it's a stop over to Python three seven.
It's a stop over to Python three eight.
We want to be modern so that when the new things happen, we can move with them.
Yeah.
And they're happening fast.
Exactly.
And they're happening in large numbers.
So you definitely want to be there.
All right.
Thank you so much for sharing the story.
I think it's going to inspire a lot of folks to take some action.
Yeah, I think so.
It's been fun.
Yeah, it sure has.
Nice chat with you and goodbye.
Bye.
This has been another episode of Talk Python to Me.
On this episode, our guest was Jason Fried, and it's been brought to you by Linode and Rollbar.
Linode is bulletproof hosting for whatever you're building with Python.
Get four months free at talkpython.fm/Linode.
That's L-I-N-O-D-E.
Rollbar takes the pain out of errors.
They give you the context and insight you need to quickly locate and fix errors that might have gone unnoticed until your users complained, of course.
Track a ridiculous number of errors for free as Talk Python to Me listeners at talkpython.fm/rollbar.
Want to level up your Python?
If you're just getting started, try my Python jumpstart by building 10 apps or our brand new 100 days of code in Python.
And if you're interested in more than one course, be sure to check out the Everything Bundle.
It's like a subscription that never expires.
Be sure to subscribe to the show.
Open your favorite podcatcher and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes, Google Play feed at /play, and direct RSS feed at /rss on talkpython.fm.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Now get out there and write some Python code.
I'll see you next time.
Thank you.