5 Good Python Habits 

100000%

if I get a script w/o it, I freak out.

It’s good practice (like he said), a lot of beginners/beginner orientated videos don’t use it though, because either they’re not writing code big enough for it to matter (most beginners use a single file), or for the beginner orientated videos they just pass over it because it’s not really important for the scope of the tutorial, however I believe its function should be taught a bit more than it is…

Still don’t really understand so it’s like if the module is directly imported from the main file then run?

@@dt3688 Sorta. So, the purpose of the if statement is to explicitly check if your file is run as main (When ran directly the interpreter sets the variable __name__ to “__main__”, but when imported it’ll set __name__ to whatever your filename is.) In doing so, whatever you have inside that if __name__ == __main__ statement will be ran ONLY if you directly run that file/script. Otherwise, if you import the file, whatever you have inside the if statement will not be run. This is useful (mostly) for test code, or if your file is meant to run as both an import and a script on its own. This is to keep whatever imports your script from accidentally running the functions in the file. Ex: def PrintSomething(): print(“This will run”) if __name__ == __main__: PrintSomething() In this code, it will only print the string to your console if ran as a script directly. If you import it, PrintSomething() will not run. (Formatting may have broken for youtube with the underscores for name and main, but yk what I meant)

I would argue that this is _the_ most important reason to use a main() function. It's not just a way to make your code look better organised, it has fundamentally different semantics from just putting code in a top-level if-name-is-main

True, but you should never ever run a main function AND THEN run extra code in the global scope later, so namespace pollution doesn’t rlly matter.

I didn't think about that, the arguments in the video didn't convince me at all, but this is a really good reason to use a main funciton.

What do you mean by "pollution"?

@@AmodeusR I think he means having a bunch of variables exposed to the global scope is polluting it, and can be problematic when importing a module.

