PEP 8 Python

00:00 In this lesson, I’m going to show you some settings you can change so that it becomes easier for you to write PEP 8 compliant Python. PEP 8 is the dominant style guide in the Python world, so it’s widely used in the community. It’s kind of the general recommendation or best practice, so it helps to adhere to these standards and it makes it a lot easier to collaborate with other people if everyone is following the same style guide.

00:24 I’m going to show you some tweaks because the style guide is pretty prescriptive about how the whitespace should be formatted, so I’m going to show you a couple of tweaks you can make to make it a lot easier for yourself to write beautiful and PEP 8 compliant Python just like Guido wants you to.

00:40 So let’s jump right in. For these changes, we’re not going to make them in the user settings or in the global settings for all file types. But instead what we’re going to do, we’re going to change this here in the syntax-specific settings.

00:55 These settings would only apply to Python files. And the way you can make sure that you’re getting the right syntax-specific settings is by actually opening a Python file, so you want to make sure that Python is selected down here.

01:07 And then you can just go to Preferences and click on Syntax Specific, and this will bounce you to the settings screen. It should say python.sublime-settings up here and that’s how you know you’ve got the right file.

01:18 So, this is where we’re going to apply all of these changes that are going to be Python-specific. The first set of changes will be concerned with better whitespace handling.

01:28 There are a couple of recommendations on how to deal with whitespace in PEP 8, and we’re going to change these settings now so that it becomes easier for you to adhere to that guide, and some of it is actually going to be done by the editor itself so you don’t have to worry about it at all.

01:42 The first setting here is the "tab_size" setting, and we’re going to just set that to 4. And that means that a tab character is equivalent to four spaces.

01:52 We’re going to combine that with the "translate_tabs_to_spaces" setting. We’re going to set that to true, and by doing that, it basically means that instead of using actual tab characters we’re going to use spaces—so like, a combination or a string of four spaces for every tab that we insert.

02:10 And that’s kind of the recommendation in PEP 8. Now the next option we want is called "trim_trailing_white_space_on_save", which is a bit of a long one. And this is going to do exactly what it says.

02:24 This is going to trim any trailing whitespace at the end of lines whenever we save a file, which again is highly useful to avoid merge conflicts when you’re working with Git with other people and people are editing the same line and sometimes you can get these extra spaces and they just kind of screw up the whole process a little bit, so you want to make sure you don’t have these. And they really have no purpose, usually, so you might as well drop them. And by the way, if you’re wondering how to actually find these settings—well, you can just click over here into the defaults and then just search for that.

02:53 You can hit Command + F. And in this case, I would search for trim_trailing_white_space, and you can kind of get an explanation for what that does and the exact name of that setting.

03:03 So, you might as well just copy that over and that would save you some typos potentially. And actually, we want this one here too,

03:11 so I’m just going to copy that over. So, PEP 8 also recommends that Python files should end with a blank line to ensure that POSIX and Unix tools can process the file correctly.

03:21 And so just to make sure you never have to worry about this very interesting aspect—again, we’re just going to put this setting here and set it to true and then that’s going to take care of that for us. All right, so I just want to show you real quick what that did for us now.

03:36 When I switch back to some code here, it doesn’t look all that different, but what this setting changed is that when we insert a new tab character here, it’s going to make sure that this is not a tab character, but this is actually four spaces for each tab, right?

03:51 And you can see that setting down here as well. So, this is just going to set a default for new Python files. And then also, if we have extra whitespace here at the end of a file or, you know, even on a blank line… Like, sometimes this stuff just happens and if you’re not aware or if someone else like a coworker introduces that, they might not be aware because they’re not using this "draw_white_space" characters settings, right?

04:14 So you might just end up with all these extra characters at the end of your lines that you don’t really need, and that can lead to conflicts when you’re working together on a Git repository.

04:25 And now what happens with the setting we turned on, every time I save the file Sublime Text is actually going to cut out these extra whitespace characters here. Just to show you that again, I’m going to add a bunch more again, and I hit Command + S and Sublime Text is going to remove them for me.

04:42 So this is a really handy feature just to make sure your files are formatted consistently. And then the last one was here, when we scroll all the way down at the bottom.

04:50 So now you can see here, I don’t have this newline at the end, which means we’re not ending this line with a newline character, which can confuse some command line tools. And now when I save the file, this is going to cause Sublime Text to actually add that newline character for me. So, you know, the next line—we’re going to be starting on a blank line here.

