Transcript #5: Legacy Python vs Python and why words matter and Request's 5 Whys retrospective

00:00 This is Python Bytes, Python headlines and news delivered directly to your earbuds.

00:04 It's episode 5, recorded December 5th, 2016.

00:07 This episode is brought to you by Rollbar. They take the pain out of errors.

00:12 This is Michael Kennedy, your co-host, along with Brian Okken.

00:16 Hey, Brian, how's it going?

00:17 It's going really good today.

00:18 Yeah, it's another week of exciting news in the Python world.

00:22 Yeah, well, let's get started right off the bat.

00:25 All right, tell me why.

00:26 Tell me why. Awesome.

00:30 There was an article, The 5 Whys of Request 2.12, 2.12.

00:35 And I thought this was a great article because it apparently in version 2.12 that came out November 15th,

00:47 they're already up to 2.12.3 now on December 1st.

00:52 But there's a, I think that they broke some people.

00:55 There were some corner cases, the non-standard ways to use Request that was supported before.

01:01 There's some reasons why they needed to change it.

01:04 And this is a good article.

01:06 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.

01:15 And it was just really well written.

01:17 It is well written.

01:18 And it gives you a look inside of how challenging it can be to write software at this scale.

01:24 I mean, Request itself is not a huge piece of software, right?

01:27 Not like Django or something like this.

01:30 Or OpenStack.

01:31 One of these really big, big projects.

01:33 But it's used so incredibly widely.

01:37 Request is downloaded 7 million times a month.

01:41 Think about that.

01:42 Yeah.

01:43 And it may be one of the largest because of how it's being used by everybody.

01:48 I mean, not large in size, but large in...

01:50 Huge footprint.

01:50 Yeah.

01:51 Yeah, absolutely.

01:52 So the problem was the current release of Request, 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.

02:05 Where it used to sometimes sort of work.

02:09 So people were kind of tweaking that.

02:11 And it has to do with a bunch of stuff internally, right?

02:14 They're moving to different domain resolution things inside and so on.

02:19 Huh.

02:19 Okay.

02:20 Yeah.

02:21 Anyway, it's basically the article talks about how hard it is to maintain software.

02:26 Like if you have software that's used as widely as Request, there's like no part of it being touched.

02:31 And I think the takeaway was more or less two things.

02:35 One, make sure that your validation and error checks are a little extra picky, right?

02:44 Like they said, the root of the problem is that they kind of didn't check strongly enough for these things initially.

02:50 And so stuff was able to work through.

02:52 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.

03:00 And the other takeaway was find a maintainer of your open source project that you love and give them a hug.

03:06 Definitely.

03:06 It's not an easy job.

03:08 No, it's not an easy job.

03:09 But, you know, 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 Bossonier.

03:17 I'm probably messing his name up a little bit.

03:18 Sorry, Matthias.

03:19 He's from the Jupyter Project at UC Berkeley's Institute for Data Science.

03:24 And he works on Jupyter and IPython, notebooks, things like that.

03:29 And this article is not super new, but I haven't talked about it before.

03:33 And I really thought it was kind of timely.

03:35 Again, you know, it came back to be relevant.

03:38 And I think it's going to continue to be relevant over the next few years.

03:42 It's more about a mental shift than it is about anything else.

03:46 And the article that I want to talk about is called Planning an Early Death for Python 2.

03:50 Okay?

03:51 Yeah.

03:52 Yeah.

03:52 So, you know, we've had this whole Python 2, Python 3 deal over Thanksgiving break.

03:58 That was last week.

03:59 And we talked about that and so on.

04:00 But this is not so much about whether or not we should be teaching people new things.

04:04 It's about how we perceive and talk about Python 2 versus Python 3.

04:10 So I'll just read you a little introduction here, just paragraphs.

04:12 It says, out of the discussion.

04:14 So this is a group, a workshop that they met at the Berkeley Institute for Data Science, a bunch of data science folks.

04:19 So they're coming at it from that angle.

04:21 So it says, out of the discussion arose a topic that's long plagued the Python community at large.

04:25 Code that requires legacy Python 2.7 is holding back the development of data science tool sets

04:30 and by extension the progress of data science as a whole.

04:33 They convened this small working group to plan an early death to Python 2, or they call it legacy Python.

04:39 And so they came up with a few things concretely that they can do.