A way to avoid them becoming unreadable without resorting to loops is to split the transformations into multiple separate list comprehensions on new lines, and assigning the result of each line to a variable with a descriptive name to show what the intermediate state represents. Ideally you would use generator comprehensions as well for the intermediary steps and only convert to list at the end (if it's even needed in list form at all).

One major example I've seen, unless you've got a very descriptive comment attached or it's doing a super simple operation, don't put two for loops in one list comp

Exactly!

It depends how you use them. Variable Naming has a huge impact in readability as well. For example: taking the person names > 7 case, if we were to rewrite with more descriptive names it can convey a sense of reality and make the code more relatable to the readers. listLongNames = [ pp for pp in people if len(pp)>7 ] See, makes so much difference.

["["".join(letter) for letter in word if letter.isalpha()] for word in "why would you say that?".split() ]

I'm just learning python, but if you were to do this, how would you suggest you test your input parsing and sanitation itself? I'm thinking I'd have the '__name__' block call a 'parse_and_sanitise_inputs' function to do that (and pass its results to main), which could then be tested separately.

@@mnxs you would have separate files that use those functions to run some tests that test they do their job. You don't need a dedicated "parse_and_sanitise_inputs" function, for example if you want to check that you provided a correct number within a certain range, such as an age, then you would do a "parse_age" or similar function, that would check if age > 0 and is a number and return that number. I would use something like arg_parser in python

That's a useful tip if you're building a more complex script, but probably a bit outside what I'd put in a boilerplate.

Another bonus is containing the variables. You won't accidentally use a globally-scoped name in another function, if that name is local to the main instead

Thanks for sharing the benefits guys! I often forget to mention simple things like these when creating the videos as a one man team.

It's similarly useful if you're using asyncio.

list(itertools.compress(people, map((7.).__lt__, map(len, people))) or functools.partial(operator.lt_, 7). which I like because it tells people to stay tf out of your code.

@@DrDeuteron ahahahahhaha

​@@DrDeuteronlol

it's called duck typing.

@@DrDeuteron yes but the point of type hinting is to reduce the issues you have with duck typing. Duck typing is both a strength and a weakness of Python. And better type hints are more meaningful so it is encouraged to use type hints imported from the typing module.

@@kycklingmannen931 i agree, especially containers vs iterables, but what do you do for a function that takes floats, int, all the numpy versions, or arrays, matrix etc…is there super that covers all that?

I'm incredibly happy to hear you enjoy the type annotations :)

Definitely agree. I also think the example function was not "big," at only seven lines and two if statements. Breaking up big functions is often good, but I probably would have left this example function alone.

how about a video on unittest or the current most bestest argparse?

Some of these are definitely bad habits. Definitely much better to do it this way, by writing a unit test. Funny to mention "testing" but not use any built-in tests idiomatic to the language... It won't actually take more time since the execution environment will be more predictable and you avoid all the issues while having better design of code.

Came into the comments to add this. Comprehensions, whether list, dict, set, etc., are much more readable if on multiple lines and you can even add more conditions, though I would advise for moderation.

@@ValkoinenShiro I tend to be guilty of overdoing it; almost like I'm trying to win an award for fewest statements. There's a point at which a generator function is cleaner and more readable.

@@TheJaguar1983 "clever" is not a compliment in python

Whats the advantage of pass vs …?

@@NathanSMS26 I think pass is more visually obvious than the ellipse, but if you prefer the ellipse, then enjoy :)

Actually, the best practice is to throw a not implemented error so you don't forget about it.. Honestly though, it's too much effort. I always thought python should have a keyword for this, something nice and short that throws an exception.

​@@davidmurphy563 "assert false"

@@Zaniahiononzenbei Oh, that's a good one! I'm going to use that!

yeah but there is no point in calling a main from somewhere else! If you need to do that, the function you wrote is not a main.

@@philippk5446 Often there is a point, especially with scripts. Last week for example I wrote a simple script which sends a request to update a product. I called it update product and gave it a main. It's Django so the usual entrance is run() in terminal but I also call it from admin which runs main. Then I have another update products which loops through the products and updates each one. Point is, the same script is being called from numerous places - sometimes main, sometimes not - so, yes, there is very much a point.

The filter/map approach is nice to write when coming from other functional programming languages. You're right that they're not always as nice to read as list comprehensions, but in certain contexts they can make a lot of sense since they allow for greater re-useability than comprehensions. Say for example you already have a function that verifies someone is an adult like so: def is_adult(person): return person.age >= 18 And that you have a function that returns the full name of a person like so: def full_name(person): return f"{person.first_name} {person.last_name}" Then at some point you want to take a list of people, and get the full names of everyone who's an adult. With list comprehension, if you wanted to re-use your existing functionality you would write the following: adult_full_names = [full_name(person) for person in people if is_adult(person)] Whereas with map/filter since they already expect functions, you dont need to invoke them, just pass them as is: adult_full_names = map(full_name, filter(is_adult, people)) Obviously I left off the list() conversion in that, but in most cases with functional-style code you wouldn't be converting to lists very often, since leaving the data in generator form is much more efficient as each element can be streamed through multiple transformations without creating a bunch of intermediate lists. It allows you to write your code as if python was a lazy language like haskell, where values are only calculated when they're actually used/required. So basically I would use map/filter if I already have functions for the transformation I'll be doing, but if I would be having to write a lambda inside the map/filter, then I would instead use a list comprehension (or more likely a generator comprehension, again for performance reasons).

I was thinking about filter while I was writing the list comprehension, but the instant benefit of using the list comprehension for me was that I could write it out in a split second, while with filter I always need to hover over the function to see the little pop-up with the documentation to make sure I'm passing in things in the correct order.

@@LittleLily_ That is a very good point. In my example I pointed on using map() and filter() with lambda-functions. Usually those lambda-functions make code hard to read. I thing using existing functions is very clean Also I was talking about people, who is new at Python. So usually I can see my friends making map -> filter -> ... -> filter combinations. In such cases even using existing functions does not save readability. My point was that beginners sometimes make overcomplicated map/filter combinations that can be replaced with a single much more readable list comprehension

@@Indently that's fair enough. the order of the arguments for higher order functions in any language generally always has the function first and data second, as that way you can more easily partially apply the function, for example with python you might write this: from functools import partial def full_name(person): return f"{person.first_name} {person.last_name}" people_to_full_names = partial(map, full_name) And now you have a reusable function that can operate on any list of people to return the full name of all of them like so: full_names_a = people_to_full_names(people_a) full_names_b = people_to_full_names(people_b)

@@cosy_sweater "pointed" --> "punted" maybe?

The advantage is to support bad habits.

@@ThomasVWorm - as far as I now understand it, if you call the function from another program, it’ll not run anything in the __main__ section.

@@daveys no. The import statement executes all the code, which is why you do have functions at all, because it executes all the def-statements too. This all happens before you do call one of those functions. If the file is meant to be imported, it makes no sense at all to have code in the main body of file which you don't want to run. So with if __name__ ... you prevent code from being run which should not be there at all.

@@ThomasVWorm - Ahh, I get it…hence your comment about bad practice! Thanks!!

@@ThomasVWorm you're just no using it right.

I agree, but sometimes there's too much redundancy, and the expression is simple enough that's it's obvious at 1st glance what the single-char var is

try some itertools, though I don't know if that is formally functional. Don't forget lambda.

@@DrDeuteron Amazon sells some books about functional programming in Python, But Python isn't purely functional. It's object oriented. In a purely functional language, there are expressions instead of statements. To simulate looping, you need recursion. Since each thing is an expression in a purely functional language, each "if" expression needs an else clause, even when you wouldn't need one in a procedural language. That's because each expression must reduce to a value. So suppose I write this: if even n then n else n + 1 Then the number will replace the "if," "then," and "else" expressions. And the computer will remember the number until your program terminates.

​@@williammcenaney1331 week, if you're going to try, you'll need: sys.setrecursionlimit

Could have been a more clever approach, yes :)

you could also use filter an map in py, iirc

similar to how you'd write it in JS/TS: longNames = people.filter(p => p.length > 7) longNames = people.filter(p => p.length > 7).map(p => p.toUpperCase()) the lambda syntax in python isn't quite as nice, so I think that's why most people don't like using stuff like map/filter over list comprehensions in python.

The problem with list comprehensions is not the syntax but how you layout the comprehension. I prefer to put everything on a new line as it makes it more readable: long_names = [ p.upper() # list element for p in people # iteration if len(p) > 7 # condition ] and it is more readable then using filter and map.

@@LittleLily_ why does "p =>" appear in every call signature? what else is there? seems like redundancy...Guido don't like.

@@DrDeuteron Its no different to the |p| in the ruby example, it's just how you define an anonymous function with an input argument named p

👍

Obvious is a common synonym in the English language, you're more than welcome to be pedantic and picky about words, but it's a lot of typing gone in the wind :)

@@Indently Well, explaining something like this to a non-technical person might make you sound... full of yourself, if you say obvious often. It's not obvious to everybody!

This looks a lot more like IntelliJ than VS Code to me

It is (maybe?) PyCharm, not VS Code. You might be able to get it with some VSCode extension, but I think Jetbrains has a much better developer experience.

When you are making programs that are 1000+ lines of code, you'll realize how much simpler debugging would have been had you added type hinting / doc strings and breaking up functions into smaller ones. Granted his example of breaking up the code into separate functions was rather extreme, but he was just using it as an example. i don't necessarily agree with him on using type hinting when it's not part of the function parameters though.

@@resresres1 Definitely. You write a function which expected certain functions from an object, the type hinting gives you a hint that the duck typing will work (or not if you violate it) as intended. It doesn't matter whether the code is interpreted or compiled, it would achieve similar protections as you'd see in a language with a type system and type safety.

that syntax is incorrect

this is a much better way to make your program crash

That's pycharm

There's an extension in the settings that you can install

My only recommendation is that you plan your code before you write your code. Living in the moment is only advised if your program is as big as printing "hello, world".

It is indeed

@@Indently thanks for your fast reply! Btw I have a discord server made for friends who also learn python and your channel have great tips on how to learn python faster. So thank you for your teaching in a way! It is accessible and easy to understand :)

Solarlint extentions give clear check and hints, try it