Python Bytes - #5 Legacy Python vs Python and why words matter and Request's 5 Whys retrospective

Episode Date: December 5, 2016

See the full show notes for this episode on the website at pythonbytes.fm/5

This is Python Bytes, Python headlines and news delivered directly to your earbuds. It's episode 5, recorded December 5th, 2016. This episode is brought to you by Rollbar. They take the pain out of errors. This is Michael Kennedy, your co-host, along with Brian Aukin. Hey, Brian, how's it going? It's going really good today. Yeah, it's another week of exciting news in the Python world.

Yeah, well, let's get started right off the bat. All right. Tell me why. Tell me why. Awesome. There was an article, the five whys of request 2.12, 2.12. 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, the non-standard ways to use requests that was supported before. There's some reasons why they needed to change it. And this is a good article. I think it's put up to try to limit people from getting mad first

so that they try to understand from the library supporter point of view why they made the changes. And it was just really well written. It is well written. And it gives you a look inside of how challenging it can be to write software at this scale. I mean, Request itself is not a huge piece of software, right? Not like Django or something like this, or OpenStack, one of these really big, big projects, but it's used so incredibly widely. Request is downloaded

7 million times a month. Think about that. Yeah, and it may be one of the largest because of how it's being used by everybody. I mean, not large in size, but large in... Huge footprint. Yeah. Yeah, absolutely. So the problem was the current release of requests, that is the 2.12 version,

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. And it has to do with a bunch of stuff internally, right? They're moving to different like domain resolution things inside and so on. Huh. Okay. Yeah. Anyway, it's, it's basically the article talks about how hard it is to maintain software. Like if you have software that's used as widely as Anyway, it's basically the article talks about how hard it is to maintain software. Like if you have software that's used as widely as request, there's like no part of it being touched.

And I think the takeaway was more or less two things. One, make sure that your validation and error checks are a little extra picky, right? Like they said, the root of the problem is that they, they kind of didn't check strongly enough for these things initially. And so stuff was able to work through and 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. And the other takeaway was find a maintainer of your open source project that you love and give them a hug.

Definitely. It's not an easy job. No, it's not an easy job. You know, speaking of people that I want to hug, there's a guy that I had on the show on TalkPython a while ago, Mathias Bossonnier. I'm probably messing his name up a little bit. Sorry, Mathias. He's from the Jupyter project at UC Berkeley's Institute for Data Science.

And he works on Jupyter and IPython notebooks, things like that. And this article is not super new, but I haven't talked about it before. And I really thought it was kind of timely. Again, you know, it came back to be relevant. And 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. And the article that I want to talk about is called Planning an Early Death for Python 2.

Okay? Wow. Yeah. Yeah. So, you know, we had this whole Python 2, Python 3 deal over Thanksgiving break. That was last week. And we talked about that and so on. But 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. So I'll just read you a little introduction here, just paragraphs. It's out of the discussion. So this is a group, a workshop that they met at the Berkeley Institute for Data Science, a bunch of data science folks. So they're coming at it from that angle. So it's out of the discussion arose 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 tool sets

and by extension the progress of data science as a whole. They convened this small working group to plan an early death to Python 2, or they call it legacy Python. And so they came up with a few things concretely that they can do. And I think the most important message here is to choose your words carefully. So instead of talking about Python 2 versus Python 3, talk about Python versus legacy Python. Oh, nice. So when you talk about, when you say Python, say, well, I mean, Python 3, like what would you be talking about, right?

And when you talk about Python 2, it's legacy Python. Refer to legacy Python in the past tense to reinforce its old and deprecated state. Let's see. Make your examples and your documentation Python 3 only. So if you're doing something with like asynchrony, you know, use async and await keywords, right? Things like this. 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 that of course you know when you have continuous integration your tests run on python 3 as well so i really found this article interesting and it's it's about the the mentality of it right 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, oh, this thing I'm using is called legacy. Well, wait a minute. Maybe I should stop using it, right? Yeah. And one of the things, I don't know if they touch on this, but one of the reasons why if you start out supporting Python 3 and you, if you are start out current Python and wanted to try to help support older versions, it doesn't add to the clarity of your code.

I mean, you'll have to not use some features that are like new and awesome. And that is problematic to try to support old libraries or old versions of Python. You can't use some of the new stuff. 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. Yeah, and I kind of even like the idea of, like, 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. Yeah, well, for example, the Beeware project