04:43 And I think the most important message here is to choose your words carefully.

04:47 So instead of talking about Python 2 versus Python 3, talk about Python versus legacy Python.

04:55 Oh, nice.

04:56 So when you talk about, when you say Python, say, well, I mean Python 3.

04:59 Like, what would you be talking about, right?

05:00 And when you talk about Python 2, it's legacy Python.

05:03 Refer to legacy Python in the past tense to reinforce its old and deprecated state.

05:08 Let's see.

05:09 Make your examples and your documentation Python 3 only.

05:13 So if you're doing something with, like, asynchrony, you know, use async and await keywords, right?

05:19 Things like this.

05:20 If a user sends you a bug to a library, ask them to reproduce it on an up-to-date version of Python.

05:26 And make sure that, of course, you know, when you have continuous integration, your tests run on Python 3 as well.

05:31 So I really found this article interesting.

05:34 And it's about the mentality of it, right?

05:37 If people at conferences and people who write and maintain libraries start referring to Python 2 as legacy Python,

05:44 and they start calling Python 3 just Python, and they assume, you know, like, that's the way the documentation is written,

05:51 I think it would have a tremendous effect on the adoption of Python 3 over a couple of years as people come into Python,

05:59 as they come into these new libraries.

06:01 If you start to hear, oh, this thing I'm using is called legacy.

06:04 Well, wait a minute.

06:05 Maybe I should stop using it, right?

06:07 Yeah.

06:07 And one of the things, I don't know if they touch on this, but one of the reasons why,

06:12 if you start out supporting Python 3 and you, if you are, start out current Python,

06:18 and wanted to try to help support older versions, it doesn't add to clarity to your code.

06:27 I mean, you'll have to not use some features that are, like, new and awesome.

06:33 And that is problematic to try to support old libraries or old versions of Python.

06:39 You can't use some of the new stuff.

06:40 Yeah, I totally agree.

06:42 It's a really well-written article, and I'm probably not doing it justice,

06:45 but I love the mental shift of we have Python and we have legacy Python.

06:49 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.

06:56 If you don't want to support it, it's up to you.

07:00 Yeah.

07:00 Well, for example, the Beware project coming along, that's a good example.

07:04 Oh, okay.

07:05 So they're only on Python 3?

07:07 Yeah, they're just doing Python 3 for their code, and Beware is doing amazing stuff.

07:10 Interesting article called Simplifying Complex Business Logic with Python's Ken Ren.

07:16 That sounds cool.

07:17 What's Ken Ren?

07:18 I had never heard of it before I read this article, and it's a library that helps with some logic coding,

07:26 and I still am going to have to play with it a bit because I'm having a hard time getting my head around it.

07:31 However, it looks like a lot of stuff that some people use.

07:35 I mean, traditionally, people use spreadsheets for or some of the data analysis stuff,

07:41 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.

07:48 It's written more business-friendly, I guess.

07:50 I see.

07:51 And they have an example in the article that actually I love that it's a Simpsons example.

07:59 If you give a whole bunch of a data set with whose parent is who in the Simpsons,

08:04 and you call it a relation, it has a whole bunch of different things that you can say.

08:09 This piece of data has a relation or a fact or there's a couple things.

08:14 You can just have sets of data.

08:17 And ask questions about the data, like who's a person that has two children in the Simpsons or things like that.

08:25 Basically, a different way to ask questions about your data, as far as I can tell,

08:29 a way to ask questions about your data that's different than some of the other methods I've seen before.

08:34 You know, I like different ways to cut different problems.

08:38 Yeah, it looks really cool.

08:42 And it looks almost like a knowledge base.

08:44 You set up all these facts and relationships between them.

08:47 And then you can ask it all kinds of questions.

08:49 And I think it's pretty awesome.

08:51 Yeah.

08:53 I don't know what type of problem I'd need it for, but yeah, another tool in your tool belt.

08:58 Yeah.

08:59 Yeah.

08:59 Tools are good.

09:00 Tools are good.

09:01 You know, before we talk about the next set of tools, actually, let me tell you about our sponsor, Rollbar.

09:06 Thank you, Rollbar.

09:07 We're really happy to have you guys on board.

09:09 Thank you.

09:10 The Talk Python websites handle almost 2 million dynamic HTTP requests per month and transfer 4 or 5 terabytes of data.

