#155: Practical steps for moving to Python 3 Transcript
00:00 Michael Kennedy: Since 2008 there's been this tension in Python where much of the effort to improve it has been focused on Python 3 and many of the developers were left stuck in Python 2 primarily because important packages were not yet Python 3 capable. We've moved into an era where most of the packages anyone is using are fully Python 3 enabled and many are Python 3 only, the latest Django framework for example. There are many carrots and a number of heavy sticks encouraging us all to move to Python 3, but what if you have a large code base that needs to be migrated? What are the concrete steps and the gotchas in this whole process? This week, we welcome back Anthony Shaw to the show. He just published a new course on migrating Python 2 code and he's here to share his tips with us. This is Talk Python to Me, Episode 155, recording February 13th, 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 @talkpython. This episode is sponsored by Linode and Rollbar. Please check out what they're offering during their segments. It really helps support the show. Before we get to the interview with Anthony, I just want to let you all know I recently published a brand new course at Talk Python Training called Eve: Building RESTful APIs with MongoDB and Flask. This course is written by Nicola Iarocci who was actually the very first guest on Talk Python. He's Episode 1. He also happens to be the creator and maintainer of the Eve framework. Eve is this framework that lets you take Flask and MongoDB and turn your collections into a RESTful API with validation, schema verification, permissions, all sorts of cool stuff. It's a powerful, powerful framework. The course is really well done by Nicola, check it out at training.talkpyhton.fm. Now, let's chat with Anthony about getting that Python 2 code out of here. Anthony, welcome to Talk Python.
02:18 Anthony Shaw: Hi Michael, how are you?
02:19 Michael Kennedy: Hey it's great to catch up with you, it's been a while.
02:21 Anthony Shaw: Yeah definitely, it's great to be on the show.
02:23 Michael Kennedy: Doing well and looking forward to this conversation. I think the time really has come for this whole conversation about like, why are we not on Python 3 and then maybe what are the actual concrete steps that'll help you go over the blockers.
02:38 Anthony Shaw: I think we keep talking about how it's been 10 years since Python 3 has been out and trying to like guilt some people to move across to Python 3, but it's really a bit more complicated than that so I'm looking forward to kind of diving into some detail.
02:51 Michael Kennedy: Yeah absolutely. So we had you on the panel show a while ago on contributing to open source and that was really, really great but I don't know that we got a chance to get your whole story and how you got into programming Python, so why don't you let us know.
03:04 Anthony Shaw: Yeah sure, so I got into programming at a really early age, I think I was 12, and I guess that probably would've been mid 90s, and in those days there was not really a free access to compilers and online knowledge and things like that so my programming experience is based off of boxes of software and floppy disks that I could get my hands on. I learned some pretty odd programming languages to start off with, one of those was dBase IV which is sort of an accounting programming language, and I tried to make a Robot Wars simulator in ASCII which is pretty challenging. So yeah, this kind of, as I evolved from there over the last 7 years I've been working in software teams in C# .NET and got into Python a few years ago. I was in Seattle, over the weekend I became pretty sick. I was stuck in my hotel and I decided to pick up a new programming language so I was contributing to the Apache Libcloud project which I've contributed a lot to actually over the last three years, and last year joined the Apache Software Foundation as a member which is great. Yeah just kind of fell in love with the Python language, the simplicity and the speed at which you can get something working and it still scales pretty well so that's great.
04:22 Michael Kennedy: Yeah, that's really interesting so you kind of healed yourself with Python.
04:25 Anthony Shaw: Yeah, definitely.
04:27 Michael Kennedy: You're really making me think back to when I was younger as well, when you used to get software tools literally in boxes. I think I remember going to the store and buying Visual C++ 1.52 and getting all the DVDs, like the six or seven DVDs and just flipping them in one after another. Those were the times right?
04:45 Anthony Shaw: Yeah, the best thing about the box was it always came with a manual, and as a kid I used to sit there and read the manual to understand everything the language could do and how it worked, and you know see who didn't want a copy of this particular language or Visual Studio and leveraging the books which is great. But nowadays we have the internet, so you wouldn't need that anymore.
05:06 Michael Kennedy: It's interesting, it's much more JIT style right? Like it used to be, here's the book, this thing contains everything so you can just go through it, right, you would never try to do that now because it's just too comprehensive. Pretty funny, okay well that's really cool and maybe tell people really quickly about Apache Libcloud, like that's a pretty big project, you've done a lot with it.
05:24 Anthony Shaw: Yeah sure, so it's a cloud obstruction library in Python. You've got some major cloud platforms like AWS, Azure, Google Cloud, and really what it does is it provides a common class and a common set of models in Python that you can connect to all these different cloud platforms and get lists of servers or your DNS records or your storage objects, and the responses you get back from the API will be consistent across all the different clouds. It's a great way of writing compatibility code essentially across different cloud platforms. We don't just support
05:59 Michael Kennedy: That's pretty cool.
06:01 Anthony Shaw: Yeah, it's about 50 different cloud platforms. There's some pretty niche, regional ones, especially there's like a great cloud platform in Switzerland, for example, that's really popular over there.
06:11 Michael Kennedy: Yeah that's really cool, so if you're going to do some sort of DevOps type thing you could say, write against Libcloud, spin up the servers and you could just point it at EC2, point at Azure or whatever right, and it just does it?
06:26 Anthony Shaw: It just does it, there's a lot of spoon bending under the covers, but it's a ... Yeah the APIs were never really consistent, and that's been on purpose really. They're trying to offer the full functionality of what their cloud can through the API, but also portability is not really in their best interests cause they want to kind of keep you locked into the platform.
06:45 Michael Kennedy: Yeah do you feel like the cloud is like, the next great lock in? Maybe even larger than say Windows and Mac?
06:52 Anthony Shaw: Absolutely and that's kind of really why I've been dedicated to the Libcloud project for the last few years. Even in my current job I guess I'm working pretty late hours most days and I'm just trying to find whatever time I can to keep contributing to it because I think it's really important, especially when I think back to how I learned programming, it was spending whatever pocket money I could on books and trying to find whatever software I could and assembling PCs out of old bits of hardware that nobody wanted so I could keep learning. And my concern is that if cloud becomes the way of running computing, and all of it costs money, then it's going to push out all these people who don't have access to cash like students, young people, people in areas or geographies where they don't necessarily have access to typically US dollars to pay for these cloud resources. Then also countries where network connectivity is not that great. I do a lot of work in Africa, for example, and there's some countries in Africa where their network connectivity can be pretty sporadic as well as the sort of power as well. That can cause all sorts of challenges, and yeah I really care about people having access to learn and run computing and I don't want them to be pushed out of that.
08:04 Michael Kennedy: This is a really cool project. You're like a cloud freedom fighter, keeping the cloud free for everyone, awesome. Maybe talk about what you do day to day. You have this kind of mission of teaching people, getting people into programming in Python on a grand scale, right?
08:19 Anthony Shaw: Yeah, no definitely. I'm basically head of talent development at a company called Dimension Data. It's a 30,000 people organization, operates in 50 countries, so pretty much all over the world and my role is to look after the skills of the people within the organizations. That can include lots of things. On the technology side, one of the big pushes we've been doing is to try and convince as many people as possible to learn Python. We're up to 4000 people now. Yeah and we've partnered with Talk Python Training, you're far too modest about the quality of those courses, they've been so popular. The Python Jump Start by building 10 Apps is the single most popular course we have within the whole company now and our learning management system.
09:04 Michael Kennedy: Thank you.
09:05 Anthony Shaw: Yeah and it's really cool to visit offices all over the globe and see the little Python logo popping up in all these different places, so it's been great.
09:13 Michael Kennedy: That's awesome. Why don't you talk just really quickly about how you got people to do this, because so many organizations whether it's Python, my classes, some other random class, they have problems of getting people to actually want to learn, to be excited about it and so on. You have a lot of cool gamification and sort of social aspects to it, right?
09:33 Anthony Shaw: The first bit is really about confidence and curiosity, so if you ask people, well how did you get into programming, there's always typically a story about how they were curious and how they explored things in an environment where it's quite safe, and I think people think of programming, I blame Hollywood, you know you see these whizzing zeros and ones going by on a green screen and they make it look complicated and it kind of puts people off cause they think that's maybe not something that's for me or that's going to be something I'm going to struggle with. The first thing you've got to do is build up people's confidence to just give it a try, and then put them in an environment where they can just learn the very basics and build them up from there. So that's really what we've been trying to do. First of all the course is super important, but then also encouraging people to sit with each other in offices and different places and just help each other and collaborate with each other, and work through some of the hurdles they might have. In different countries we've got different programs depending on what food is popular. South Africa for example we've got, there's a donut morning that runs every week. We have people get together and talk about their Python challenges and work through the course and things like that. Thailand, as an example, they have a challenge to do one of the apps in the jump start course every week and they have a little celebration every time someone finishes one of the apps. That's kind of why we're seeing so much popularity in Thailand, it's all about people really and getting them together and helping them learn so.
10:57 Michael Kennedy: Yeah that's awesome. Hopefully a lot of organizations can adopt something like that because that's a really big difference. I mean just think of a company of 30,000 people where they all have some capability to automate parts of their job, it could really make a big difference.
11:11 Anthony Shaw: Yeah, definitely. It's not that we're trying to make everyone developers, cause that's not what we need to do, it's the basic coding skills that's going to be a, almost like a requirement going into the future. So just as I can use Microsoft Outlook or Excel, that's kind of assumed when you go into a professional job nowadays, and I think programming, now that it's being taught in schools to pretty much all students in some countries, is going to be really useful, and especially in our space in technology. Everything is now software defined and automated and has APIs, so coding is now the new way of interacting with it, so people need to learn that.
11:48 Michael Kennedy: It's definitely a superpower, it's awesome that you're doing that. So speaking of courses, we were talking a while ago, you said, "Hey I'm working on this really cool course on moving from Python 2 to Python 3 and helping people with that." so I'm really excited that you built this, this is definitely something that should exist out there. Why don't you tell people quickly about your course and how they can get to it, then we'll get into the details of why and how.
12:09 Anthony Shaw: This is a course really talking about how to move from Python 2 to Python 3, and it goes through a whole range of things, some of which we'll talk about today. That's what changed, how should you move, how should you plan for the change, how to test it, a really kind of all the things that you'd need to know to move a library or an application from 2 to 3. It's a pretty big challenge, but I've tried to really break it down into small pieces so I think if you can break something down into small enough pieces and just start with the first one, then it really makes any problem a lot easier. So this will be a course that will be available on Pluralsight, so if you have a Pluralsight subscription if you're a professional developer, your company should have already provided you a Pluralsight account if you've asked, and if they haven't you should push them a bit harder, especially access to some of the top Python courses as well I'd say, really kind of lean on your employer to give you access to this stuff. So yeah, this will be out on Pluralsight, it's about two hours long, so it's not too bad you can watch it over maybe like a short afternoon or something and play with some of the examples.
13:10 Michael Kennedy: Yeah maybe you could even have people do something really awesome, kind of like what you're doing with some of your teams where you could literally get the entire team together and sit and experience the course like on a projector in a conference room in an afternoon, or maybe in the morning and the afternoon you go and actually start the conversion and plan that out, right that would be awesome.
13:30 Anthony Shaw: Yeah definitely. A lot of the stuff in that course is actually about having conversations with your team about how to move the application. I think I've kind of assumed that what you're trying to move to Python 3 is typically a medium to large application. If it was a simple script, it would be pretty straightforward, so yeah it's kind of assuming it's a large one and it's not just you working on the project. So yeah, I mean .
13:54 Michael Kennedy: If it's like 500 lines, you could just rewrite it, right it's not a big deal.
13:58 Anthony Shaw: Yeah exactly.
13:59 Michael Kennedy: But if it's Instagram with a million lines of code, if it's Dropbox, if it's Bank of America it is the essence of your product and hundreds of people work on it, that is an entirely different undertaking, right?
14:12 Anthony Shaw: Yeah definitely.
14:12 Michael Kennedy: For sure. Before we get into the details of sort of how. Three years ago it really felt to me like there was this debate of whether Python 2 or Python 3 was the right thing to do for your projects. It seems to me as if that's more or less settled in Python 3's favor, what do you think? Is that debate still worth having or is it kind of done?
14:36 Anthony Shaw: I'm still having the debate with people on different projects and things like that. I say, like I said earlier, it's been out for a decade but that's not really a fair statement. I mean 3.4 has been out for four years now, and I would say that's probably the first kind of really stable release of the three series, so we've really had the last four years to kind of work with Python 3 and some of the changes. Python 2.7 specifically is such a stable release of Python 2, that's it's been a real challenge for people I think to have a reason to move across. So Python 3.4 is as good as Python 2.7, there's a few more extra features, futures came out there, I think that asyncio library came in 3.4 so there's kind of like a couple of reasons to move but definitely with 3.5, 3.6, and now 3.7 there are lots of reasons to move across. So I think that's settled that part of the debate and then also we've got upcoming end of support for Python 2.7 which people are going to say, well it works fine, maybe if security holes and things like that come out in the future we can resolve them, but lots of people don't actually realize there are existing holes in Python 2.7, in the XML modules for example there are some pretty well documented flaws in some of the temp file standard library modules there are some security holes so this is going to happen that there are reasons to move across to Python 3 from a security point of view. But then also I don't think we should keep trying to divide the community because we've seen time and time again in other languages like Perl 5 to 6 for example, .NET is going through it at the moment moving to .NET Core, where they're kind of, there's been a huge overhaul trying to fix all the big issues that they had in the old version and it's kind of separating the community until they can all agree to move forward and get on with the new.
16:28 Michael Kennedy: I think that's a really going point and one of the major frustrations and challenges of that I think is, you mentioned the .NET Core stuff I think you see it there, you certainly see it with the core developers in Python, is that the people who create and maintain and improve Python are putting all of their energy and effort into Python 3 right, that's where the work is being done, and you're only going to get the benefit and realize all those things that they've added in terms of performance and memory and language features and everything if you make the jump, right?
17:03 Anthony Shaw: Yeah definitely.
17:04 Michael Kennedy: Yeah, so the sooner that gap is sort of over with and everybody's back focused on the same thing, I think it's really interesting. I was at PyCascades recently, a conference in Vancouver and Guido was there. He gave the keynote which was a retrospective on Python 3. He talked about why he felt there were challenges moving to Python 3, why this whole thing began. Right, obviously there's the benefits, but why, what could they have done to avoided this gap basically. It's a really interesting talk, I'll link to it in the show notes. One of them I think was interesting was basically under estimating the importance and significance of third party libraries. Right, so how do you think we're doing there, right. There's places you can go check and say, does my library support Python 3. For the popular ones on PyPI like what ones are converted an so on right?
17:54 Anthony Shaw: Yeah, I think we're definitely out there now. There's a few tools you can use to check for Python 3 compatibility for your modules. If you're pulling stuff from PyPI. But from what I checked last time, of the 200 most popular modules in PyPI, I think 95% of them are now compatible with Python 3. The ones which are leftover have Python 3 equivalents. I think for the big packages, we're pretty much done. It's kind of a lot of the really niche applications and a bit more obscure packages that have been a bit of a challenge. Yeah, there's definitely ways to upgrade third party packages if you can't find the original developer. Some of that has really been because people publish them and then say, oh I'm done with this and move onto something else and it never gets updated.
18:44 Michael Kennedy: Yeah, for sure. You actually wrote a nice article on like, I depend on a package that's Python 2. Now what, how do I fix this right?
18:50 Anthony Shaw: Yeah, I've had that issue many times. Where I've pulled in a package that only works in Python 2 and I've had to update it to 3. So that's kind of where some of my experience in writing this course has come from. It's been updating other peoples applications, but also maintaining some pretty big packages. Like Apache Libcloud which supports both 2 and 3, which is sort of the portability approach.
19:11 Michael Kennedy: Pretty interesting. Before we move on to the goodness in Python 3, I want to try to spread this concept a little farther in the community. I talked about it all the time with Brian Okken on Python Bytes. If you say there's Python 2 and there's Python 3, they kind of feel like, ehh there's these two things and their similar. But if we all start calling Python 3, just Python and Python 2, legacy Python. When we have these conversations with managers and stuff they're like, wait, our systems written in legacy Python. That doesn't sound good, what is that? You know hopefully that term resonates with people.
19:47 Anthony Shaw: Yeah, I think so. Yeah definitely, I mean some of the tools that I work with a lot is Ansible, SaltStack, StackStorm which are about infrastructure automation. All of those were written in Python 2 originally and they still primarily support Python 2.7. Needs a huge Codebases and they're all trying to go through the migration at the moment to Python 3. Yeah it's definitely, they're seeing, I think in the last 18 months I think there's been a big shift. People really starting to realize that this Python 3 thing isn't going to go anywhere. It's not going to go away, they're not going to go and say, you know what we made a big mistake, we're going to move back to Byte Strings instead of Unicode strings.
20:27 Michael Kennedy: Yeah, yeah exactly. Alright, so let's maybe a good place to talk about what you get by moving to Python 3. What's better, actually what are the trade offs, what's worse? Things like that.
20:37 Anthony Shaw: The most wide reaching shift is that Python 3 is faster and I put that in air quotes, not that you can see them. If you go on speed.python.org, they run a continuous speed test against all the different versions of python. And you can go and compare specific things between Python 2 and Python 3. You can even compare different versions, say like 3.5 versus 3.6. In pretty much all of the cases that I've used Python 3.5 and above is faster than Python 2.7. You will probably going to see a speed improvement in moving to Python 3. Then you've got the async and await support in asyncio. If you start to implement some of those features, you're definitely going to see a big speed improvement. That's a big shift.
21:27 Michael Kennedy: That could just completely unlock it. You know just one story on that. There was a guy who we talked about aiohttp client, which is a little like request, but let's you await. While you're wait on the server and do other requests. This guy was downloading a whole bunch of stuff off a server and it taking like a day or something really, really long. He switched from request to the async and await version and then his machine crashed because he ran out of memory going so fast. Then he had to like throttle a little bit, but it was like a minute versus a day. It was something really super dramatic like that. When you think about performance, it's never so simple as it's just always faster in this way or that. It could be, well there's this new algorithm or technique that unlocked that is so much better. That you shouldn't compare apples to apples, you should like the pick new shiny apple and compare that to the old. You know the old unpolished apple, I don't know what the metaphor is there. There's a bunch of great stuff in there and then you talked about performance in terms of like speed. There's also improved memory, right?
22:29 Anthony Shaw: Yeah definitely. There's been some significant improvements under the covers in Python 3, so even if you're just writing with Python 3, you'd never really see most of those changes. In the actually execution, they did a lot of work to clean up a lot of the C code and definitely a lot of the optimizations around how it handles memory consumption and garbage collection and things like that. I've definitely seen some big improvements. There's some more coming in 3.7 in terms of how you call methods which are part of a class instance. So that's going to get a bit of a speed improvement, about 20%. So yeah, there's lots of things coming and lots of reasons to move across.
23:06 Michael Kennedy: Yeah there's actually a lot of stuff still coming and I think it's interesting to, while we're on this performance bit is. I think this is around the 3.5 timeframe where the core developers were like, one of the actual things that we need to focus on, one of the features is actually performance. It's great that we have async and await, or type annotations or something like that. But if we can say your code uses half the memory or runs twice as fast, that will solve the Python 2-3 divide right there, right. They've actually been putting a lot of effort into 3.5, 3.6 and 3.7 around that goal.
23:42 Anthony Shaw: Yeah definitely and also Python 3 is kind of embraced iterators more in some of the built-ins. When you run filter for example or zip in Python 3, they will return a iterator instead of a list, which it would in Python 2. Now when you're working with dictionaries if you're calling keys, values, and items on the dictionary, it's going to return in a view. Which has a iterator built-in to it, where as in Python 2, that would be a list. Yeah, they definitely kind of embraced iterators a lot more in the built-in types and you'll get definitely memory, better memory consumption while using those.
24:17 Michael Kennedy: What's cool about that is, a lot of those is, you don't do anything. Your code just, you already were like for in, over in that keys or something. But now it just does it better. Really nice.
24:27 Anthony Shaw: Yeah, just don't modify the dictionary.
24:31 Michael Kennedy: Oh yeah, there's that. 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 server or file server, you'll get native SSDs on all the machines. And newly upgraded 200 gigabyte network, 24/7 friendly support even on holidays and a seven day money back guarantee. Do you need a little help with your infrastructure? They even offer professional services to help you get started with architecture, migrations and more. Get a dedicated server for free for the next four months, just visit talkpython.fm/linode. Let's talk a little bit about the carrots. You talked about the stick, Python 2 is going to go end of life in 2020. Just to put a date on it. It's unclear, have you heard anything about the actual day? I only know the year.
25:42 Anthony Shaw: I've heard it's PyCon, so it'd be PyCon 2020.
25:46 Michael Kennedy: It should be PyCon 2020, I hope they do that.
25:49 Anthony Shaw: I think there's going to be burning of the Source Code or something. We'll see what happens on the day.
25:53 Michael Kennedy: That would be a great party to celebrate what it has done for us and like a goodbye party basically. That'd be awesome. Alright, so that's the stick. If you don't move and there's a security vulnerability or something bad, you're in a bad place. And it's not just the runtime, it's not just Python. It's the stuff that you might depend upon on top of it that you haven't moved into that. Let's talk about the carrots, what are some of the good things you get from moving to Python 3. Other than the performance that you already talked about.
26:18 Anthony Shaw: Yeah, so there's a lot of work with async and await, it being introduced as new keywords. And anyone who's worked with C# before will definitely be familiar with our syntax. I think that's actually where it was inspired by, was from the C# language. This is really a way of making it a bit easier to, I guess, work with the synchronous programming and to specify a bit more upfront that your functions can be awaited on.
26:44 Michael Kennedy: Especially when you're waiting on something, like you're calling a web service or a database. Your code could be doing so much more while you're just waiting for that network response, right. This makes it drop dead simple.
26:54 Anthony Shaw: Yeah definitely. I think there's still a bit of confusion with async and await. You know we've not seen it that widely adopted because it really takes a bit of time to get around the concept. You can't just stick it in front of every method and expect your code to just run faster. It doesn't quite work like that.
27:09 Michael Kennedy: It's more about scalability, than it is about pure performance increase for a single request, right?
27:15 Anthony Shaw: Yeah definitely. And if you're working with REST APIs a lot which, in the modern world, is pretty typical. Then waiting for a response back from an API can keep your code hanging, essentially. This is a great way to kind of speed that up. Dictionaries have got a bit of an overhaul.
27:31 Michael Kennedy: Especially around microservices, right. If you're calling more, it's not just one thing. You're calling a bunch of little services. You could really clog that up, so this'll unlock it.
27:39 Anthony Shaw: Yeah definitely
27:40 Michael Kennedy: Yeah, dictionaries, go ahead.
27:41 Anthony Shaw: There's been a separation before between the order in which the dictionary keys have been set up. Based on how they were hashed. In the newer versions like Python 3.6, they will be ordered by default. However, you should not see that will always be the case. So while it's a great feature, you should probably still import from collections and get autodicts that way. The performance improvements are pretty great. Also there's the yield from keyword. If you're working with generators, iterator's a bit more than, you know you can leverage that to make sure that you don't have to exhaust the generator before you yield it back.
28:19 Michael Kennedy: It really makes that sort of consuming generators and passing them on, or the really good in recursive sorts of situation. Instead of looping over and yielding a different item, you just say, here's a generator, give me all the, you know, return all the stuff out of there. It's nice.
28:33 Anthony Shaw: Yeah, definitely. Type annotations is a great feature. There's some really interesting ways to work with type annotations. Data classes is coming out in 3.7, which heavily leverages type annotations. This is really a way of creating a class which represents a model of data, like the response you would get back from an API. You can actually say here are the types. If you're working with a good IDE, it's going to give you a lot of hinting as to what methods are going to be on the instance and how to leverage it. That's another great feature.
29:06 Michael Kennedy: Yeah, type annotations are really, really great. I was a little unsure what they would do to the language. Would they make it like C# or Java or something like that by, you know making you say the types everywhere. It's, I think a little sprinkling of them around is really working out quite nice in my experience. There's some really cool stuff that Facebook and the Instagram folks are doing with type annotations. When we were talking earlier about the third party packages that were not converted to Python 3, there was maybe a couple that you said well, these aren't converted, but there's Python 3 equivalents. But what I'm noticing a lot more recently, over the last year or so is things that are only available in Python 3. Really awesome third party libraries, you only get, right so it's kind of almost the reverse right. So if you don't move, you know the world is moving on without you. Some of those come to mind, you already mentioned the RESTful services. So there's API Star which is the new fangled thing from Tom Christie. He does Django REST Framework. This is like, it uses type annotations to inject parameters from the API and all sorts of really interesting stuff. There's Quart, which is a async and await enabled flask API compatible derivative. Maybe the biggest one of all is Django 2.
30:23 Anthony Shaw: Yeah, Django 2 is a great step forward I think in terms of getting people to move to Python 3. Even using Python 3, it's a default on their tutorials and stuff like that. Contributed a lot to the uptake. If you're looking at PyPI download stats. For some of the packages that I maintain or work with, you still see like a large number of people using Python 2. I guess the question is, do they know which version of Python they're consuming, or are they just running some commands in a shell and it's pulling in packages from somewhere else and they're not really questioning.
30:58 Michael Kennedy: I think that's a really interesting point and how much of that is continuous integration systems that happen to be set up to test on all the version of Python. So they also are pulling Python 2.7.
31:09 Anthony Shaw: Yeah definitely, and there's also still a challenge. I mean Django I think have stepped forward and said, you know from Django 2 we're just not going to support Python 2. If you do pip install Django from a Python 2 distribution, it will just give you an error. Unfortunately the error is not, this doesn't support Python 2. It's something really obscure.
31:29 Michael Kennedy: It seems like would be pretty easy to put in to setup.py for that package. Just go if version major is 2 or less, just raise this error, sorry wrong version. Or something right, but it doesn't matter. The fact that Django, all Django work going forward is focused on Python 3 only. Is going to make such a huge difference. Let them forget trying to write two different versions of code for everything that they're doing and they can just focus on the new features which is really good. You touched on data classes, but I know that everyone necessarily knows exactly what they are. Could you give us just like the quick summary, what those things are? There are 3.7 that come in soon.
32:05 Anthony Shaw: It's very similar to the attrs Project and this is, if you have a class in Python. Which only has really one purpose and that is to store some data to reflect on some data that you might have in a database, or in Mongo, or it gets responded from a REST API. So this will have a number of fields like ID and name and things like that. You want to store them in a object, so that you can write the fields and you can instantiate it in quickly. There's a lot of boilerplate code that you quickly have to write to do that sort of thing. If you use attrs, it definitely becomes a lot easier, but I can't think of how many times if it's a right class, with just a long list of init variables. Then just basically storing each one of those in the class instance. It basically gets rid of all that boilerplate for you and just automates it. So you declare a data class, you specify all the fields you want to have and then it implements dunder init for you, dunder repr, dunder str, dunder eq. It's got some great other features as well.
33:06 Michael Kennedy: You can make it immutable by saying its frozen, in which case it also implements dunder hash. Which actually can be kind of challenging to do. Pretty cool. These are all sorts of things that are in Python 3 only, right. We kind of have to wait for a little while because 3.7 is not yet out. We'll talk more about that in a bit, but maybe let's talk about some of the strategies of actually doing it. Okay, so people think they sound great, they're like awesome, data classes, I definitely want that. Async and await, I want that, but I have all this codes that's in Python 2. How do I move it, what are my strategies?
33:41 Anthony Shaw: In the course, the way I try to explain this problem is, so I live near the beach on the east coast of Australia. I went down to the beach and basically shot a series of photos of me jumping from one rock to another one with some water in the middle. What I was trying to illustrate is that you're on Python 2 and you're on solid ground and you want to move to Python 3. It's extremely tempting to just say, okay let's just go and rewrite the whole thing and jump from one side to the other. But the real challenge with that, I think is if it's a large application, then the amount of time you're going to spend suspended in midair where you application neither works in Python 2 of Python 3 could be quite a long period of time. If any customers come to you, or you need to make any changes to the codebase, whatever, during that time. It's going to be really challenging. You could go and create a separate branch of your application and just rewrite everything in Python 3. But definitely you're going to get also the temptation to go, well since we're rewriting in Python 3. Let's also go and rewrite everything in Microservices and use the latest design patterns and right. Before you know it, it's changed from a, let's just move to the newest version of Python to, let's re-engineer the whole application from scratch. If you've got a big enough team and big enough budget, then great, you know knock yourself out. I think a more realistic approach is to start to introduce Python 3 support in specific modules or parts of your application. This is kind of like the portability approach. Now you probably don't want to support Python 2 for very long after you've done the move. But it's a lot easier to introduce Python 3 support to a already working application. I think that's the most important thing is that your application today, or at least I hope it does, works. So you know really introducing Python 3 support piece by piece means that you can maintain a working application whilst moving to Python 3. That's going to be a lot easier to you know land with the managers.
35:43 Michael Kennedy: Yeah definitely, it to say our code or making it better eventually will be off of legacy by then. But at any moment we could ship it and it's just as we work with it, it gets closer and closer to that goal which is really awesome. I think one of the most insane stories, and saying insane in an awesome way stories of this. Is what Instagram was doing and they really documented this at PyCon 2017 with one of the keynotes there.
36:11 Anthony Shaw: Yeah, the Instagram story is amazing and I think it's a great case, you know to talk about the power of Python and the scalability of Python 3 as well. Whenever I hear someone say Python's not scalable, I just say, "Oh how many users do you have? Is it more than half a billion?" Well you probably don't have an issue.
36:28 Michael Kennedy: Exactly, what response time do you need, 6 milliseconds is not fast enough, right. I mean maybe, maybe very rarely. Yeah it's amazing. At PyCon 2017 Instagram, a couple of the engineers from there got up and they gave this really compelling presentation of they were on an old version of Django. I don't even think it was necessarily a Python 2.7, it was like a pretty old version of Python, it was definitely some variant of 2. They talked about how they moved all of Instagram over to Python 3 without taking down the site. Without creating a separate branch, and continuously shipping and running their program. So some of the techniques were things like we are going to make our code run on both Python 2 and 3, instead of just rewriting it. So we're just going to make it compatible with both, then they started running unit tests on both versions Python 2 and Python 3. They'd only deployed a production if it would pass them both. But for a long time production was Python 2. Then slowly they started like running production Python 3 versions, but only giving those to the internal people. Just slowly growing out, but it was really great. They did this major conversion, they didn't branch. They didn't like kill the momentum for awhile. It's pretty cool.
37:45 Anthony Shaw: Yeah I think it kind of goes back to some other examples. I think of Windows Vista as well as a great example of where to be cautious of reintroducing bugs that you solved decades ago. I remember the first time they released the beater. They say oh we've rewritten the TCP/IP stack from scratch and they'd actually re-implemented something called Ping of Death which is like a late 1980s security hole in the stack. You should definitely not dismiss a lot of the robustness of your old application. Which is why testing is so important in the migration story. You know as I talk about in the course, Python is a very, very dynamic language. You can pretty much overwrite anything, and all sorts of crazy things can happen at runtime. The better testing coverage and the more robust tests that you have, the easier it's going to be to move. Then also making sure that you don't reintroduce bugs that you've already solved. Which is why I'm more of a fan of the sort of gradual migration process, than the completing rewrite because I've concerned that you'd introduce bugs. Which you either didn't have before, or you'd already solved.
38:53 Michael Kennedy: Yeah there's always so, the temptation is right there, to just say we could rewrite this. We could do it better. That may be a great thing, but I would say like you pointed out before, separate that from the concept of moving to Python 3. Do the move and then think about restructuring of some part, if that makes sense. There's no reason to conflate them and make them both riskier.
39:15 Anthony Shaw: Yeah, definitely.
39:16 Michael Kennedy: Yeah. How about some of the tools that people might use. There's some linters and other things that might work right?
39:23 Anthony Shaw: Yeah so probably the easiest one to use is, when you're running Python. You can use the -3 flag. So if it's Python 2, you can use a -3 flag and it will actually give you warnings on the shell where you've used something which is not compatible in Python 3. That's kind of like the easiest way to doing things. You've also got some linters. If you're using Pylint as an example. If you're using Pylint from Python 2, it will only give you a linting warnings that are relevant to Python 2. If you're calling it from Python 3, it will give you newer warnings. Linters can be really useful in terms of understanding, or at least trying to guess what types certain variables are. Tox is a tool which I highly recommend. So let's say you already or at least I hope, you've got some sort of tests written in unittests or pytests or something like that. Basically just introducing tox, which isn't not actually that complicated, just pip install tox and then you can run tox-quickstart. It will just ask you a couple of questions about which Python versions you want to test. So tox basically, each time you run it, it will create a virtual environment for each version of Python and it will run your test suite for those different versions. If you just wanted to target--
40:38 Michael Kennedy: That's really cool.
40:39 Anthony Shaw: Yeah, it's fantastic. I think people have been a little bit put off because it takes longer to run the test suite on multiple versions. If you install a tool called detox, it will actually run the multiple versions in different threads. So it takes the same amount of time as it would just to run your normal test suite.
40:57 Michael Kennedy: Yeah, that's pretty cool actually. Detox, I love it. Yeah so the idea is you can basically have your continuous integration, or just your unittest execution, basically automatically run on all the versions that you check. It could even be things like PyPy right. It doesn't just have to be just Python 2 versus Python 3 and CPython.
41:17 Anthony Shaw: Yeah definitely. PyPy runs on a 2 equivalent syntax and then PyPy 3 has still been a bit of a challenge actually. We've had challenges in Pytest support, I'm not sure if they've fixed that yet with PyPy 3. It's been a bit of a thing to get over. So yeah I do caution people who are using PyPy and moving to PyPy 3. The supportability of the PyPI packages.
41:40 Michael Kennedy: Yeah that's definitely a little bit tricky. It sounds like you definitely recommend continuous integration.
41:45 Anthony Shaw: Yeah continuous integration, so start off simple. Which is just run your tests in Python 3 like, and another thing you can do is Python actually has a compileall method which is in the standard library. Which will go through a directory that you have, look at all the Python source files and try just to compile them all upfront. That's another handy trick you can use, just to check. Just to do a quick syns check of the syntax that you've got and make sure that you've not done anything blaringly obvious.
42:15 Michael Kennedy: Right because normally if you don't go down a certain execution path, you may not even interact with some of the files. They may be messed up, but you can sort of force Python to parse all the files and turn them into pyc's right?
42:27 Anthony Shaw: Yeah definitely and then and as you start to introduce unittesting, think about in particular the string change in Python 3. Which we'll probably talk about in a minute. And having more testing on your application for unicode strings. So that's definitely bring up some challenges in your existing code.
42:46 Michael Kennedy: This portion of Talk Python To Me is brought to you by Rollbar. One of the frustrating things about being a developer is dealing with errors, ehh relying on users for port errors, digging through log files trying to debug issues. Or getting millions of alerts just flooding your inbox and ruining your day. With Rollbar's full stack error monitoring, you get the context, insight and control you need to find and fix bugs faster. Adding Rollbar to your Python app is as easy as pip install rollbar. You can start tracking production errors and deployments in eight minutes or less. Are you considering self-hosting tools for security or compliance reasons? Then you should really check out Rollbar's Compliant SaaS option. Get advanced security features and meet compliance without the hassle of self-hosting. Including HIPPA, ISO 27001 Privacy Shield and more. They'd love to give you a demo. Give Rollbar a try today. Go to talkpython.fm/rollbar and check them out. Yeah when I hear people working with challenges in their code or problems that they have converting. Number 1 there's some package that I depend upon and it's not working. Number 2, is strings. It seems like that catches a lot of people. Especially if they're working at the network layer, where they're getting bytes off the network and then they want to do string like. It's really ultimately supposed to represent a string or something.
44:09 Anthony Shaw: Yeah I hugely this decision in Python 3 to change the core types. I think it was the right choice. Kind of going back to I guess, what changed? In Python 2 there's a type called string or str. I think people have used it for two different purposes. This has kind of come back to some of the issue, is a 8-bit string type. It just happens that the ASCII characters which are the English alphabet plus things like, you know, basically everything you would find on an American or an English keyboard. Fits in ASCII character set. Now that set because it doesn't have that many characters, fits inside 7 bits so you can use it as a way of transferring, sending strings. Which only include American/English characters. People would use the str type for text and also use it for binary data. If they were reading images as an example, you'd still use the str types. I think part of the issue has been that there was also a unicode type. If you were a really good citizen, you would try and use the unicode type. But it would introduce all these weird issues in Python 2. One of those issues is that Python 2 will try its hardest if you can catenate a string type and a unicode type. This is the byte string and the unicode string. It would basically try and convert the byte string to unicode, and then bring the two things together. Now what that leads to is runtime errors specific to the values that you have in the strings. This is kind of the achilles heel of Python 2's unicode support. Is that it just tries to basically run either a encode or a decode at runtime. Then if you've got specific values in the strings, then your whole application can just suddenly crash. So yeah that's been a big challenge.
46:06 Michael Kennedy: And it may well be another culture that you don't typically interact with, so it's a really hard edged case to catch, right. Mandarin or something like that, I would never type that into my program, but other people would. It would totally make sense to them right.
46:21 Anthony Shaw: The case I talk about in the course is the argument has always been, oh we don't need unicode because all of our customers use English. But there's been this new culture called emojis which is introducing unicode characters in everything. People want to put smiley faces and snakes in their display names or their profile names. Or put all sorts of weird things in their addresses. Actually I think the culture of unicode has actually pushed, or emojis, sorry has pushed forward people trying to think about unicode support. That's uncovered a lot of the challenges in Python 2. Really what they did in Python 3 is to make it a lot more explicit about binary data and text data. What was the unicode type in Python 2, is now the string type in Python 3. If you want to use binary data from reading and writing let's say images or network sockets, there's a new type called bytes. Those things are very, very different. If you have a string literal, so if you just say hello world in double quotes, or single quotes in Python 3. That will be a unicode string by default. I think that's caught a lot of people out. If you're just passing strings around your application, you probably won't see the difference, but if you're reading and writing from sockets or files, or interacting with which a lot of these return binary data. Then that's when you start to see these unicode encode errors and things like that.
47:49 Michael Kennedy: Yeah definitely right at the boundaries of your app, where stuff comes in and out. That's the danger zone. So one other tool I wanted to just throw out there of while you're on this topic is Mypy. Mypy's an optional static typing, linter typing for Python 2 and for Python 3. If you're going to move your code over, one thing you can do is you can add typing to it in the Python 2 style. To actually verify that it's working the way you think and everything. So when you do the switch, you can make sure for example, you haven't switched to strings for bytes or something weird like that. Alright, it's still all the same types that you were thinking about. This is a major project that Guido van Rossum's working on, so it's pretty significant.
48:33 Anthony Shaw: That sounds really useful. Another thing you can do is to think about when you've got strings in your code. Whether they're text or whether they're binary and I think if you just, instead of thinking about the actual types. If you think about the purpose of the string, then it's a lot easier to port across to Python 3.
48:50 Michael Kennedy: Yeah for sure. Do you want to talk about just some of the things that change, say the language level. So we talked about strings. There used to be longs, are there still longs?
49:00 Anthony Shaw: Long in Python 2 is very, very, very long number. You know almost infinitely long, depending on how much memory you have on the computer. Then int was a fixed length numeric type in Python 2. What they've actually done is they renamed the old long type to the int type and then the old int type is no more. If you ever refer to long in your code, then it will give you an error in Python 3. There's ways around that, you can use the future package and you can actually import the long type from there which just redirects to the new int type. That's a way of safeguarding. Also, if you're working with numbers and you're using the division operator. So, you know the forward slash. If you divided two integers in Python 2, it would return an integer. If you said 1 / 2 in Python 2, it would give you zero. In Python 3 the division operator will give you a floating point number back, if that's the actual result. Say if you do 1 / 2 in Python 3, it would give you 0.5, so that's another thing that catches a lot of people.
50:07 Michael Kennedy: That's got to be super subtle as well. If your saying do this division. Then if it equals zero, we'll do this, otherwise we'll do that. Of course, no no, not so much. We have a couple of tools that will go through and adjust some of the stuff, right?
50:20 Anthony Shaw: Yeah they can at least make it easier to expect the new behavior when you're running Python 2. I mentioned the future module, that definitely does that. So you can actually import the new behaviors of certain operators and types into Python 2 using packages like future.
50:37 Michael Kennedy: Have you done anything with 2to3, or Six. I know those are not set on purpose, but they're both sort of tools or packages to help you adjust.
50:46 Anthony Shaw: There's three ways of doing it, so there's the 2to3 application which comes with Python 3. It's maintained by the core team. That will do it's best to automatically make your code portable, executable in Python 3. I think when Python 3 initially came out, they said if you pip install our package and you want it to work in Python 3. Then inside setup.py, you could actually run 2to3 over the source code.
51:15 Michael Kennedy: That's pretty ambitious.
51:16 Anthony Shaw: Yeah, that's ambitious. And people pretty quickly realized it's actually not that straight forward. What I recommend to people is that you can use these tools to fix really mundane things, like the use of the print statement and changing it to a print function. You know, that's something that's not really, you're not really adding much value by doing it by hand. So 2to3 and then there's also two other tools called futurize and modernize. I'd actually recommend using futurize instead of 2to3. It bases itself on the future package and it has a lot of the logic that 2to3 has for fixing your code of Python 3. But it also has a number of other features, basically for catching common things that are going to cause issues with portability. If you install futurize and you run it over your Codebase, it was going to give you a bunch of changes that it wants to make. Those will be in the form of a patch file, so it's going to say I'm going to replace this line with that line. The biggest issue with those tools I think is that the code that it creates can be pretty messy. You know we talked about dictionaries earlier and how keys, values, and items now return views instead of lists in Python 3. So the way those tool will try and get around that is that whenever you call two items in a dictionary. It will wrap that in a list constructor. So the tool will add that for you and then if you do something in the same line to use another iterator, it will do it again. The code that it can create sometimes can be, eye watering ugly, and actually not what you intended.
52:52 Michael Kennedy: Yeah it could actually change the performance adversely as well.
52:55 Anthony Shaw: Absolutely, there's a reason that they moved to views and there was a reason that people were typically use inter items in Python 2. I kind of warn against that. All of these tools, 2to3, futurize and modernize. You can toggle which fixes, which is the name for the logic that changes the code, you want to use. What I recommend is when you install them, you run futurize -l and it will give you a list of all the fixes that you can use. Then test out different ones. See which ones you happy with and then explicitly turn them on, or explicitly disable the ones that you definitely don't want. I mentioned the dictionary one as an example. I'd be really cautious of that because it can introduce, you know some pretty ugly code and impact the performance. There's some others as well in terms of the way it handles the strings and tuples, which can introduce a bit of mess. The tools I think are good for starting off by fixing some of the really mundane replacements such as print statements.
53:54 Michael Kennedy: Yeah, like if you could just have that happen, that would be nice right.
53:58 Anthony Shaw: It's not going to completely move your application for you, so don't expect it to do that.
54:02 Michael Kennedy: Yeah, but it can do some of the low level work. Also brought up six, the package S-I-X. That's not a tool that you'd run that changes stuff, but it's like a package you can use to help create compatible code, right?
54:13 Anthony Shaw: Some of the big changes in Python 3 are on the core types. Let's say for example you've got some code which says is this variable that I've just received in my function a string? In Python 2 it could be a str type, or it could be unicode type. Both of those inherit from something called base string. You can say if this instance my variable basestring. That's doesn't work in Python 3 because basestring is no more. The string type and the byte type are very, very distinct. What six can do, is it basically just introduces a redirect. If you want to check if something is a string, you can say if this variable is instance of six.stringtypes, or six.numerictypes. Then it's a really simple module. It's only about 600 lines of code I think. I recommend that people actually read the source code. It's not magic, it's actually pretty straight forward. It's just a series of if statements that says if Python 3 do that, if Python 2 do this. It's pretty handy for the thing that you really want to avoid when you're doing portability is having lots of if it's Python 3, go and run this piece of code. If it's Python 2, go and run this piece of code. Because in the long term, that's going to be really hard to maintain. It's hard to read, it's hard to follow and it's going to introduce all these weird edge cases in your testing as well.
55:37 Michael Kennedy: Yeah, you definitely want to stay away from that if possible. Very cool. Let's sort of wrap this up a little bit and talk about maybe, what do you do after you've migrated, now what?
55:47 Anthony Shaw: After you've migrated, if you're doing the portability approach. Then you've got an application that works on 2 and 3. Then what I recommend you do is basically start dropping 2 support. The ways that you can do that is to remove some of the portability code that you have and then you can, if you're using Python 3 as your execution. In production basically, you're calling Python 3, not Python 2. Then you can start to use some of the new features. You can actually start to implement async and await and data classes. And f-strings, yeah f-strings are great.
56:18 Michael Kennedy: Yeah we haven't even talked about those and those are really, really awesome. Both from a performance and syntax perspective. One thing that I wanted to throw in here at the end is I can see as a challenge is like if you're writing some code that's going to go run on a server. Really the one that comes to mind is macOS because they ship with Python 2, but they don't ship with Python 3, right. If you're writing some code, you could say well I'm going to write it in Python 2 and just it'll work on the Mac with nothing. But if I write in Python 3, they've got to install Python and there's all these challenges. You can do things like use PyInstaller and package up an independent version of your app, right. Sort of make it easier to deploy anyway, but also get around some of those challenges right?
56:59 Anthony Shaw: If your in Python 3 support, which version of Python 3 you get with different Linux distributions as an example. It's kind of all over the place. So expecting that people have already installed Python 3 is then okay, which version is it? 3.4, 3.5 or 3.6?
57:14 Michael Kennedy: Yeah, exactly.
57:16 Anthony Shaw: Yeah, that's definitely been a challenge I think because 2.7s been out for so long. You can pretty much assume that people have already got 2.7 installed. But yeah if your package runs on 3, then you've got to figure that out as well.
57:28 Michael Kennedy: Yeah, I've accidentally taken down the I think training website, maybe the podcast website by using f-strings in a little side utility. It's not actually run by the website, but the web framework scans all the files to look for like views and stuff. It hit a f-string section and it couldn't start the web app. I a like, really? This is what takes it down because it was 3.5, not 3.6 or something silly like this. Yeah I guess it's still a modern challenge to some degree right?
57:55 Anthony Shaw: Definitely, there's still one thing I think which is missing at the moment. That's dropping support for Python 2 in a nice way for packages that you pushed to PyPI. I've got a number of packages that I maintain. I'd love to drop Python 2 support, but I want people who are still using Python 2 to use, to end up installing the version which still supported it. I think something we're still missing is, if you pip install some package and you don't pin the version. And it detects that you're running Python 2, it says, oh okay you want the legacy version, not the new version. And it installs the legacy version.
58:28 Michael Kennedy: That would be nice.
58:30 Anthony Shaw: So you can, Yeah I think that'd be really helpful to help people start to drop Python 2 support. Because at the moment if you know that 70% of your downloads are in Python 2, you still would have to kind of maintain both.
58:41 Michael Kennedy: Yeah and you don't necessarily want to do like a super hard break and say, we're going to rename the package, like request 3, or boto 3 or something like that.
58:49 Anthony Shaw: Yeah, definitely not.
58:50 Michael Kennedy: Don't want that. Alright, so maybe final thoughts. We have Python 3.7 coming out, already just recently came out in a Beta. We can start playing with things like data classes, right?
59:03 Anthony Shaw: I recommend people go and download the Beta and give Python 3.7 a go, try some of your existing code. The reason that it's in Beta is because they're asking people in the community to actually go and test it and give them feedback. If there's something that's not working quite right or you've somehow managed to find some bugs. Yeah, then definitely raise those. Now that Python's source code, CPython's source code anyway, is on GitHub, then you can work with pull requests and issues through a nice friendly interface.
59:31 Michael Kennedy: Yeah, I think the move to GitHub is really, actually we're going to see benefits from that for a long time. I think that's a big deal.
59:37 Anthony Shaw: Yeah definitely a huge deal.
59:38 Michael Kennedy: Yeah definitely. Alright Anthony, this is really, really insightful and thank you for sharing everything you put together on this course. People should check it out over on PluralSight, right? Will you give us a link to it?
59:48 Anthony Shaw: Yeah, definitely.
59:48 Michael Kennedy: Alright. I'll put that in the show notes, awesome. You going to be at PyCon in the U.S. 2018, Cleveland?
59:54 Anthony Shaw: Yes, I'm flying all the way from Aus, over to Cleveland.
59:58 Michael Kennedy: Half way around the world to come hang out with all of our Python friends right.
01:00:02 Anthony Shaw: Yeah that's going to be like a remake of 'Planes, Trains, and Automobiles,' so I'm quite looking forward to it.
01:00:06 Michael Kennedy: Yeah, very cool. I'm looking forward to that whole event as well. I don't think it's sold out yet, so people should definitely get their tickets because it's going to. Alright, let's do the final two questions before you get out of here. If you're going to right some Python code, what editor do you use?
01:00:19 Anthony Shaw: At the moment I'm using Visual Studio Code, it's kind of light weight enough. Not to take 10 minutes when I want to open it and it's got some more advanced features like it highlights all of my mistakes for me, which is nice.
01:00:31 Michael Kennedy: Yeah, very cool. It's definitely very cool with the Python plug-in which is now part of like the official team, right. They hired Don who working at that, that's also a cool story. We talked a lot about PyPI packages. Got one that is notable, you want to recommend to people that they maybe don't know of?
01:00:46 Anthony Shaw: Yeah, sure. I'm going to cheat since this is one of the one's that I maintain. If you're using documentation written in restructured text and you would love to use Read the docs, but the documentation that you want to publish is proprietary to your company and you have Atlassian confluence as a wiki. Then install Sphinx-Confluence builder and it will actually publish your sphinx output to your confluence for you.
01:01:12 Michael Kennedy: Oh wow, okay, very cool. Alright so, final call to action. People out there with Python 2 code, what do they do?
01:01:19 Anthony Shaw: People out there with Python 2 code. Start to run some linters, start to run some of the automated tools. See what you need to change first. Then introduce your test suite to Python 3. See what things you need to change and just keep working through the application. Follow the best practices, and of course watch the course.
01:01:36 Michael Kennedy: Right on. Alright well it was really great to catch up with you and thanks for being on the show again.
01:01:40 Anthony Shaw: Yeah, thanks very much Michael.
01:01:41 Michael Kennedy: Yep, bye. This has been another episode of Talk Python To Me. Today's guest was Anthony Shaw and this episode has 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 the insight you need to quickly locate and fix errors that might have gone unnoticed until your users complain of course. As Talk Python To Me listeners track a ridiculous number of errors for free at rollbar.com/talkpythontome. Are you or a colleague trying to learn Python. Have you tried books and videos that just left you bored by covering topics point by point? Well check out my online course Python Jumpstart by Building 10 Apps at talkpython.fm/course to experience a more engaging way to learn Python. And if you're looking for something a little more advanced, try my Write Pythonic Code course at talkpython.fm/pythonic. Be sure to subscribe to the show. Open your favorite podcatcher and search for Python, we should be right at the top. You can also find iTunes feed at /itunes, GooglePlay feed at /play, and direct RSS fee 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.