coming along, that's a good example. Oh, okay. So they're only on Python 3? Yeah, they, for example, the Beware project coming along, that's a good example. Oh, okay. So they're only on Python 3? Yeah, they're just doing Python 3 for their code. And Beware is doing amazing stuff. Interesting article called Simplifying Complex Business Logic with Python's Ken Ren. That sounds cool. What's Ken Ren?

I had never heard of it before I read this article. And it's a library that helps with some logic coding. And I still am having, I'm going to have to play with it a bit because I'm having a hard time getting my head around it. However, it looks like a lot of stuff that some people use. I mean, traditionally, people use spreadsheets for or some of the data analysis stuff. But it's for people that are using, it's written such that I think it's more readable than some of the data analysis stuff but it's it's for people that are using um it's written such that i think it's more readable than some of the data analysis stuff it's written more business friendly i guess i see and like they have an example in the article that um actually i love that uh it's a simpsons uh

example if you give a whole bunch of a data set with whose parent is who in the simpsons then you in real and you call it a relation it has a whole bunch of different things set with whose parent is who in The Simpsons, and you call it a relation, it has a whole bunch of different things that you can say. This piece of data has a relation or a fact, or there's a couple things. You can just have sets of data and ask questions about the data, like who's a person that has two children in the Simpsons and 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 you know I like different ways to cut it different problems so yeah it looks really yeah yeah it looks really cool and it it

looks like almost like a knowledge base you set up all these facts and relationships between them, and then you can ask it all kinds of questions, and I think it's pretty awesome. Yeah, and I don't know what type of problem I'd need it for, but, yeah, another tool in your tool belt. Yeah, tools are good. Tools are good. Before we talk about the next set of tools, actually,

let me tell you about our sponsor, Rollbar. Thank you, Rollbar. We're really happy to have you guys on board. Thank you. The TalkPython websites handle almost 2 million dynamic HTTP requests per month and transfer four to five terabytes of data. And yet I deploy them frequently.

I don't worry about whether or not they're up and running. I have some basic server monitoring. And if anything goes wrong with the app, Rollbar is going to send me detailed information to my Slack, my email, all sorts of things. And it comes with all sorts of info already there. So you can probably fix the problem before you even have to debug it or something. So it's great.

If you guys want to check out Rollbar, please go to rollbar.com slash pythonbytes and sign up for the free tier. You can plug it in in a few minutes. Sounds awesome. Yeah, it's awesome. Okay. I don't hope you have errors, but you know, you want to be sure that when you do, it's easy to solve them, right? All right. So speaking of web apps running that are pretty cool, one of the larger implementations or deployments of Python is Reddit itself. So Reddit's, you know, often referred to as the front page of the internet. Maybe that's Facebook these days. I don't know. But Reddit has definitely got a lot of traffic, that's for sure. And it's built on some of the older Python

technologies. So pylons, Mako templates, a custom non-OR version. So the core part of SQL alchemy, right? And I'm sure there's tons of other stuff going on there as well. So there was this question or discussion on Reddit. It says, if Reddit were written from scratch today, which Python web framework would it use and why? I don't know. I feel like the sense that when I talk to people and I listen to what people are doing with web frameworks,

it's either Flask or Django, Flask or Django, Flask or Django. And you know, my stuff's built on Pyramid. I really like Pyramid. I think it's kind of a nice Goldilocks framework between the two that I was mentioning. And I thought it was interesting that a bunch of people came out and said, well, obviously Pyramid is the right choice for this, right? So I'll give you a few sentences from what people said. So I would say the most sane option would be Pyramid. It's faster than Django and TAS, and it doesn't repeat the mistakes with thread locals that Flask or Pylons did in the past.

I did some both small and medium to big, you know, say 20 million plus user web apps, and it just feels right. It doesn't get in your way, and it will give you magical solutions to your problems. It's great. Another guy said, assuming you're talking about Reddit at its current scale,

not Flask, too many global variables, 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's current services are built. And they link to a GitHub thing that is a foundation of their services. And the takeaway was basically around this discussion

that the web frameworks cause a lot of strong subjective split in opinion. Yeah, I just thought it was really interesting to see a lot of people coming out with this Pyramid recommendation because I hear Flask versus Django so often. Yeah, and that's often what I hear too. And I saw this and it was surprising to me,

