5 Tips To Write Better Python Functions

In this video I’m going to be showing you 5 tips and tricks that can help you write better Python functions in 2024.

▶ Become job-ready with Python:

▶ Follow me on Instagram:

00:00 Learning Python made simple
00:05 Tip #1
01:45 Tip #2
06:32 Tip #3
10:04 Tip #4
12:31 Tip #5
15:43 Your thoughts

[shakapaker]

1. raise NotImplementedError instead of "pass" or "..."
2. always specify return types
3. use docstrings for extra info
4. force keyword args for complex functions with *,
5. use *args to collect variable arguments

[hellNo]

as a c/c++ enjoyer i must say that it warms my heart that specifying the return type not only is a thing, but a recommended practice

[FighterAceee]

raise NotImplementedError("Too drunk to think this through atm")

[hriscuvalerica]

Most of the time i use an iterable instead of the *args and **kwargs thingy in those types of situations.I feel it's more readable. I used *args, **kwargs when i needed to pass a function and some of it's arguments to a class instance to execute while a method was sleeping .

[Websitedr]

I'm always trying to find more "pythonic" ways to do things since behavior is different in C or Java. Even a simple for loop isn't the same in Python it's a "for each" and so much easier to use than for(i==0, i<condition, i++). Docstrings seems like extra work but when your code base gets bigger it's useful to have those notes in place.

[DrDeuteron]

Since you didn't ask, here are my tips for functions:

docstring for users

comment for devs

pass arguments as keywords (for devs--from Raymond Hettinger--If you don't know who that is, you're not a pystro)

single point return for successful use-cases

use guard clause to catch errors early and raise/return early

minimize branches (cyclic complexity).

only ONE purpose per function: break it down, use private helpers if needed) so devs never scroll to see the whole function.

all functions should be PURE: if it depends on state or mutates parameters, make it a class method....and don't mutate someone else's state. only 'type(self) should mutate 'self's attributes.

[gksculpture]

I must say I love your tutorial so many new concept I thought that never exist 👌🏽

[ChrisJones-hvmo]

Good stuff.

For docstring Sphinx conformant :param: or :return: statements I wouldn't just repeat the type hint you put in the def statement as it is generally redundant, and even if it wasn't the place that should go is in :type: or :rtype:. The only time you might want :type: or :rtype: there is if you want to add ", optional" just in case you didn't want to use the type hint typing.Optional[] in the def statement.

Pycharm and for that matter Sphinx generated documentation picks everything up well if you have type hints in the def and ignore :type: + :rtype:.

Oh, for up to date versions of Sphinx, at the end of the :param:, use for default values ", defaults to [DefaultParamVal]". The older syntax was something like (Default: ``'Default Value'``).
I'm sure everyone can handle that, as we are all coping with how type hinting has changed from Python 3.6 to 3.12.

[phaedrus]

Great tutorial videos. You really get me thinking. My head hurts!

[oSpam]

Great vid. We need a video on naming things. So different case styles for variables, function names, classes etc, to be more descriptive in the names, and just common practices for naming things. So many people name things with the wrong case, a video would help clear them up 😊

[Alexme]

join text function example is absolutely great. Thank you

[Markadown]

As a beginner, this was great. Thank you.

[mohdaman]

Your videos are really helpful. As you are always stressing for annotations could you point me to any video of yours where you have discussed about the annotations of async await and other complex return type and variables. If you have not talked about it a new video on it would be great

[senzmaki]

9:14
I see no point in specifying types in docstrings when your function is already type annotated, not only is it redundant but it makes the codebase less maintainable since if the function's arguments and return types were to ever change you might fail to update the documentation

[seboll]

Yesss, it's fundamental to add typing in Python, or as a matter of fact, in any programming language (yes including you Javascript :o)

[matsim]

My tips for passing parameters to functions:
- like you said, use type annotations
- if possible avoid passing/returning dictionaries of base types. Better use classes. In most cases this means docstrongs are not really necessary because the class name should convey the meaning.
In your example, it could have been an dict[Index, User] where Index and User are classes. Or even a class "UserData" wrapping the dict.

[Sailesh_Bhoite]

I noticed that you have a codeium AI attached, right?
Does it explain 400-500 lines of code or more than that?
I haven't tried it yet.
And is that enough for most of the cases or other AI are better?

[taglud]

please, which extension do you use to get all this help in visual code

[smalltimer]

How do you typehint the *strings parameter in the final tip ?

[luiggitello]

What if my function does a different thing depending on the parameter type. For example open a file if the type is Path but first convert to Path if it’s a string. How would i define the parameter type then?