Brought to you by Michael and Brian - take a Talk Python course or get Brian's pytest book


« Return to show page

Transcript for Episode #52:
Call your APIs with uplink and test them in the tavern

Recorded on Wednesday, Nov 15, 2017.

00:00 KENNEDY: Hello and welcome to Python Bytes, where we deliver news and headlines directly to your earbuds. This is Episode #52, recorded November 15th, 2017. I’m Michael Kennedy.

00:00 OKKEN: And I’m Brian Okken.

00:00 We’ve got some awesome news for you. Hey, Brian. Do you want to say, ‘Happy birthday.’

00:00 Oh, yeah. Happy birthday.

00:00 Yeah, so this is the 52nd episode of Python Bytes and if I recall, I’m pretty sure we didn't skip a single episode. The entire first year we shipped an episode every week and I think that’s pretty awesome.

00:00 That is cool. Even around Christmas and stuff?

00:00 Yeah. I think we somehow recorded ahead. Maybe we missed on, but I think we did it. It’s pretty exciting. I just want to say thank you to everybody out there who listens to the show on a weekly basis. That’s why we do it. We do it for you guys and we wouldn’t do it if you weren’t interested and excited. So, thank you for appreciating this. Giving us all the ideas and keeping us going.

00:00 Yeah, definitely, thank you. And we had a whole bunch backed up so this episode is two hours long and it has 52 topic. (Laughs)

00:00 (Laughs) That’s right, you guys. Pause it now, get a coffee, settle in, or whiskey if it’s late. Actually, we’re going to keep to the same format.

00:00 we get to our topics though, I just want to say thank you again to DigitalOcean. They’re another reason that this show is going strong. DigitalOcean, Rollbar and a few of the other folks that continuously support this show, thank you, thank you. They just launched Spaces. Check it out at do.co/python. We’ll tell you more about it later.

00:00 I want to spend awhile on APIs, Brian.

00:00 Yeah, I’ve got APIs on the brain right now. So, we’ll start with a project called Tavern.

00:00 It’s like a drinking game or something?

00:00 (Laughs) No, it's testing RESTful APIs. I don’t know why it’s called Tavern. I’ll have to ask them about that.

00:00 It’s a really cool project though, I checked it out. I like it a lot.

00:00 It’s a tavern testing.github.io. Like I said, it’s RESTful API testing. What it reminds me of the most is pyresttest because it uses a YAML format to describe the tests and describe what sequences to go through. So, it does have one-off tests where you can just either post or gets from a URL and you can specify what you want out of it. But you can also do sequences and one of my favorite things about this is it comes with a pytest plugin and they say it works best when integrated with pytest.

00:00 That’s really awesome. So, you basically describe, ‘I want you to call this URL. It’s going to be a get.’ You expect to get this thing back and you can just assert against it? Is that how it works?

00:00 With the YAML-syntax, you don’t even have to specify asserts, you just specify what you expect to get back and it just automatically tests for all that. For things like this, I actually really like, even though it takes up a lot of space – the YAML takes a lot more space than a little test function – but it’s very readable, especially if you have Azure that colorizes your YAML file. I think it’s good, especially because you can discuss it with non-programmer people. That’s one of the benefits of that.

00:00 Okay. Yeah, that’s really cool. That’s true, you can give a YAML file to a non-technical person who is a requirements-gatherer or business analyst or something, or domain expert. They can say, ‘Yeah, these are the things that slot in here.’ Or to the person who built the API.

00:00 For instance, the sequences, you can say, ‘The test is called this. This is sort of the sequence we’re going to go through. First you log in, then you have to do this.’ Also, with a lot of sequences, you have to get information, like tokens or something from the server. Tavern allows you to save those tokens as variable names to use later, in later tests, which is nice.

00:00 Yeah, that’s really sweet. Tavern sounds really cool. Definitely worth checking out.

00:00 thing I want to talk about is not for testing APIs but for consuming APIs, calling APIs. If you we’re looking at this document we’re sharing and just thinking of, ‘Hey, I’m going to call an API from Python.’ What library do you think you would use?

00:00 Oh, Requests.

00:00 Obviously. Everyone uses Requests and Requests is one of the absolute most popular libraries. It’s downloaded an insane number of times. What I find myself doing a lot when I know this is a proper API I’m going to consume, it’s part of an application or I’m going to fold it in and make it really important, I’ll create a class or some module that will model all the actions that you take against that API. ‘Login’ or ‘Get courses’ or whatever your API is about, right? You use Requests to implement it but deep down, you kind of bury Requests. And hopefully, you’ve got some facade or class or module in front of it.

00:00 I want to talk about this up and coming project that does that all at once for you, which is really sweet. And you use it with decorators called Uplink. Have you heard of Uplink?

00:00 Not until you listed it today, but it looks really cool.

