Random things: order of imports is recommended to be future imports, builtin packages, 3rd party modules, project specific imports, each separated with a newline. When you have a keyword argument with a typehint, you add the extra spaces: def foo(str: arugment = “hi”):
I love the way that snake case looks in PEP-8. At first I was not excited about having to reach my fingers to do the awkward _ characters, but really, I only need to type those when I first declare the variable. Every other time I use that variable, I can just use my editor's autocomplete and just skip all the underscore characters and then just hit tab to accept the autocomplete.
If you use if foo[3:] == "bar" and you subsequently change "bar" to "barf", your code is broken unless you also edit the slice size. This is brittle. That's why Guido recommends endswith and startswith.
Tim I'm beginner at python and overall new to programming your videos are helping me a lot. I'm really interested in data analysis can you please make some videos on this topic
Hi Tim, i'm very new to tech and a career changer, i just want to say that the content here is one of the best explanations i've found scouring the interwebs!
Irony: in an article title "write proper python code" using "from os import path" as an example when Pathlib is by far the preferred solution for handling file paths
You missed the point. He was just giving an example that if you import multiple things from the same module then you should put them on the same line according to PEP8.
Amazing video, was wishing for a while you talk about it! One thing about the comments (ca. 21:55): Is there a convention, when the comment should be on the same line as the code and when it should be on a new line above it?
There's no real convention for it, you basically just have to use your own discretion. One way that I decide which one to do is that if I'm trying to write a comment about a block of code, I put the comment above the block of code, but if there's something I want to say about a specific line of code, then I just put it on the same line.
Yep, defo show it in work tomorrow... our team's coding is like NY subway wall, snake here, camel there, pascal on top and indentation may vary a lot.... Not to mention those long strings punching through the sides of 2 screens...
Won´t get as many views as normally, but this is such an important topic!. I always get crazy when I see people coding x == None or even worse: try: x() except: pass
@@Joe-zg9eq If you are trying something and it fails, you should handle the errors, ideally. At least you would log or state what's the error that happened. But passing after failing in a try block is considered very bad because of that.
Love your vids! Could you do any about when you would use classes because I do get confused slightly.. maybe through doing a project - that would be ace!
Unexpected banger. As the expression (roughly) goes: "any fool can write code that a computer can understand, the challenge is to write code that a human can understand"
I do programming in python on a daily basis and i really do not follow most of the pep Guidelines as python itself is not really following their own standards too. The best tip you also mention is, consistency. I do camelcase for normal var, for class and function i follow the pep with the underscore.
What do you mean python is not following their own standards? Maybe you can deviate from PEP if you work on projects by yourself, but if you work in a team you really all have to follow the same styleguide otherwise the codebase becomes a mess. So why not follow PEP. Most IDE's can automatically check for it as well.
@@pietheijn-vo1gt no you missed the point, I do follow the pep, as in some cases it could cause follow up issues if you do not. But considering Naming vars and defs it is not that important but consistency through out the script. When you write camel case var instead of underscore, no Big deal. In bigger projects you do follow the standard AND what the team deside, if there is a preference to write vars like this and that. I am really only referring to naming, nothing more ore less. If a programmer cannot read that, he /she is maybe not a programmer. The key word is consistency. Regarding there own standards, when you read the peps its sometimes a mess what is proposed and what not, what is adopted what not, sometimes it changes..i found it quit hard to read. I read one pep where python itself was not consitent - but sorry i cant remember what was it exactly.
@@Richard_GIS I missed the point? You literally said "i really do not follow most of the pep Guidelines". Maybe you missed the point? I think every team should follow PEP and only deviate if there is a very good reason to do so, everybody agrees and the code linters validate the deviation too. I have contributed to a few open source projects and they tend to use linters that simply reject your commits if it doesn't pass PEP. I haven't found anything inconsistent in PEP so I wouldnt know what you are talking about. But on the other hand PEP is very comprehensive and humans can make mistakes so it wouldn't be weird if there were a few inconsistencies. If you spot them, just report it.
Just some random information I find that when I use double quotes that it allows me to use words like in or is . For example print("spike is a good dog ") . Indentation in python doesn't make a lot of sense to me . I know everything after the colon is indented but what I am talking about is why . I tried to have a buddy of mine explain it to me but it is still clear as mud . He says that it executes each line of code in order of the indentation . While that may be true it does not make a tone of sense . So what does the computer recognize def blank(): it would throw an error if I didn't write pass .
Thanks for your expertise. At 22:35 it appears that you're saying if x = False or if x = 0, "if x:" will trigger. Isn't it the opposite? The shorthand "if x:" refers to True or something > 0, depending on the object reference.
i didn't know about the startswith thing either, good to know. i've seen it around used a lot. question though, for function names that are multiple words, do these act similarly to variable names as in they are snake case as well, or is there some other way of denoting functions as opposed to variables? also, do we treat lambda functions any differently in this regard if they are stored in a variable?
Hey man, this is random but what chair is that? I have the exact same desk as yours (the table top and Alex from IKEA) and have been struggling to find a chair that fits them for a while now. Is your chair comfortable? if so do you mind giving me a link so I can get a similar one?
It’s a great chair, absolutely love it. It’s called a Herman Miller Aeron chair, I have the classic version but they now have an updated one with ever more features. I also have a head rest which I bought separately
Imports should be grouped in the following order: 1. Standard library imports. 2. Related third party imports. 3. Local application/library specific imports.
Interviewer: "Why were you fired from your previous job?" Me: "Something i did at work" Interviewer: "Which was ?" Me: "Indent camel case with tabs in python in lines with more than 80 lines" Interviewer: "Next please"
I think it is much more easier for viewers to follow a 25 to 30 mins videos long video rather than a 6 videos long video. And subdivide them into different small topics
The class variables should still be the same as the normal variables, in this case snake case, but if you mean the class name the class name should be a pascal case like class ClassName
@@sherluck_code I ment like self.my_variable, and the question part is just in general. Idk i remember somewhere i saw that type, but not sure it was just a user preference or it was specific to other programing language.
One of the things I hate the most from Python y how much you must trust the developers. It's incredible there is no way of making a variable constantant!!
I'm new to python and coding. Is there value to having it defined as a constant vs. just capitalizing it. If it's capitalized then you should know not to change its value right? Or is there something else to it?
I am still a noob but in my limited experience its best not to use black in case of a collaborative project with git. Goodluck merging commits on using black. Auto format makes your life hell on merge
Is this guy reading minds, I was literally watching a seminar by uncle Bob on writing clean code , and he posts this video . CREEPY!!!!!!!!!!!!!!!!!!!!!!!!
I would use more descriptive names and if I needed variables of the same name indexed I would prob store them as a list instead: vars = ['x', 'y', 'z'] and access them like print(vars[2])
