8 Python Coding Tips - From The Google Python Style Guide

I love generators. They are memory cheap.

"Having readable code is more important than having efficient code". I definitely don't agree with this for my embedded world. Efficient code is often required. However, that list comprehension is horrible, I agree, but could easily be made readable with a comment. One of the few good uses of a comment, to explain something not readable, that has been done for performance.

Cool video. Nice to go over best practices to avoid spaghetti code 🍜🍝

What kind of Python he is using? Never saw def foo(my_list: list....) -> int?

Great , Thanks I was searching for this video

If you absolutely need to, using a property is the Pythonic way to deal with it!

@arjoncodes can’t stop watching your content. Truly amazing stuff. If you ever get chance, could you make videos on api development and good practices around that topic please - thanks

I love being a mere mortal. By the way, thanks mate.

There is no perfect way to code. Just dont be sloppy. Google isnt the king of the world, they provide a service, and the style guide is probably informed by their particular business

very insightful video

A1

I've been writing Python code (among other languages) at Google for many years, and I definitely write better code since I started working there. Here are some ways that the way I write code changed:

* No code is temporary. Assume anything you check in will be used in production, because someone might decide to do so. They won't ask you.
* Code isn't useful if you don't have proper unit tests. You literally can't check it in without tests.
* Clear is better than fast. Clear is better than brief. Clever code and implicit assumptions are the first place you look to find the bugs.
* Your tests are your spec. Anyone is free to change your code; the only way to ensure they know what it is supposed to do is to test it properly.
* A given commit can EITHER refactor (in which case your tests do not change) OR change functionality (in which case your tests demonstrate the change in expectations). Never do both at the same time. You eliminate most mistakes this way.

It's not in the public style guide (because it conflicts with pep8), but 2 spaces instead of 4 is used across all languages. It sounds dumb but once you go 2-space you will never be able to go back. Cannot unsee. 4-space feels like the old 8-space standard. Cannot unsee... Cannot go back. My eyes are ruined forever. 2-space it must be forever...

I have a doubt with the imports, if it is true that sometimes it is valid to know where a class or function comes from, there are times when it seems obvious to me, for example, I will not import "from django.core import exceptions" then use "except exceptions.ObjectDoesNotExist"... or, "from modules.mymodule import serializers" to use "serializer_class = serializers.MySerializer" in my ViewSet. Sometimes I find it unnecessary to do this.

My python mentor.
Why didn't i find you ever since.
Keep up the great content.
I am really learning alot.

Great video, it would be nice to hear your thoughts on Google's doc block style guide, I've noticed in your videos you use the more simple one-line explanation docblock (which may be for keeping the lesson easier to understand). I come from a PHP / Java background so when picking which doc block style guide to use, Google's felt familiar to me compared to phpdoc (summary, params/args, returns, throws/raises).

An interviewer raised a question to me that doc blocks may be redundant if you use strict types, type hinting and DAMP naming styles. I get his point but it's hard to undo years of habit-formed documentation because it just doesn't look right anymore (also can't automatically generate an api doc or provide extra info in IDE's when hovering methods etc). Be good to know where you stand on this :)

Doesn't it increase the memory usage when import an entire module and just one function is used? 🙃

the list default arguments have been useful to me when writting recursive code though. or was i doing something very silly? doesn't happen often, but tree traversal is one case.

Why is Python so terribly slow? ... Probably I got too much used of the speed of PHP.

The good MS / Java devs transition to python well but others tend to struggle so this provides a credible documented way to approach things.

Whats a "physical computation?"

really appreciate your effort. wondering if you could make more video about this topic

We did this on my team with Google's JS style guide.

Just keep in mind that the order of "for" loops and their variables stays the same when going from loops in a comprehension to 'normal' nested loops and vice versa. So "[bla for x in range(5) for y in range(5)]" translates to "for x in range(5): for y in range(5): bla". Since I had learned this easy rule of thumb from someone on stackoverflow, I don't find these list comprehensions hard to read at all. At least I'd doubt the traditional loop code looked so much better.

Thanks for all these tips! As an extra tip, I would suggest to write short and clear functions that can be used for creating bigger functions. Basically this way, you won't be repeating any code you write and each of your functions will have not much code, so they will be easy to read.

Great stuff!

really interesting share Arjan! Great video man!

About the minimizing the usage of try/except clauses when you don't care about the error-- If you plan for another part of your code to deal with an error, I'm of the opinion that explicitly reraising the exception (with `except: raise`) is better than relying on the built-in behavior for Python to reraise an exception. This way, you are clearly acknowledging that a part of your code can raise an error and that it is handled elsewhere.

If I'm looking at some code that calls some function which can raise an error and isn't inside a try/except block, I have no way of knowing if that error is caught elsewhere in the code or is just assumed to not raise an error.

The thing about mutable default values in functions is actually useful for memoization. The parameter's name should indicate its purpose (eg "memo"). It can start off empty or contain a base case or two. Thoughts?

Fuck Google and their fucking style guide.

I got caught in the nested loops inside list comprehensions, lol

I’m of two minds regarding list comprehensions.

On the one hand, reading code that uses functions like map and filter for operations on collections can be easy to follow, if you’re stringing together operations, it starts looking ugly. (One solution, perhaps, is to use packages like toolz that provide functions for piping, currying, and composing functions—but how pythonic is that?)

On the other hand—and I’ll admit that my affinity for functional programming is really showing here—I don’t see that even a moderately complicated list comprehension is that confusing if formatted in a way that’s easy to understand. After all, list comprehension syntax resembles set notation; placing each for expression on its own line clarifies what’s going on quite a bit. I think that approach may make sense within a shop whose culture encourages thinking that way.

In either case, there comes a point where readability is compromised. In those cases I find it useful simply to write a finction that returns a generator for the collection (using yield): sure, it’s not as declarative (and I really prefer—non-pythonically?—declarative over imperative code), but it might be easier for others to maintain.

Google teaches R in their Google Data Analytics Specialization and talk about Using Python. Python is the most preferred language and they taught entire data analysis and viz in R.

Great video!

Would be cool to see some more "Insights" into the python interpreter because a lot of silly mistakes like the default variables and variable nesting are due to the nature of Python being a dynamic interpreted language.

For getters and setters could you show examples when they can be used neatly with @property Decorator?

My wife (a google employee) thought I've being watching a couples therapy video

I think the guide is very good for people who build a library or at least create code that other people use within their code.
IN our company we have code that runs on our customer's servers, so the program must never crash and must always give some response our customer can send us. This means that we have certain places where we actually have to just catch every Exception that might come, especially those we don't expect.

The only thing where I disagree is that you rather do not put assertions in your code but in your unit tests. Let me point out that there is a different kind of assertions that does not belong into a unit test, e.g. assertions about intermediate results and loop invariants. Moreover, assertions in your code also function as an executable documentation what property is expected to hold at this location in you program. This can give you further insights about how the code works. Since this "documentation" is executed, it typically does not rot as pure text does in comments. Personally, I use assertions a lot and combine it with advanced testing techniques that use randomization. I was already often surprised that assertions failed in my code I never thought possible, thus finding wrong assumptions and design flaws.

Great video, Arjan. Fully agree with points about properties and getters/setters.

Thank you for giving away your golden thoughts...

Background music is good. Can you share it's link as well ?
Btw, great content : )