« Return to show page
Transcript for Episode #5:
Legacy Python vs Python and why words matter and Request's 5 Whys retrospective
00:00 Python Bytes Transcript
00:00 Episode #5: Legacy Python vs. Python and Why Words Matter and Request’s 5 Whys Retrospective
00:00 Michael KENNEDY: This is Python Bytes. Python headlines and news delivered directly to your earbuds. It’s Episode #5, recorded December 5, 2016.
00:00 This episode is brought to you by Rollbar. They take the pain out of errors.
00:00 This is Michael Kennedy, your co-host, along with Brian Okken. Hey Brian, how’s it going?
00:00 OKKEN: It’s going really good today.
00:00 KENNEDY: It’s another week of exciting news in the Python world.
00:00 OKKEN: Let’s get started right off the bat.
00:00 KENNEDY: Alright, tell me why.
00:00 OKKEN: (Laughing) Tell me why. Awesome. There was an article, “The 5 Whys of Requests 2.12.” I thought this was a great article because apparently in Version 2.12 that came out November 15th – they’re already up to 2.12.3 now on December 1st – but I think that they broke some people. There were some corner cases, non-standard ways to use requests that was supported before. There’s some reasons why they needed to change it. This is a good article. I think it’s put up to try to limit people from getting made first, so that they try to understand that the library supporter point-of-view why they made the changes. It was just really well-written.
00:00 KENNEDY: It is well-written and it gives you a look inside at how challenging it can be to software at this scale. Request itself is not a huge piece of software, right? Not like Django or something like this or Open Stack, one of these really big projects, but it’s used so incredibly widely. Request is downloaded 7 million times a month. Think about that.
00:00 OKKEN: Yeah, it may be one of the largest because of how it’s being used by everybody. Not large in size.
00:00 KENNEDY: Huge footprint.
00:00 The problem was the current release of Request, that is the 2.12 breaks anyone who uses a URL scheme, that’s the little part before the colon that is not http or https, where it used to sometimes sort of work. So, people were kind of tweaking that. It has to do with a bunch of stuff internally, right? There moving to different domain resolution things inside and so on.
00:00 OKKEN: Huh. Okay.
00:00 KENNEDY: Anyway, basically the article talks about how hard it is to maintain software. If you have software that’s used as widely as Request, there’s no part of it being touched. I think the takeaway was more or less, two things. One, make sure that your validation and error checks are a little extra picky. They said the root of the problem is that they kind of didn’t check strongly enough for these things initially, so stuff was able to work through. They said if you make your checks really rigid, it’s easy to roll them back but it’s very problematic to put them forward. The other takeaway was find a maintainer of your Open Source project that you love and give them a hug.
00:00 OKKEN: Definitely. It’s not an easy job.
00:00 KENNEDY: No, it’s not an easy job.
00:00 But speaking of people that I want to hug, there’s a guy that I had on the show on Talk Python a while ago, Matthias Bussonnier. He’s from the Jupyter project at UC (University of California) Berkeley’s Institute for Data Science and he works of Jupyter, IPython, Notebook, things like that. This article is not super new but I haven’t talked about it before. I really thought it was kind of timely again; it came back to be relevant. I think it’s going to continue to be relevant over the next few years. It’s more about a mental shift than it is about anything else. The article I want to talk about is called “Planning an Early Death for Python 2.” We had this whole Python 2/Python 3 deal over Thanksgiving break, that was last week, and we talked about that and so on. This is not so much about whether or not we should be teaching people new things, it’s about how we perceive and talk about Python 2 versus Python 3. I’ll just read you a little introduction. This is a workshop, they met at the Berkeley Institute for Data Science, a bunch of data science folks. So, they’re coming at it from that angle.
00:00 “Out of the discussion rose a topic that’s long plagued the Python community at large. Code that requires Legacy Python 2.7 is holding back the development of data science toolsets and by extension, the progress of data science as a whole.”
00:00 They convened this small working group to plan an early death of Python 2 or as they call it, Legacy Python. They came up with a few things that concretely they can do. I think the most important message here is to choose your words carefully. Instead of talking about Python 2 versus Python 3, talk about Python versus Legacy Python.
00:00 So, when you say Python and say, ‘I mean Python 3’ what would you be talking about, right? When you talk about Python 2 it’s Legacy Python.
00:00 “Refer to Legacy Python in the past tense to reinforce its old and deprecated state.”
00:00 “Make you examples and your documentations in Python 3 only.” So, if you’re doing something with Asynchrony, use Async in 08, key words, things like this.
00:00 “If a user sends you a bug to a library, ask them to reproduce it on an up-to-date version of Python.” And make sure, of course, when you have continuous integration that your tests run on Python 3 as well.
00:00 I really found this article interesting. It’s about the mentality of it. If people at conferences and people who write and maintain libraries start referring to Python 2 as Legacy Python, and they start calling Python 3 just Python, and they assume that’s the way the documentation is written, I think it would have a tremendous effect on the adoption of Python 3 over a couple of years. As people come into Python, as they come into these new libraries… If you start to hear, ‘This thing I’m using is called Legacy… Wait a minute, maybe I should stop using it.’
00:00 OKKEN: Yeah. I don’t know if they touch on this but one of the reasons why if you start out supporting Python 3, if you start out current Python and wanted to try help support older versions, it doesn’t add clarity to your code. You’ll have to not use some features that are new and awesome. That is problematic, to try to support old libraries and old versions of Python, you can’t use some of the new stuff.
00:00 KENNEDY: Yeah, I totally agree. It’s a really well-written article and I’m probably not doing it justice but I love the mental shift of ‘We have Python and we have Legacy Python.’
00:00 OKKEN: I even like the idea of, it’s totally okay to have some stuff that doesn’t support Python 2.7. If you don’t want to support it, it’s up to you.
00:00 KENNEDY: For example, the Bee Ware project, coming along. That’s a good example.
00:00 OKKEN: Oh, okay. They’re only on Python 3?
00:00 KENNEDY: Yeah, they’re on Python 3 for their code and Bee Ware is doing amazing stuff.
00:00 OKKEN: Interesting article called “Simplifying Complex Business Logic with Python’s Kanren.”
00:00 KENNEDY: That sounds cool. What’s Kanren?
00:00 OKKEN: I had never heard of it before I read this article. It’s a library that helps with some logic coding. I’m still going to have to play with it a bit. I’m still having a hard time getting my head around it. However, it looks like a lot of stuff that some people use. Traditionally people use spreadsheets for some of the data analysis stuff. It’s written such that I think it’s more readable than the data analysis stuff. It’s written more business friendly, I guess.
00:00 They have an example in the article; it’s a Simpsons example. If you give a data set with whose parent is who in “The Simpsons” and you call it a relation, it has a whole bunch of different things you can say. ‘This piece of data has a relation or a fact…’ There’s a couple things. You can have sets of data and ask it questions about the data. ‘Who’s a person that has two children in The Simpsons?’ or things like that. Basically, a different way to ask questions about your data as far as I can tell. A way to ask questions about your data that’s different than some of the other methods I’ve seen before. I like different ways to cut at different problems.
00:00 KENNEDY: It looks really cool. It looks knowledge-based; you set up all these facts and relationships between them. And then you can ask it all kinds of questions. I think it’s pretty awesome.
00:00 OKKEN: Yeah, I don’t know what type of problem I’d need it for, but another tool in your toolbelt.
00:00 KENNEDY: Yeah, tools are good.
00:00 Before we talk about the next set of tools, let me tell you about our sponsor Rollbar. Thank you, Rollbar. We’re really happy to have you guys on board.
00:00 OKKEN: Thank you.
00:00 KENNEDY: The Talk Python websites handle almost 2 million dynamic ACP requests per month and transfer 4 or 5 terabytes of data. And yet, I deploy them frequently. I don’t worry about whether they’re up and running, I have some basic server monitoring. And if anything goes wrong with the app, Rollbar’s going to send me detailed information to my slack, my email, all sorts of things. It comes with all sorts of info already there, so you can probably fix the problem before you even have to debug it. It’s great.
00:00 If you guys want to check out Rollbar, please go to Rollbar.com/pythonbytes and sign up for the free tier. You can plug it in in a few minutes.
00:00 OKKEN: Sounds awesome.
00:00 KENNEDY: Yeah, it’s awesome. I don’t hope you have errors, but you want to be sure when you do, it’s easy to solve them.
00:00 So, speaking of web apps running that are pretty cool… One of the larger implementations of Python is Reddit itself. Reddit is often referred to as the front page of the internet – maybe that’s Facebook these days, I don’t know. Reddit has definitely got a lot of traffic, that’s for sure. It’s built on some older Python technology; Pylons, Mako templates, custom non-OR versions. The core part of SQLAlchemy. I’m sure there’s tons of other stuff going on there as well.
00:00 There was this question of discussion on Reddit. If Reddit were written from scratch today, which Python web framework would it use and why?
00:00 I feel like the sense, when I talk to people and listen to what people are doing with web frameworks, it’s either Flask or Django, Flask or Django, Flask or Django. My stuff is built on Pyramid. I really like Pyramid. I think it’s a nice Goldilocks framework between the two I was mentioning. I thought it was interesting that a bunch of people came out and said, ‘Obviously, Pyramid is the right choice for this.’ I’ll give you a few sentences from what people said.
00:00 “I would say the most sane option would be Pyramid. Faster than Django in tests and it doesn’t repeat the mistakes with threadlocals that Pylons and Flask did in the past. I did some both small and medium to big – say 20 million plus – user web apps, and it just feels right. Doesn’t get in your way and give you magical solutions to your problems. It’s great.”
00:00 Another guy said: “Assume you’re talking about Reddit at its current scale. Not Flask, too many global variables and it’s not thread safe for Async. Not Django, too opinionated. Everything’s in-house for scaling reasons. My guess is Pyramid. In fact, that’s what Reddit current services are built.” They link to a GitHub. I think there’s a foundation in their services.
00:00 The takeaway around this discussion was that the web frameworks cause a lot of strong subjective split in opinion. I just thought it was really interesting to see a lot of people coming out with this Pyramid recommendation. I hear Flask versus Django so often.
00:00 OKKEN: Yeah, that’s often what I hear too. I saw this and it’s surprising to me but I enjoyed reading about it. It also prompted me to try to find some time to go through your course. Don’t you teach Pyramid in your course?
00:00 KENNEDY: Yeah, I do in my Python for Entrepreneurs course. It’s definitely Pyramid.
00:00 OKKEN: Next up, I’m going to bundle these. I’ve got two testing-related articles. I was tempted to have these be two different articles on this, but I didn’t want to take over the entire podcast on testing. There’s a “Getting Started with Pytest” from he goes by Jacobian, Jacob Kaplan-Moss. One of the things I like, it’s not silly. It’s a simple example but it’s also a real example using some things that are hard to visually tell whether some things are right or wrong. He also goes through and looks at test parameterization, which is very useful if you’re into testing.
00:00 The second article is “The Best New Feature in Unittest You Didn’t Know You Needed.” The feature that isn’t highlighted in the title is Subtest. Subtest was added in Python 3.4, but I haven’t seen very many people blog about it or talk about it. Like if you have a list of things that you’re testing a data test – a whole bunch of data points you’re checking for – normally if you just iterate through them, the first one that fails will stop your test. But Subtest is a way to say, I want all of these to be checked or everything that is in this loop.
00:00 KENNEDY: That is really cool because sometimes you create a Unittest and there’s so much, actually three separate sort of things I need to verify to actually verify this case. I can use Subtest for those, right?
00:00 OKKEN: Yeah. Using it, you can fail a part of it and that part of it will skip out and not continue but it will go on to the next Subtest. It’s a pretty cool thing. I know, since I’m a Pytest fan, you can run Unittest with Pytest, Unittest written test with Pytest. Pytest will run Subtests but it doesn’t highlight out the individual failures as Subtest does. That is one of the breaking, if you’re writing Unittests, that you want to run with a Pytest runner. Subtest might be something you might want to avoid. If you’re running in Pytest, you’d probably use parameterization anyway for the same problem.
00:00 KENNEDY: The last one here I have for us is just a fun one. Imagine you’re running a meet-up or conference or some kind of hackathon, and you want to have some music playing. Because, I don’t know about you, but the right kind of music along with coding is the perfect mix.
00:00 There’s this jukebox-type thing called PyTone. By no means is PyTone new, but I haven’t talked about it and people recommended it to me. Kidpixo who runs the Geek Cookies Italian developer podcast sent this over and said, ‘Hey, you guys should check this out, this is fun.’
00:00 Let me just give you a quick, little summary of this screenshot here. I’m going to set the stage. Under this screenshot here it says, “This is how PyTone 197 looks in action in an 80 by 25 terminal.” This is a terminal-based, iTunes-type of thing. Brian, what do you think of this?
00:00 OKKEN: Actually, I kind of like it a lot. It’s neat.
00:00 KENNEDY: It’s neat, right? Imagine you can project this on a screen during breaks while you have music playing. It’s really a terminal base, with progress bars and players, everything. A little music player. It’s cool.
00:00 OKKEN: Yeah, and it looks nerdy so, there’s that. (Laughing)
00:00 KENNEDY: Exactly, that’s why I said you should do it at a geek conference. It’d be perfect for that.
00:00 OKKEN: Yeah, also I think it’s neat to see a maintained Curses project.
00:00 KENNEDY: Yeah, it’s an interesting use of Curses as well, like if you want to build an interesting, more interactive, terminal-based GUI. I guess, it’s cool.
00:00 Alright, that’s it for our headlines this week. It’s been slightly less interesting than last week but nonetheless. A lot of cool stuff coming along, a lot of good news to share with you.
00:00 Brian, you got anything going on you want to tell everyone about?
00:00 OKKEN: Well, last week I was trying to get two episodes out of Testing Code and did. So, I’ve got Episode 25, talking about Selenium with Dave Hunt, and also Pytest, and working at working at Mozilla.
00:00 KENNEDY: Yeah, that was a good one.
00:00 OKKEN: And then (Episode) 26 was a new tool that I hadn’t heard of before called PyRest Test, and got the developer on to talk about that. It’s a Rest API testing framework that uses YAML to describe the tests. It’s pretty cool.
00:00 KENNEDY: How very cool. I’ll have to check that out. YAML seems to be coming along for all sorts of things around Rest. We’ve got it for Swagger, for automatic API documentation generation, and testing as well, it sounds like. That’s cool.
00:00 OKKEN: Yeah, my first reaction to the YAML stuff is why do we need something else. But it seems like it’s more human-readable than some of the other options.
00:00 KENNEDY: As long as we stay away from XML, I’m happy.
00:00 OKKEN: How about you? What’s going on?
00:00 KENNEDY: Not so much. Just working on the Entrepreneurs course that talked about. A couple hours of new content there. When we hang up here I can get a chance to upload it, organize it and all that.
00:00 Life’s good. Love working on all the Python projects I’ve got going on
00:00 OKKEN: Wonderful.
00:00 KENNEDY: Absolutely. Everyone thank you for listening. Brian, thanks for sharing the headlines with me. It’s been fun.
00:00 OKKEN: Thank you, it has been fun.
00:00 KENNEDY: Bye, everyone.
00:00 Thank you for listening to Python Bytes. Follow the show on Twitter via @pythonbytes and get the full show notes at pythonbytes.fm. If you have a news item you want featured, just visit pythonbyes.fm and send it our way. We’re always on the lookout for sharing something cool. On behalf of myself and Brian Okken, this is Michael Kennedy. Thank you for listening and sharing this podcast with your friends and colleagues.