05:09 And again, that’s something that can just drive you nuts when you’re working with other people in a repository and it’s inconsistent, right? Like, someone adds that, someone else removes that, so it really helps us if everyone is using the same settings here and just making sure that you’re having these newlines at the end like they’re supposed to be in the PEP 8 standard.

05:29 And also, this is a super boring thing, so you don’t want to have to worry about that. And personally, I just want to make sure that tools are doing the right thing.

05:35 I have to set that setting once, and then I never have to think about it again. Another helpful feature—and you’ve seen that before—is the "rulers" setting.

05:43 We’re going to bring that back for Python as well. This adds these vertical lines at certain columns in the editor code. The recommendation in PEP 8 is to actually use 72-character line length for documentation strings and 79 for any other kind of line.

06:03 And so what this change added is, here, these two vertical lines that are going to show us exactly when we’re getting above this line length. So you can see here that this is actually too long here, but in terms of the code, it’s actually formatted correctly, right?

06:18 Like, we’re not going over 79 characters. And so with the line length—it’s a common point of argument where some people, they don’t really see the point in a relatively low limit like that.

06:28 For me, the biggest reason is that it’s just nice if you don’t have to scroll around horizontally. So for me, it just makes sense to limit that and especially if you’re doing code review and using a tool like GitHub for that, it’s just difficult if you have to constantly scroll around horizontally and just kind of, like, limiting that.

06:48 And also it makes it easier for people to view multiple files at the same time side by side. And there are a couple of good reasons to use that setting. It’s a PEP 8 recommendation. But of course you’re free to pick any other setting that works for you. As long as it makes sense in your situation and with your team, I think that’s totally fine.

07:07 Okay! So, speaking about line length, there’s one more feature I want to show you here. What I like to do a lot is to actually edit two files side by side. Often, I will open up the test files and the implementation code at the same time.

07:23 There’s actually a way to change the layout here in Sublime Text. You can just change that to two columns and then you’re getting these two files side by side here.

07:35 I just need to arrange that for a bit. Right now you can see here we still need to scroll and it’s not super convenient. We see parts of the code at the same time, but it’s not super great.

07:45 We can get rid of the sidebar and we can do that by pressing down the Command key and then hitting K + B, and that’s just going to slide out the sidebar. And we can bring it back in the same way. So, it’s kind of a good shortcut to remember.

07:58 And that’s going to give us a little bit more space here, but still it doesn’t really fit here, so I might have to crank down the font size a bit, but then I can actually view these files side by side. I don’t have to scroll vertically—or, I have to scroll vertically, of course, but I don’t have to scroll horizontally, and that’s kind of nice.

08:17 Now this might not be possible under all circumstances. For example, what if you’re using longer line length and you get those scroll bars back and then it becomes kind of hard to read that code.

08:28 Now, there’s a way to change that too,

08:32 and that is by enabling word wrapping. So again, here in your Python-specific settings, or you could also put that in your user-specific settings, we’re going to enable word wrapping by setting this "word_wrap" option to true.

08:48 And then I like to wrap at 80 characters because, again, that’s compliant with PEP 8. I’m just going to save that, and now when I switch back to this file… Let me just zoom out for a bit so that I can actually fit these two at the same time. So now when I switch back to this file and actually have a line that goes past the 80-characters limit, then Sublime Text is going to render it in a way that actually wraps around this extra content. And you can see here it’s a wrapped line because it doesn’t have an extra line number here. That way, I’m never going to have to worry about having these horizontal scroll bars here and it just makes it easier to edit two files at the same time.

09:28 I only have to worry about scrolling vertically, and not horizontally. Let’s undo that. Okay, and if you want leave that column mode, there’s actually many more columns settings you can set up here.

09:41 You could even do a grid of four of these, which again, looks very interesting. You can just go back to the single column layout, and of course, there’s also a shortcut and that is worth remembering because it makes everything a little bit easier. So you can just switch that back, and then with Command + K + B, we’re going to bring back the sidebar and then we have our standard setup again. Great! So, just to recap, now we applied a bunch of settings that are specific to Python and that are specific to writing PEP 8 compliant Python. So, this should really help with making your Python code look nice and kind of follow the best practices so that a lot of these things are just not going to have to be called out by a linter or a code style tool because the editor is going to do the right thing for you.

10:26 I think that really helps because once you’ve configured something like that, you never have to worry about it again and it’s just always going to work for you in the background and it’s going to make sure your Python files look the way they should look.