09:17 And yet I deploy them frequently.

09:19 I don't worry about whether or not they're up and running.

09:22 I have some basic server monitoring.

09:24 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.

09:32 And it comes with all sorts of info already there.

09:34 So you can probably fix the problem before you even have to debug it or something.

09:38 So it's great.

09:39 If you guys want to check out Rollbar, please go to rollbar.com slash pythonbytes and sign up for the free tier.

09:44 You can plug it in in a few minutes.

09:46 Sounds awesome.

09:46 Yeah, it's awesome.

09:47 Okay.

09:48 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?

09:53 All right.

09:55 So speaking of web apps running that are pretty cool, one of the larger implementations or deployments of Python is Reddit itself.

10:03 So Reddit's, you know, often referred to as the front page of the Internet.

10:09 Maybe that's Facebook these days.

10:10 I don't know.

10:10 But Reddit has definitely got a lot of traffic.

10:12 That's for sure.

10:13 And it's built on some of the older Python technologies.

10:17 So pylons, Mako templates, a custom non-OR version.

10:22 So the core part of SQLAlchemy, right?

10:25 And I'm sure there's tons of other stuff going on there as well.

10:28 So there was this question or discussion on Reddit.

10:30 It says, if Reddit were written from scratch today, which Python web framework would it use and why?

10:36 I don't know.

10:37 I just, I feel like the sense that I, 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.

10:46 And, you know, my stuff's built on Pyramid.

10:47 I really like Pyramid.

10:49 I think it's kind of a nice Goldilocks framework between the two that I was mentioning.

10:53 And I thought it was interesting that a bunch of people came out and said, well, obviously Pyramid's the right choice for this.

10:59 All right.

10:59 So I'll give you a few sentences from what people said.

11:02 So I would say the most sane option would be Pyramid.

11:05 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.

11:10 I did some both small and medium to big, you know, say 20 million plus user web apps.

11:14 And it just feels right.

11:16 It doesn't get in your way and it will give you magical solutions to your problem.

11:19 It's great.

11:20 Another guy said, assume you're talking about Reddit at its current scale, not Flask, too many global variables, not thread safe for async, not Django, too opinionated.

11:27 Everything's in-house for scaling reasons.

11:29 My guess is Pyramid.

11:30 In fact, that's what Reddit's current services are built.

11:33 And they link to a GitHub thing that is a foundation in their services.

11:35 And the takeaway was basically, you know, around this discussion that the web frameworks cause a lot of strong subjective split in opinion.

11:42 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.

11:52 Yeah, and that's often what I hear, too.

11:55 And then I saw this and it was surprising to me, but I enjoyed reading about it.

12:01 And it also prompted me to try to find some time to go through your course because don't you teach Pyramid in your course?

12:08 Yeah, I do.

12:09 In my Python for Entrepreneurs course, it's definitely Pyramid.

12:12 Cool.

12:12 It's pretty cool.

12:13 Yeah, thanks.

12:14 Next up, I've got actually, I'm going to bundle these.

12:17 I've got two testing related articles.

12:19 And I was tempted to just have these be two different articles on this, but I didn't want to take over the entire podcast or testing.

12:27 But there's a getting started with pytest that's from, I'm going to get his name wrong, but it goes by Jacobian.

12:35 What's, who's, Jacob, Jacob Kaplan Moss.

12:38 That's it.

12:39 One of the things I like is it's not a, it's not a silly, he does, it's a simple example, but it's also a real example using some, some things that are hard to, hard to just visually tell whether something's right or wrong.

12:55 He also goes through and uses, looks at test parameterization, which is very useful if you're into testing.

13:03 The second article is the best new feature of unit, in unit tests you didn't know you needed.

13:09 The feature that isn't highlighted in the title is subtest.

13:13 And subtest was added in Python 3.4, but I haven't seen very many people blog about it or talk about it.

13:21 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.

13:28 If the, normally, if you just iterate through them, the first one that fails will stop your test.

13:34 But subtest is a way to say, I want all of these to be checked or everything within this loop.

13:41 Oh, that is, 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, three separate sort of things I need to verify to actually verify this case.

13:52 And I could use subtest for those, right?

13:53 Yeah.

13:54 Okay.

13:55 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.

14:03 And it's a pretty cool thing.

