5 Tips To Write Better Python Functions

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

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

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

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

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 .

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.

Excellent! 💯

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

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.

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 😊

Those were some great tips. Thanks!

join text function example is absolutely great. Thank you

Very helpful video. Thank you!

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

Very useful. Thanks!

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

As a beginner, this was great. Thank you.

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.

Very nice 🙂

thank you so much!