00:00 Super cool, right? Let me just describe how to use this. So, imagine I wasn't to call the GitHub API, I want to have a header on all my requests that says, ‘I’m using this particular format or schema for my JSON. I’m going to call the get_user function. I might update a user.’ And so on. So, what I do, I create a class, call it whatever you want, derived from a certain based class that comes from Uplink. I add a @headers decorator to the class. I say, ‘Accept’ the right, funky content type, that just applies to all the functions you call on this class. If I want to get the users, I’d say, ‘Create a function called Get User’ and I’d say @get/user/{username} and that {username} there maps to the arguments. When I call it I say, ‘GitHub.get_user(mikeckennedy)’ and it actually directly pulls that into the little URL decorator and passes it.

00:00 This is cool.

00:00 It’s cool, right? They have another example for updating the user, that’s a patch call. So, you say, @JSON @patch. And then the arguments to the method, you can pass like a body of basically **kwargs. That becomes the body of the patch submission. You can also say, ‘Access token: query’ and use the type decorator in Python 3 to decorate as a query. So, then it will go, ?accesstoken= what you pass as that argument. This is so smooth.

00:00 Wow.

00:00 I really like it. So, if I’m building a super structured API that’s got really strict RESTful requirements like this, I’m definitely going to check out Uplink.

00:00 Definitely watch this, this is neat. They have a little warning in there that says it’s in the early stages, but that might be a great way for other people to get involved and want to help out to push this further.

00:00 It's definitely a warning you want to be careful about. It’s not quite production-ready. Mostly not because they think the API may change. They don’t want to break your code.

00:00 think there’s an opportunity here. There’s so many people who say, ‘I want to get started in Open Source.’ And they look at Django or CPython and go, ‘This is complicated. Changing this is really hard.’ Something like this, you can totally contribute to a project like this without getting overwhelmed in the early stages, so check it out.

00:00 Yeah, check it out. Cool.

00:00 So, let’s switch to a totally different topic and talk about REST and APIs.

00:00 (Laughs) Yeah. So, I wanted to combine these two things because I ran across them in the same week, for one. And this was shared by a listener and I’m sorry that I didn’t write down the name.

00:00 Yeah, thank you for submitting that. That’s awesome. I saw that come in as well, over email.

00:00 There’s an article called, “Using JSON-schema for REST API Endpoint Tests.” Have you heard of JSON-schema before?

00:00 I have heard of JSON-schema. It’s kind of what your test does but at a different level. You can say, ‘This is what the JSON is supposed to look like. This is supposed to be an integer. This is supposed to be a string.’ And so on. But I’ve never used and I’ve pretty much exhausted my knowledge of it now.

00:00 The example of it, they do Django – which I don’t really know Django so I kind of read that anyway – but I don’t think it’s necessary. You can use this for anything. But the idea is, you can implement a schema to describe what your data should look like an then actually serve that. So, on your server code, serve that as well. For your tests you can grab the schema and then grab whatever data you want. Then use the test to validate that the data you’re getting adheres to the schema. And then you can also go out and make sure the values are correct and things like that.

00:00 I’m just curious what you think of this?

00:00 I think it's pretty cool,actually. Especially if the API already has a JSON-schema associated with it. If they’re like, ‘Here’s the schema. Here’s the API.’ Then you can just say, ‘Here’s how I test.’ It’s interesting if you are the maintainer of that thing so you know if the tests break that you’re verifying, that you have to go and update the documentation, or something like this. But it’s also interesting to point at APIs you depend upon and say, ‘I'm going to call this and I want to know if the schema changes.’ Because it’s totally common that people document one API, the API will change, your stuff will stop working. And you’re like, ‘But I’m doing what they say. What’s happened?’ If you knew the schema of APIs that you depended upon changed, this is a good way to do that. I think that’d be great.

00:00 Yeah, or even if you didn’t have a schema provided to you, you could find one.

00:00 Yeah, it’s usually not too hard, right?

00:00 Actually, that’s a great idea. And another thought with that is, it’s not just restful APIs. Anything that’s using JSON, you can use that to test any APIs.

00:00 Yeah, definitely. It’s very neat. So, check that out as well.

00:00 we go onto the next thing, I’m going to tell you where your audio came from this week. It came from DigitalOcean Spaces. Those guys are sponsoring this episode, as I said at the top of the show. Check them out at do.co/python. Get a free two month trial of Spaces. And Spaces is object storage and delivery in the Cloud. Things like AWS S3, Azure blob storage. Things like that but way, way better. Better pricing, simpler, things like this. I’ve been using it for this podcast. I just recently – big announcement – just recently switched to using it as the video delivery network for my courses. So, I’m trying that out on a few courses and it’s been super smooth as well. What’s really interesting, the way that I wrote the API for accessing the video files and stuff was, I imported Photo 3. That’s the S3 AWS API. The API is compatible with S3 quite literally. It’s the same API even, just point at a different base URL and you’re good to go.