14:05 I know since I'm a pytest fan, you can run unit test with pytest, unit test written tests with pytest.

14:13 pytest will run subtests, but it doesn't highlight out the individual failures as subtest does.

14:22 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.

14:31 If you're looking, if you're running in pytest, you'd probably use parameterization anyway for the same problem.

14:37 So the last one here I have for us is just a fun one, right?

14:41 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,

14:50 but the right kind of music along with coding is like the perfect mix.

14:53 So there's this jukebox type thing called PyTone.

14:57 Now, by no means is PyTone new, but I haven't talked about it.

15:01 People recommended it to me.

15:03 So KidPixo, who runs the Geek Cookies Italian developer podcast, sent this over and said,

15:09 Hey, you guys should check this out.

15:10 This is fun.

15:11 Let me just give you a quick little summary of what this screenshot here.

15:18 And you pull it up, I'm going to have you describe it to me.

15:21 I'm going to set the stage.

15:22 Under the screenshot here, it says, this is how PyTone 197 looks in action in the 80 by 25 terminal.

15:29 So this is a terminal based iTunes type of thing.

15:33 Brian, what do you think of this?

15:35 Actually, I kind of like it a lot.

15:37 It's neat.

15:38 It's neat, right?

15:39 Like imagine you could project this up on the screen during breaks while you have music playing.

15:43 And it's really a terminal based with progress bars and playlist, everything.

15:48 Little music players.

15:50 Cool.

15:50 Yeah.

15:51 And it looks nerdy.

15:53 So there's that.

15:56 Exactly.

15:57 Well, that's why I said you should do it at like a geek conference, right?

15:59 It would be perfect for that.

16:01 Yeah.

16:02 Also, I think it's neat to see a maintained curses project.

16:08 Yeah.

16:09 It's an interesting use of curses as well.

16:12 Like if you want to build an interesting kind of more interactive GUI, terminal based GUI, I guess.

16:17 It's cool.

16:17 All right.

16:19 That's it.

16:19 That's it for our headlines this week.

16:22 It's been slightly less interesting than last week.

16:26 But nonetheless, a lot of cool stuff coming along.

16:29 A lot of good news to share with you.

16:31 Brian, you got anything going on you want to tell everyone about?

16:33 Well, I've put out last week I was trying to get two episodes out of Testing Code and did.

16:41 So I got episode 25 talking about Selenium with Dave Hunt and also pytest and working at Mozilla.

16:48 Yeah, that was a good one.

16:49 And then 26 was a new tool called that I hadn't heard of before called PyRest Test and got the developer on to talk about that.

17:00 And it's a REST API testing framework that uses YAML to describe the tests.

17:07 It's pretty cool.

17:08 Oh, very cool.

17:09 Yeah.

17:09 I'll definitely have to check that out.

17:10 YAML seems to be coming along for all sorts of things around REST.

17:13 We've got it for Swagger for like automatic API documentation generation and testing as well.

17:21 It sounds like that's cool.

17:22 Yeah.

17:23 And my first reaction for to YAML stuff is why do we need something else?

17:26 But it is it seems like it's more human readable than some of the other options.

17:31 Yeah.

17:32 Well, as long as we stay away from XAML, I'm happy.

17:34 How about you?

17:36 What's going on with you?

17:37 Yeah, not so much.

17:38 Just working on like the entrepreneur's course that you talked about.

17:41 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.

17:49 So I'm just, you know, life's good.

17:51 Nice.

17:51 Love working on all the Python projects I got going on.

17:53 Wonderful.

17:54 Yeah, absolutely.

17:55 All right.

17:56 Well, everyone, thank you for listening.

17:57 Brian, thanks for sharing the headlines with me.

18:00 It's been fun.

18:01 Thank you.

18:02 It has been fun.

18:02 Yeah.

18:03 Bye, everyone.

18:03 Thank you for listening to Python Bytes.

18:06 Follow the show on Twitter via at Python Bytes.

18:09 That's Python Bytes as in B-Y-T-E-S.

18:11 And get the full show notes at Python Bytes.fm.

18:15 If you have a news item you want featured, just visit Python Bytes.fm and send it our way.

18:19 We're always on the lookout for sharing something cool.

18:22 On behalf of myself and Brian Okken, this is Michael Kennedy.

18:25 Thank you for listening and sharing this podcast with your friends and colleagues.