These are great tips.

I do the opposite regarding indentation : 4 spaces everywhere 2 spaces is not enough to inconsciously distinguish the different blocks

Thank you. All those bullet points are amazing. BTW, as soon as I left Google, I got back to bigger indentation space (like 4 spaces). I prefer to reduce the nested logic rather than letting me add more complicated nested code with 2 space indentation... Unless I write in lisp.

Happy to hear you like the videos!

I was about to write the same but you’ve explained it very well already.

Those are good points, thanks for the in depth explanation. I’ll definitely experiment more with using asserts like this and it might actually be a good topic to talk about in a future video.

Very nice comment! Thx. Glad Arjan take you up on these aspects

assertions are best only if they put separately in the code, because if someone runs the code with -O flag, then this can lead to disabling the assertion execution and can produce unexpected results.

​@@shera2667 Generally, I disagree with that assertions should be separated from the other code. You can see assertions as an executable kind of documentation which are embedded into your code. If you only care about functional correctness, and you have assertions without side-effects, you should be fine. However, if the run time makes a difference, assertions may be problematic, here I agree.

An alternative way is to have the argument default to None. The function checks for this value, and replaces it with the current time (or other dynamically-computed value, as appropriate).

@@lawrencedoliveiro9104 Yes. That's what I've seen recommended elsewhere.

Glad it was helpful!

@@ArjanCodes Was a bit disappointed not to see any comment around try-else while discussing exceptions. Per Guido/PEP the entire purpose is to enable minimizing code within the Try statement. It's just a little something extra that helps the programmer cope with letting go of a bad behavior :D

true, this is amazing

Yes and no. Working in teams means not everyone is used to it, but everyone will be used to classic for loops. And when using code formatters, the classic fors will be indented and looking very ugly, so there is a solid chance they get refactored. Just to keep the example, you could write seperate from itertools import it ... x_y = it.product(range(5), range(5)) for x, y in x_y: ... # or put the for back, but now more easily to grasp into the list comprehension Some might not be used to this a bit more functional approach and just put a part of the for looping into an own function call (like a def x_y_pairs(): return ...), but this will help the reader more (and might be even the better way longterm anyway).

I have been trying to avoid "for" loops unless there are side effects within the iterations. Not only do I avoid "for" loops, but I also avoid mutation. The nested list example in the style guide does both. For nesting, I sometimes use this pattern: items = [(x,y,z) for x in range(5) for y in range(6) for z in range(7)] results = [do_something_with(x,y,z) for x,y,z in items] Although in the above case, where the nesting is between independent iterables, I would agree that itertools.product would be better. And I use this pattern all the time, because I don't know a better way to "flatten" lists in Python: flat_list = [x for sublist in list_of_lists for x in sublist] When I need nesting between iterables that have some dependency, I might combine the two approaches: nested_items = [comma_separated_string.split(",") for comma_separated_string in my_strings] flat_items = [x for sublist in nested_items for x in sublist] results = [do_something_with(x) for x in flat_items]

The more I think about this, the more I think I should use itertools more. Maybe chain is the better way to flatten lists - what do you think?

You’re welcome!

Thank you Rahul, glad you liked the video!

Thanks, will do!

I would include an exception traceback as part of “some response our customer can send us”. Your subsystem writes logfiles, doesn’t it? Any exception crash should end up in there; tell them to send those.

Thank you, glad to hear the content is helpful to you.

Thank you for the kind comment!

Isn't it a DRY principle?

Googles docstring format pre-dates type checking, but it's worth noting that the most important part about documenting your parameters is that's the only place you get to describe what they actually DO, not just the data type. That said, Google's doc format for Go doesn't document args explicitly; instead you write it out as prose if needed. Honestly, I think it was the lack of types in python that originally made the doc format what it is, and now since we have ide integration for it, it's just handy.

Glad you like them!

In theory, but if you're always supplying the same constants every time you call a function, then you're not being explicit, you're being verbose. Overriding a default should signal that you're overriding "normal" expectations.

Explicit is better than implicit, but practicality beats purity. If mostly the use of the function is with one value of the argument and only seldom with another, or if you don't want to make users bog down on what to pass to that when they start using the func, then default values make a lot of sense

I'm wondering... It's it possible to go: from my_package import my_module.my_function? Because if you can do that, then you you still get the origin of the function without importing the entire module.

There is one advice that has stuck with me as a software engineer: write code to be read. Yeah, it is a few more keystrokes, but you will save other people time trying to figure out where something came from