00:00 you’ve been using something like S3, you really owe it to yourself to check out DigitalOcean Spaces at do.co/python. Very cool stuff.

00:00 Very neat and cool that you tried that our that the API is compatible.

00:00 So, far it’s working really well.

00:00 I was thinking that some music would be nice.

00:00 I love to listen to music when I code. Do you?

00:00 Yeah, all the time.

00:00 It’s funny, I find that a little bit of distraction helps keep the mind focused. People are weird but I work in coffee shops and I like that as well. But this is a different kind of music for coding. This is almost like music as performance art. There’s this presentation called, “Programming Music for Performance: Live Coding with FoxDot.” This is from Ryan Kirkbride at PyCon UK. It’s a really short video but maybe it will inspire some people to do some similar performances. Basically, he’s up there writing code to dramatic, electric, classical-type music and it’s really interesting to see it go. What did you think of it Brian?

00:00 I thought it was really interesting but I’m a little lost. I was hoping you could explain to me what’s going on.

00:00 I wasn’t at the talks and the video’s not that long and I didn’t see the introduction, but what I think it is, ‘I’m going to show you come cool thing by writing a demo live but instead of explain it to you, I’m going to do it to dramatic music and make it like a performance art.’ Remember how we talked about code as poetry awhile back? This is like code as performance art, I think.

00:00 Yeah, I guess I’ll have to check out what FoxDot is and how that all works with that.

00:00 Yeah, sadly there’s not that much information in this video because it’s partial. But this is from Ian Watt, another listener suggestion I thought it might inspire some of you guys out there. Have a look at this little video, it’s cool. Be sure to turn on the audio.

00:00 Plus, he did a talk without speaking, which is good.

00:00 Exactly. We’ve talked about, ‘Should you do live coding during your demos?’ This is like the opposite. Only live coding and there’s nothing else. There’s not even words. (Laughs) It’s awesome. If we had a weekly Python chat there’d we words, right?

00:00 There’d be words and video and audio.

00:00 (Laughs) Tell us what you’ve got going on on this Weekly Python Chat? I saw that you were just on it.

00:00 Yeah, it was super fun. Weekly Python Chat is at weekly python.chat. It’s Try Hunter and I can’t remember what he exactly does but he’s part of the Python Software Foundation and he’s also a Python instructor. He does quite a bit. He’s a super nice guy. He has these weekly chats where he just picks somebody in the Python community and often requests by other people that listen, and does a little, under an hour, video chat with somebody else. But also, you can do live coding and there’s people in the chat room asking questions while it’s going on. So, it’s a live thing but it’s also recorded so you can watch old ones. So, yeah, the last one, last week on November 9th was Testing Python with pytest. It was with me. And I’m highlighting it because it’s really cool, it’s fun. It allows to ask questions of people that they wouldn’t, maybe you don’t go to conferences that much but you can stay up for a weird hour depending on where you live in the world. But you can ask questions of people you wouldn’t get a chance to otherwise.

00:00 Very cool, check that out. We’ve got a link in the show notes.

00:00 let’s round this out with a bunch of mistakes. Our last topic, I think, has a mistake in it. It’s “10 Common Beginner Mistakes in Python.” So, this comes to us from a blog post via check.io.org, or maybe it would be better pulling up py.checkio.org. Have you played with py.checkio.org? It’s like a video game for programming.

00:00 I think I have. Yeah, I have.

00:00 Yeah, it’s funky. So, you basically have these little islands, you’ve got to conquer the islands. The way you conquer them is by solving all the puzzles. It’s a little but like Myst, but programming. One of the things I think is really cool about playing the game is you solve some little puzzle, then you see how everybody else solved it. Then you get to see your style of programming relative to other solutions.

00:00 It’s kind of like code reviews. You can comment on other people’s solutions and stuff.

00:00 Yeah, it’s pretty cool. So, these guys wrote a blog post based on the mistakes they’ve seen people making from that area. Let’s go through the 10 common beginner mistakes real quick.

00:00 indentation, tabs versus spaces.’ Obvious, but you can imagine if you come from Java that you don’t know that, right?

00:00 one’s more subtle. Using a mutable value as a default value. So like, pen to list. Then you give it like, source list = [ ] [ ] as a default value. That is a super bad idea but not at all obvious why it’s bad. Because every time you call it without specifying that argument explicitly, it’s going to use the same list because that is initialized at not quite compilation time, but as Python sees and determines that method it finds that default value and sets it, it doesn’t actually recompile at every call.

00:00 Yeah, that’s a fun one.

00:00 It’s definitely fun and tricky.