but I enjoyed reading about it. And it also prompted me to try to find some time to go your course because don't you teach pyramid and yeah i do in my python for entrepreneurs course it's definitely a pyramid cool it's pretty cool yeah thanks next up i've got actually i'm going to bundle these i've got two testing related articles um and i was tempted to just have these be two different articles on this but um i didn't want to take over the entire podcast or testing. But there's a getting started with PyTest that's from, I'm going to get his name wrong, but it goes by Jacobian. Who's Jacob?

Jacob Kaplan Moss. That's it. One of the things I like is it's not a silly, it's a simple example, but it's also a real example using some things that are hard to just visually tell whether something's right or wrong. He also goes through and uses, looks at test parameterization, which is very useful if you're into testing. The second article is the best new feature in unit tests you didn't know you needed. The feature that isn't highlighted in the title is subtest. And 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 within a test, like 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 within this loop. Oh, that is really cool because sometimes you create a unit test and you're like, well, there's so much. I've sort of got it ready, but there's actually three separate sort of things I need to verify to actually verify this case. And I could use subtest for those, right? Yeah. Okay. Using it, you can fail a part of it and that part of it will skip out and not continue, but it'll go on to the next subtest. and it's a pretty cool thing. I know since

I'm a pytest fan you can run unit tests with pytest. Unit tests written tests with pytest. PyTest will run subtests but it doesn't highlight out the individual failures as subtest does. So that is one of the breaking if you're writing unit tests that you want to run with a PyTest runner. Subtest might be something you might want to avoid. If you're looking, if you're running in PyTest, you'd probably use parameterization anyway for the same problem. So the last one here I have for us is just a fun one, right? So imagine you're running a meetup or a 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, it's like the perfect mix. So there's this jukebox type thing called PyTone. Now, by no means is PyTone new, but I haven't talked about it. People recommended it to me. So KidPixo, who runs the Geek Cookies Italian developer podcast, sent this over and said, hey, you guys should check this out. This is fun.

Let me just give you a quick little summary of this screenshot here. You pull it up. I'm going to have you describe it to me. I'm going to set the stage. Under the screenshot here, it says, this is how Python 197 looks in action in the 80 by 25 terminal. So this is a terminal-based iTunes type of thing. Brian, what do you think of this?

Actually, I kind of like it a lot. It's neat. It's neat, right? Like imagine you could project this up on the screen during breaks while you have music playing, and it's really a terminal-based with progress bars and playlists, everything. Little music player. It's cool. Yeah.

And it looks nerdy. So there's that. Exactly. Well, that's why I said you should do it at a geek conference, right? It would be perfect for that. Yeah. Also, I think it's neat to see a maintained Curses that. Yeah. Also, I think it's neat to see a maintained

Curses project. Yeah, it's an interesting use of Curses as well. If you want to build an interesting kind of more interactive GUI, terminal-based GUI, I guess. It's cool. Alright, that's it. 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. Brian, you got anything going on you want to tell everyone about? Well, I've put out, last week I was trying to get two episodes out of Testing Code

and did, so I got episode 25 talking about Selenium with Daveave hunt and also pi test and working at mozilla yeah that was a good one and then uh 26 was a new tool called that i hadn't heard of before called pi rest test and got the developer on to talk about that and it's a rest api testing framework that uses um yaml to describe the tests it's pretty coolEST API testing framework that uses YAML to describe the tests. It's pretty cool. Oh, very cool.

Yeah, I'll definitely 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. Yeah, my first reaction to YAML stuff is, why do we need something else? But it seems like it's more human-readable than some of the other options.

Yeah. Well, as long as we stay away from XML, I'm happy. How about you? What's going on with you? Yeah, not so much. Just working on the entrepreneur's course that you talked about. I'm going to ship a couple hours of new content there after we hang up here and I can get a chance to upload it and

organize it and all that. So I'm just, you know, life's good. Love working on all the Python projects I got going on. Wonderful. Yep, absolutely. Alright, well, everyone, thank you for listening. Brian, thanks for sharing the headlines with me. It's been fun. Thank you. It has been fun. Bye, everyone.

Thank you for listening to Python Bytes. Follow the show on Twitter via at Python Bytes. That's Python Bytes as in B-Y-T-E-S. And get the full show notes at pythonbytes.fm. If you have a news item you want featured, just visit pythonbytes.fm and send it our way. We're always on the lookout for sharing something cool. On behalf of myself and Brian Auchin, this is Michael Kennedy. Thank you for listening and sharing this podcast with your friends and colleagues.