Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.
This is episode 52, recorded November 15th, 2017. I'm Michael Kennedy.
And I'm Brian Okken.
And we got some awesome news for you. But hey, Brian, just want to say happy birthday, man.
Oh, yeah. Happy birthday.
Yeah. So this is the 52nd episode of Python Bytes. And if I recall, I don't think we skipped.
I'm pretty sure we did not skip a single episode. We shipped the entire first year.
We shipped an episode every week. And I think that's pretty awesome.
That is cool. Even around Christmas and stuff?
Yeah. I think we somehow recorded ahead. Or maybe we missed one. But I think we did it.
Okay.
So pretty exciting. And 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.
Yeah, definitely. Thank you. And we had a whole bunch backed up. So this episode is two hours long and it has 52 topics.
That's right. So you guys, just pause it now, get a coffee, settle in, or whiskey if it's late.
No. Actually, we're going to keep to the same format. All right. Cool.
So before we get to our topics, though, I just want to say thank you again to Digital Ocean as well.
They're another reason that this show is going strong.
Digital Ocean, 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 slash Python.
Tell you more about it later. Right now, I want to spend a while on APIs, Brian.
Yeah, I've got APIs on the brain right now. So we'll start with a new project. I don't know if it's new, actually. A project called Tavern.
It's like a drinking game or something?
No, it's testing RESTful APIs. So I don't know why it's called Tavern. I'll have to ask him about that.
It's a really cool project, though. I checked it out. I like it a lot, actually.
Yeah, so it's at tavern testing dot GitHub dot IO. Like I said, it's a RESTful API testing. And what it reminds me of the most is PyREST test, because it uses a YAML format to describe the tests and describe what sequences to go through.
So it does have like one off tests where you could just either post or gets from a URL and then determines whether or not. 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 with integrated with pytest.
That's really awesome. So you basically describe, I want you to call this URL. It's going to be a get and you expect to get kind of this thing back and then you can just assert against it. Is that how it works?
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 I really like, even though it takes up a lot of space, the YAML takes a lot more space than like a little test function.
But it's very readable, especially if you have if you have an editor that colorizes your YAML files. And I think it's good for especially you can discuss it with non programmer people. So that's one of the benefits of that.
OK, yeah, that's really cool. Yeah, that's true. You can give a YAML file to a non technical person who is like sort of a requirements gatherer, business analyst or something or domain expert.
They can say, yeah, OK, these are the things that let's slot in here. Right. Or to the person who built the API.
Like, for instance, the sequences, you can say, OK, here's the kind of the test is called this. And this is sort of the sequence we're going to go through.
First, you log in and then you have to do this. And there is also with a lot of sequences, you have to collect get information like tokens or something from from the server.
And Tavern allows you to save those tokens as variable names to use later in later tests, which is nice.
Yeah, that's really sweet. That's Tavern. Tavern sounds really cool. Definitely worth checking out.
The thing I want to talk about is not for testing APIs, but consuming APIs, calling APIs.
What if you weren't looking at this document or sharing, just like thinking of like, hey, I'm going to call an API from Python.
What library do you think you would use? Oh, requests.
Obviously, everyone uses requests and requests is one of the absolute most popular libraries since downloaded an insane number of times.
What I find myself doing a lot when I know this is like 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 is I'll create like a class or some module that will model all the actions that you take against that API.
Right. Like log in or, you know, get courses or whatever your API is about.
Right. And you sort of put use requests to implement it.
But deep down, you know, you kind of bury requests and hopefully you've got some like facade sort of class or module in front of it.
So I want to talk about this sort of up and coming project that does that all at once for you, which is really sweet.
And it uses it with decorators called Uplink. Have you heard of Uplink?
Not until you listed it today, but it looks really cool.
It's super cool. Right. So let me just describe like real quick how you use this.
So imagine I want to call the GitHub API.
I need 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 users function.
I might update a user and so on.
So what I do is I create a class, call it whatever you want, derived from a certain base class that comes from Uplink.
I had to add headers decorator to the class.
I say accept the right funky content type.
And 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 at get slash users slash curly username.
And that curly username there maps to the argument.
So when I call it, I say GitHub dot get user.
Yeah, Mike C. Kennedy is my username there.
And it actually directly pulls that into the little URL in the decorator and passes it.
Oh, this is cool.
That is cool, right?
And they have another example for updating a user.
That's a patch call.
So you say at JSON at patch.
And then the arguments to the method, you can pass in just like a body of basically KW args.
And that becomes the body of the patch submission.
You can also say access token colon query and use the type decorator in Python 3 to decorate as a query.
So then I'll go question mark access token equals what you pass as that argument.
This is so smooth.
Wow.
I really like it.
So if I'm building like a super structured API that's got really strict, restful requirements like this, I'm definitely going to check out Uplink.
I'm going to definitely watch this.
This is neat.
They have a little warning in there that says that it's in the early stages.
But that might be a great way for other people to get involved if they want to help out and push this further.
Absolutely.
So that's definitely a warning you want to be careful about.
They say it's not quite production ready, mostly not because it doesn't work, but because they think the API may change.
They don't want to break your code.
So I think that there's an opportunity here.
There are so many people that say, I really want to get started open source.
And they look at Django or CPython.
I'm like, whoa, this is complicated.
And changing this is really hard.
Something like this, you could totally contribute to a project like this without getting overwhelmed in the early stages.
So check it out.
Yeah, definitely.
Cool.
All right.
So let's switch to a totally different topic and talk about REST and APIs.
Yeah.
So I wanted actually 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.
But yeah, thank you for submitting that.
That's awesome.
I saw that coming as well over email.
There's an article called, I've got it turned around, using JSON schema, which I hadn't heard of before, using JSON schema for REST API endpoint testing.
And the idea, had you heard of JSON schema before?
I have heard of JSON schema.
It's basically a way to say my, it's kind of like what your test does, but at a different level.
You 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 haven't ever used it.
So like, I pretty much have exhausted my knowledge of it now.
The example of it, they do a Django, which I don't really know Django.
So I kind of read that anyway, but I don't think that's necessary.
I think you could use this for anything.
But the idea is you can implement a schema to describe what your data should look like and then actually serve that within.
So within your, on your server code, serve that as well.
And then for your tests, you can grab the schema and then grab, grab whatever data you wanted and validate, use a test to validate that the data you're getting it adheres to the schema.
And then you can also go out and make sure the values are correct and things like that.
But actually, I'm just curious what you think of this.
I think it's pretty cool, actually, especially if the API already has a JSON schema associated with it.
Right.
Like if they're like, here's the schema, here's the API, then you could just, okay, and here's how I test.
You know, one thing that might be interesting is like, it's interesting if you are the maintainer of that thing.
So that, you know, if the test break that you're verifying, you have to go and update the documentation or something like this.
But it's also interesting, I think, to point it 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 will document one API, the API will change, your stuff will stop working.
You're like, but I'm doing what they say.
It's like, you know, what has happened, right?
So if you knew the schema of APIs you depended upon changed, this is a good way to do that.
I think that'd be great.
Yeah.
Or you could even, I mean, even if you didn't have a schema provided to you, you could define one for.
Yeah.
It's usually not too hard, right?
Actually, that's a great idea.
And another thought with that is that it's not just RESTful APIs.
You can, anything that's using JSON, you can use that to test any API.
So.
Yeah, definitely.
It's very neat.
So check that out as well.
All right.
Before we get on to the next thing, I want to tell you where your audio came from.
It came from DigitalOcean Spaces.
So that's right.
Those guys are sponsoring this episode.
As I said at the top of the show, check them out at do.co slash Python.
Get a free two month trial of Spaces.
And Spaces is object storage and delivery in the cloud.
You know, things like AWS or Azure Blob Storage.
Sorry, AWS S3, Azure Blob Storage.
Things like that.
But way, way better.
Better pricing.
Simpler.
Things like this.
So I've been using it for this podcast.
I just recently, big announcement, switched to using it as the video delivery network for my courses.
So I'm trying that out on a few courses.
And that's been super, super smooth as well.
And what's really interesting, the way that I wrote the API for accessing the video files and stuff was I imported Voto 3.
That's the S3 AWS API.
So the API is compatible with S3, like quite literally.
It's the same API even.
Just pointed at some different base URL and you're good to go.
So if you've been using something like S3, you really owe it to yourself to check out DigitalOcean Spaces.
And do.co slash Python.
Very cool stuff.
Yeah, very neat.
And cool that you tried that out, that the API is compatible.
So far it's working really well.
I was thinking that some music could be nice.
I love to listen to music when I code.
Do you?
Yeah, all the time.
It's funny.
I find like a little bit of distraction kind of helps keep the mind focused.
I don't know.
People are weird that way.
I work in coffee shops as well.
And I like that as well.
But this is a different kind of music to coding.
So this is almost like music as performance art.
So there's this presentation called Programming Music for Performance, Live Coding with Fox Dot.
This is by Ryan Kirkbride at PyCon UK.
So this is a really short video, but maybe it will inspire some people to do.
Some similar performances.
And he's doing some similar performances.
Basically, he's up there writing code to dramatic, electric, classical type music.
And it's just, it's really interesting to see it go.
What did you think of it, Brian?
I thought it was really interesting, but I'm a little lost.
So I was hoping you could explain to me what's going on.
I wasn't at the talk.
So the video is not that long.
So I didn't see the introduction.
But what I think it is, is it's like, I'm going to show you some cool thing by writing a demo live and do it.
But instead of explaining it to you, I'm going to do it to a dramatic music and make it like a performance art.
Remember how we talked about code is like poetry a while back?
This is like code as performance art, I think.
Yeah, I guess I'll have to check out what all FoxDot is and how that works with that.
Yeah.
There's not, sadly, there's not that much information in this video because it's like partial and it's short.
But this is from Ian Watt, another listener suggestion.
And I thought it might inspire some of you guys out there.
So just, you know, short, have a look at this little video.
It's cool.
But be sure to turn on the audio.
Plus he did a talk without speaking, which is good.
Exactly.
We've talked about should you do live coding during your new demos.
This is like the opposite of a should I do live coding.
It's like only live coding and there's nothing else.
There's not even words.
Yeah.
That's good.
That's awesome.
But if we had like a weekly Python chat, there'd be words, right?
There would be words and video and audio.
All right.
So tell us about what you got going on this weekly Python chat.
I saw you were just on it, right?
Yeah.
So it was super fun.
So weekly Python chat is at, how did you get that?
It's at weeklypython.chat.
Nice.
But it's Trey Hunter.
And he's a, he's can't remember exactly what he does, but he's part of the Python software
foundation, but he's also Python instructor.
And 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 requested
by other people that listen and does like a little, like a under an hour or approximately
an hour video chat with somebody else.
But they're also, you can do live coding and then there's people in the chat room asking
questions while it's going on.
So it's a live thing, but then it's also recorded so you can watch old ones.
So yeah, the last one last week on November 9th was a testing Python with pytest.
So those with me.
That's awesome.
And I'm highlighting it because I want more.
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 could stay up for a weird hour or what, depending on your, where you
live in the world, but you can ask questions of people you wouldn't get a chance to otherwise.
So that's good.
Yeah.
Very cool.
Nice.
So yeah, check that out.
We got the link in the show notes.
So let's run this out with a bunch of mistakes.
I think that's a good one.
So our last topic is sort of, I think actually has a mistake in it.
It's 10 common beginner mistakes in Python.
So this comes to us from a blog post at a checkio.org or maybe better pull it up pi.checkio.org.
Have you played with pi.checkio.org?
It's like a video game for programming.
I think I have.
Yeah, I have.
Yeah.
It's funky.
So you basically, you have these little islands, you got to conquer the islands and you go,
the way you conquer them is by solving all the puzzles.
It's a little bit like Myst, but programming.
One of the things I think is really cool about playing the game actually is you solve some
little puzzle and then you see how everybody else solved it.
And then you get to see your style of programming relative to other solutions.
And it's kind of like code reviews because you can, you can comment on other people's solutions
and stuff.
Yeah.
So it's pretty cool.
Yeah.
So these guys wrote a blog post based on the mistakes they see people making from that
area.
And they said 10 common beginner mistakes.
So let's go through real quick.
Incorrect indentation tabs versus spaces.
Obvious.
But you can imagine if you come from Java that you don't know that, right?
This one's more subtle using a mutable value as a default value.
So like, you know, append to list and then you give it like a source list equals bracket bracket
as a default value.
That is a super bad idea, but not at all obvious why it's bad.
Right?
Because every time you call it with, without specifying that argument explicitly, it's going
to use the same list because that is initialized at like not quite compilation time.
But as Python sees and determines that method, it finds that default value and sets it.
It doesn't actually recompute it every call.
Yeah.
That's a, that's a fun one.
Yeah.
It's definitely fun and tricky.
Write a lot of comments and doc strings.
You know, my theory is comments, not so much doc strings, but 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.
Scoping, you know, if you come from a C based language with curly brace scoping, block scoping,
Python is different with its functions, scoping and closures and whatnot.
So that's definitely a mistake to be made.
One that I really love they covered is called edge cases first.
And you could have like a loop with a test that does another loop with another test.
And it 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 the loop.
And then you're going to do the edge case you're going to break out of and then the inner
loop.
And it's way less indented.
And, you know, that's one of the Xenopython things, but also just a great design pattern.
I mean, if you utilize, 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.
Oftentimes you don't have to check for, you don't have to make things bulletproof if the
function you're calling is going to check it for you anyway.
Exactly.
The easier to ask for forgiveness than for permission style is better than the look before
you leap.
We got copying.
Everything is a pointer in Python.
So the pointers means you may be sharing the same object, not a new one.
So it talks about that, especially around the lists and data structures.
Range is half closed.
Range one to 10 actually is one to nine.
Wrong capitalization.
So you're just writing like camel case, Java, C# style, or some, you know, JavaScript
style of naming for variables, classes, functions, whatever.
And then finally, using class variables incorrectly.
This one's a little bit interesting about class level variables and inheritance.
And you can check that out.
But they have nice little examples for all of them.
And as far as I could tell, there's only nine mistakes.
So I'm not sure what the 10th mistake is.
But maybe I read it wrong.
I read it twice.
I didn't see it.
So could be tired.
Well, I mean, if the range is one to nine, if it's...
Yeah, that's true.
It could be range, range one to 10 common beginner mistakes in Python.
Yeah.
Perfect.
All right.
So anyway, if you're getting started in Python, and you want to kind of level it up a little
bit, you know, check that out.
Or if you're working with new developers or mentoring new people, this is all good information.
Yeah.
And also, if you got somebody that works for you that's on Check.io at their lunch break,
they're not just goofing off.
They're upskilling.
So...
That's right.
Let them goof off on Check.io.
That's one of the best possible options.
Beats Facebook every day.
That's our six.
Do you have any news for us?
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?
No.
It's supposed to be twice as fast.
A lot of it's rewritten in Rust.
Use a way, way less memory than Chrome.
So these are all pretty exciting.
So I'm actually checking out Firefox Quantum.
I'm doing even the show from it this week.
Pretty cool.
So yeah, if that sounds interesting to you, check it out.
It sounds like Firefox might make a good comeback.
And they're definitely the most open source friendly of all the browsers.
So I love to see them actually alive.
Rust is that language that I'm always meaning to try to look at, but I haven't yet.
Yeah.
Well, it's getting dark and cold and rainy here in Portland.
Maybe you have a Sunday afternoon and you're like, you know, I just need to get a book and
just sit by the fire.
Yeah.
And rain and rust go together really well.
They do.
You can start with some regular metal.
Put it outside.
By the time you know rust, it'll be rust.
It's all going to go together great.
It's good.
So the other thing I wanted to run by you is by everybody is how interested would people
out there be in having an Amazon flash briefing that is this show, right?
So what I'm talking about, if you don't have an Amazon Echo, there's a way to ask it in
the morning.
You could ask it whenever, but I think the idea is in the morning, like, hey, what's my news
today while I'm brushing my teeth, you know, getting ready for work, whatever, right?
Or just sit down at my desk and I'm not really ready to work yet.
You could ask for your flash briefing and you can configure different sources like Reuters or
NPR or whatever.
And 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.
I think then every day somebody would have, people would have a thing that we talk about
for a couple of minutes for Python.
Yeah, we should do that.
Sound fun.
So if people are super into this, send us an email or something on Twitter and let us know.
Yeah, let us know.
Yeah.
If not, then I won't write it.
If we do it, then I can get a, like an Amazon device as a business expense.
Absolutely.
I think that's totally great.
Yeah.
So the Echo Dot, it just as functional as the full expensive one.
It's just the speakers aren't as good, but it's like 45, 50 bucks for one of those things.
It's not outrageous.
Yeah.
And everybody's got them on sale for the after Thanksgiving thing.
Yeah, that's right.
It's coming up.
All right, cool.
Well, that's all I have for us.
Yeah, me too.
Yeah, so just once again, thank you everybody for helping the show be one year old.
It's really awesome.
Yeah, thanks.
Yep.
And thanks, Brian.
Catch you next time.
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 Okken, this is Michael Kennedy.
Thank you for listening and sharing this podcast with your friends and colleagues.