I can understand the motivation for importing the module alone in large files, but that seems to me as overkill for smaller files (say

Thank you Kevin, glad you liked the video!

Thanks - I have no experience myself with embedded software, but that's interesting.

Interesting idea. I've assigned attributes to functions before just for that, where on the first read you have to catch the AttributeError and assign the initial value. Using the default value would make that a lot easier - if there isn't a catch to it that I don't see right now. 😬

I think i'd rather use a class for that, it seems more explicit to me and the memo table could be either instance or class -wide giving some flexibility, using the default argument in function (at least to me) looks a bit hacky and confusing (is it really intentional or complete accident altho this can be mitigated by appropriate naming) also it relies on users not passing anything into the memo argument which seems somewhat counterintuitive, you shouldn't be expected not to pass anything into an argument in my opinion

@@funkenjoyer The user could pass an already filled in memo table which would replace the default empty one. Passing anything else and the user gets what they deserve: undefined behaviour. A potential problem is that the memo table is unreachable. But when would you need to access it? Anyway, a class would solve that.

Sounds dangerously easy to accidentally mess up. Better to follow common practice here. Cleverness is where bugs live.

Python readability admin at Google here. I did the recent re-wording of the "mutable global state" section. 1. It is cleaner to use a decorator to wrap up a function with memoization, rather than putting state into mutable default values. 2. This is still problematic, since the cache can keep heap objects alive you wouldn't want to lifetime-extend like that. In particular, memoization-caches ideally should be scoped. In some situations, one can fix this with weak references, but their precise semantics is a bit tricky. Personally, I'm not a big fan of "memoization with global cache". 3. functools.cached_property is a good thing.

I'd create a function for each and then a mapper function to select which to use in a given case

I've seen two different solutions to unit handling: 1) use a package like `units`, `pint`, `unyt`, or `unum`. This solution is more robust in that you end up dealing with compound objects (with both a magnitude and a unit), and thus you can do things like ensure incompatible dimensions cannot be added together (e.g., meters plus seconds). The drawbacks are that the code often ends up rather verbose, and your calculated values are now no longer primitive types, which can make it harder to pass results to other functions or libraries. 2) choose a standard set of units across your project, e.g., meters, seconds, kg, and define these as variables equal to 1.0. Then you can define other units like cm, inch, g, relative to the standards. Do this in a units.py file so that you don't pollute the namespace. Then every dimensionful quantity you define (or read in from a file, e.g.) MUST be multiplied by a unit (or use the default unit), e.g.: # units.py m = 1.0 kg = 1.0 s = 1.0 cm = 1e-2 * m g = 1e-3 * kg inch = 2.54 * cm cm3 = cm * cm * cm N = kg * m / (s*s) # main.py from . import units x = 5.4 * units.m m = 1.0 * units.g An advantage here is that you can change what units are printed simply by dividing: >>> print(f"x = {x/units.m} m or {x/units.cm} cm or {x/units.km} km or {x/units.inch} inches") Or find ratios between units: >>> units.ly / units.km # 9.461e12 km in a lightyear This solution is a lot more flexible but a little more dangerous as it's up to the user to apply the units on definition/import and make sure incompatible dimensions are not being added. But you end up with regular floating point types that only ever get multiplied/divided, saving some cognitive overhead and interoperability concerns. Another caveat: it also won't work for unit conversions that are not just scalar multiples, e.g., temperature between C and F. In the end, this solution is probably useful for small-scale projects, but for larger projects, one of the aforementioned libraries may be better.

I've been writing Python at Google for a long time, and I gotta say this rule is my FAVORITE one. Yes, you're never more than one click away from the definition of anything, but the owning module is important information about what you're looking at -- it's effectively part of the name of the function or class, it gives context. Especially when you're reading code that someone else wrote, it is always more clear.

Just avoid wildcard imports, and you’ll be fine.

@@lawrencedoliveiro9104 do whatever you want, it's your code. But if you're working on a team, especially when a product like UKposts depends on your code being perfect, "you'll be fine" doesn't cut it.

@@TylerLarson I hope you’re not trying to offer up UKposts as an example of “perfect” code ...

@@lawrencedoliveiro9104 nothing is ever perfect, but we all try. Like I mentioned in another thread, I haven't had a single bug of my own make it to production in over six years, which I think is a pretty damn good accomplishment. I don't personally work on YT so I can't comment on how their rules affect things, but I can definitely say that my own code wouldn't be a 10th as solid as it is if it wasn't for the rules I had to learn to follow. Every last one of them was inconvenient, but looking back I can definitely see the wisdom. And today I wouldn't argue with any of the restrictions that my code has to follow.

I'd use the first one since it's more clear in my opinion. Neither of these pollute the global scope and everything gets imported (you just can't use it in the second case)

was thinking the same - you can find the origin of the imported function very easily if you wanted to, and as another commenter pointed out things get muddied when you use aliases anyways. importing functions explicitly from a module makes more sense to me.

As someone who works in a large codebase, we have standard aliases for modules. I think that makes a huge different, because no matter the file I am reading code from, if I see a certain alias, I know what module it is. In my opinion, aliases are problematic when there are not consistent; and that’s what code reviews are for

You win! :) Thanks, and enjoy the video.

If those functions are only called from the “main” function, why not make them local to that “main” function?

@@lawrencedoliveiro9104 for the sake of readability; there could be different types of functions and hundreads lines of code

Have difficulty navigating nested blocks? This is why I have editor commands defined to quickly jump between lines with matching indentation.

Is it this one? ukposts.info/have/v-deo/fn1oZZWYaqqptaM.html

@@ArjanCodes Yes, thank you. And thank you, for the most informative videos.

Definitely a good point. I think what also plays a role is the balance between keeping things consistent and doing things differently as an individual developer. The Google style guide is intended for Google's Python libraries and I'm sure quite a few different developers work on those libraries. So then I can definitely understand that they lean toward being more strict in their style guide (even if in some cases it's overkill), to ensure consistency and avoid discussion.

Very good point! I'm usually working in small projects, so it's fine for me when only I'm working on the code. But enforcing style-guides by linters is generally a good idea for co-working. It helps you keep the code clean 😂 IMO those tools should lint metrics that are more relevant to achieving a good software design and readability. Putting docstrings, having imports in the wrong order etc. is less significant than functions with too many params, classes with bad cohesion, high cyclomatic complexity, ... SonarLint usually helps me with that 😄

For long function/method calls, put the arguments one to a line, and give the whole expression a two-dimensional layout, e .g.: aqsis_output = ReasonablePerms.subprocess.check_output \ ( args = ["aqsis"] + extra + [self._filename], stdin = subprocess.DEVNULL, stderr = subprocess.STDOUT, universal_newlines = True, cwd = self._parent._workdir, timeout = self._parent.timeout )

Done!

@@ArjanCodes Thank you very much!!

I'm not entirely sure how well Python does tree shaking. But in addition to following this import guide, I would suggest to keep your modules relatively small. So if memory usage increases, I don't expect that to be a problem if you keep your modules at a manageable size.

From what I understand, when you import anything from a module it has to load the entire module even if you only want one specific part.

Isn't it better to keep things light rather than importing the entire module? I think this is ok in moderation

Apparently UKposts thinks I'm Korean, haha. I've updated the captions to English.

It's only under a few parts, but noted.

When an expression gets as complex as this one, a tip is to make it a function and add doc strings so the developer wanting to change this piece of code in the future (being you or someone else) has a nice time understanding what it is trying to achieve

@@christoferberruzchungata2722 It’s already in a function.

@@christoferberruzchungata2722 It’s already a large chunk of the code in a single function. Splitting it off doesn’t seem very helpful, when the error message is already supposed to explain what the check is trying to achieve.

If you want to see that snippet in context, have a look here

/ldo/aleqsei , in the method Context.Rib.motion().

There are some things tho that make code much more readable that don't sacrifice efficiency. Reasonable variable names for instance! The compiler would bake them down anyway. Reasonable comments just as well!

True: code is more read than it is written! BUT: it is also MUCH much more executed than its read! So I agree: Readability SHOULD be sacrificed for efficiency! But I'd say this is rarely the case that one has to do that.

@@ewerybody agreed

Using the most hacky solution to a very specific problem that only affects a single function over every single codebase that implemented it as an argument against a general case isn't very useful, like at all. Supposing that most code is actually just waiting for another FISR to come along would make for an incredibly buggy, unreadable, and probably badly performing as well, codebase. Write readable code first, then if, and only if, the program is too slow, measure what causes the slowdown and then improve that. If in the end you end up writing another FISR like algorithm, then yeah cool, keep it and document it well, but until then, don't write unreadable code.

There's no real performance difference between importing and using a whole module or just a function from a module.

​@@sadhlife there is performance difference, and more you're importing like this more "real" it is

@@clauseclause6640 prove it. I really, really doubt there's a difference. Post a timeit benchmark

@@sadhlife it's a basics of python optimization, it described many times in books, if you getting attribute of object, under hood you calling getattr, and it costs you something. But you can continue be doubt if you wish ;)

@@clauseclause6640 sure, there's extra dictionary lookups happening. But I doubt that makes even 0.1% of a difference in any program