00:00 a lot of comments and doc strings.’ My theory is – comments, not so much doc strings – comments are deodorant for code smells and problems, so I’m not so sure I’m going to recommend that as much. But documentation? Good stuff for sure.

00:00 If you come from a C-based language with { } (curly brace) scoping, block scoping, Python is different with its functions and closures and whatnot. So, that’s definitely a mistake to be made.

00:00 that I really love that they covered is called, ‘Edge cases first.’ And you can have a loop with a test that does another loop and anoter test. And that could be some super indented thing, or you could do the negative test, the edge case that you’re going to break out of, and then loop. And then you’re going to do the edge case you’re going to break out of and then the loop. It’s way less indented. That’s one of the ‘Zen of Python’ things and also a great design pattern.

00:00 I see a lot of that when people are used to old style C code or something, that they don’t trust the exception handling. Often times, you don’t have to make things bulletproof, if the function you’re calling is going to check it for you anyway.

00:00 Exactly. It’s easier to ask for forgiveness than for permission-style is better than the look before you leap.

00:00 got, ‘Copying.’ Everything is a pointer in Python. Pointers mean you maybe be sharing the same object, not a new one. It talks about that, especially around a list and data structures.

00:00 is half-closed.’ Range 1 to 10 actually is 1 to 9.

00:00 capitalization.’ So, you’re just writing like, CamelCase Java or C Sharp-style of naming for variables

00:00 finally, ‘Using class variables incorrectly.’ This one’s a little bit interesting about class-level variables and inheritance and you can check that out.

00:00 they have nice little examples for all of them. And as far as I can tell, there’s only nine mistakes. I’m not sure what the tenth mistake is. (Laughs) Maybe I read it wrong. I read it twice and I didn’t see it. I could have been tired.

00:00 Well, if range is 1 to 9.

00:00 Yeah, that’s true. It could be, Range 1 to 10 common beginner mistakes in Python. (Laughs) Anyway, if you’re getting started with Python and you want to level it up a little bit, check that out. Or if you’re working with new developers or mentoring new people, this is all good information.

00:00 Yeah, and also, if you’ve got somebody that works for you and they’re on check.io at their lunch break, they’re not just goofing off. They’re upscaling.

00:00 That’s right. Let them goof off on check.io. That’s one of the best possible options. Beats Facebook everyday.

00:00 That’s our six. You’ve got any news for us?

00:00 I do, I have two pieces of news, or ideas I want to run by you. First, have you tried Firefox Quantum? The brand new Firefox that came out yesterday?

00:00 No.

00:00 It’s supposed to be twice as fast. A lot of it is rewritten in Rust. It uses way less memory than Chrome. So, these are all pretty exciting. I’m actually checking out Firefox Quantum. I’m even doing the show from is this week. Pretty cool. So, if that sounds interesting to you, check it out. It sounds like Firefox might make a good comeback. They’re definitely the most Open Source friendly of all the browsers so I’d love to see them actually alive.

00:00 Rust is that language that I’m always meaning to try to look at but I haven’t yet.

00:00 Well, it’s getting dark and cold and rainy here in Portland. Maybe you’ll have a Sunday afternoon where you’re like, ‘I just need to get a book and sit by the fire.’

00:00 Yeah. Rain and Rust go together really well.

00:00 They do. You can start with some regular metal and put it up. By the time you know Rust it’s going to be rusty.

00:00 the other thing I wanted to run by you – by everybody – is how interesting would people be in having an Amazon flash briefing that is this show. What I’m talking about is, if you don’t have an Amazon Echo, there’s a way to ask it in the morning – you can ask it whenever but I think the idea is in the morning – ‘Hey, what’s my news today?’ While I’m brushing my teeth, getting ready for work, whatever. Or just sitting down at my desk and I’m not ready to work yet. You could ask for your flash briefing. You can configure different sources, like Reuters or NPR (National Public Radio) or whatever. I was thinking it might be really fun if we took our little items and shipped one of them per day as a flash briefing. Then everyday people would have a thing that they talk about for a couple minutes from Python.

00:00 Yeah, we should do that.

00:00 Sound fun? If people are super into this, send us an email or something on Twitter and letts know.

00:00 Yeah, let us know.

00:00 If not, then I won’t write it.

00:00 If we do it, then I can get an Amazon device as a business expense.

00:00 Absolutely. I think that’s totally great. The Echo Dot is just as functional as the full, expensive one. It’s just that the speakers aren’t as good. But it’s like $45/$50 for one of those things. It’s not outrageous.

00:00 Yeah and everybody’s got them on sale for the after-Thanksgiving thing.

00:00 Alright, cool. Well, that’s all I have for us.

00:00 Me, too.

00:00 Once again, thank you everybody for helping this show be one year old. It’s really awesome.

00:00 Yeah, thanks.

00:00 And thanks, Brian. Catch you next time.

00:00 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 pythonbytes.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.

Back to show page