Quick Python Refactoring Tips

In this Python Tutorial I show you 8 quick Python refactoring tips for cleaner and more Pythonic code.
✅ Sourcery - Free VS Code & PyCharm Extension for Refactoring: sourcery.ai/?... *
Get my Free NumPy Handbook:
www.python-engineer.com/numpy...
⭐ Join Our Discord : / discord
📓 ML Notebooks available on Patreon:
/ patrickloeber
If you enjoyed this video, please subscribe to the channel:
▶️ : / @patloeber
Resources: sourcery.ai/blog/explaining-r...
~~~~~~~~~~~~~~~ CONNECT ~~~~~~~~~~~~~~~
🖥️ Website: www.python-engineer.com
🐦 Twitter - / patloeber
✉️ Newsletter - www.python-engineer.com/newsl...
📸 Instagram - / patloeber
🦾 Discord: / discord
▶️ Subscribe: / @patloeber
~~~~~~~~~~~~~~ SUPPORT ME ~~~~~~~~~~~~~~
🅿 Patreon - / patrickloeber
#Python
----------------------------------------------------------------------------------------------------------
* This is an affiliate link. By clicking on it you will not have any additional costs, instead you will support me and my project. Thank you so much for the support! 🙏

[@patloeber]

I hope you like those tips! If you want to install the Refactoring Extension in VS Code or PyCharm, you can check it out here: sourcery.ai/? * ---------------------------------------------------------------------------------------------------------- * This is an affiliate link. By clicking on it you will not have any additional costs, instead you will support me and my project. Thank you! 🙏

[@meowvee]

#4: `var=something; return var` has its place: debugging.

[@sourg_rage]

Good tips, thanks! Personally, I don't like returning an expression directly without assigning to a variable. When you use a variable, it is easy to add a breakpoint without refactoring if you need to see the value before it is returned.

[@patloeber]

Good point! Yes this point is debatable, too :) I also like to use the variable in certain cases

[@aleksandarandjelkovic8650]

It is as easy to add a breakpoint to a return statement even without a variable and evaluate the expression in a debugger, at least in a decent IDE. I don't think adding variables just for that is approved. Readability, on the other hand, is discussable.

[@dennycrane2938]

I can to make the same comment. It's easier for debugging

[@FORGIVE123N]

Thanks a lot! Tips about "any" statement, assigning variables closer to their usage and guard statements to remove excessive indentation were very nice.

[@CupapiTG]

Nice! I didn't think of some of these, good tips.

[@adrien.cordonnier]

3:35 Tip #5 can be applied one more time. You can avoid the "else:" and corresponding indentation as you just returned in the previous if section.

[@patloeber]

yep thanks for the hint!

[@henryantwi8222]

Thanks for these helpful tips. I'll start using them asap

[@manojm9084]

Thirst for learning . This channel is a good one to quench

[@thatoneuser8600]

3:50 you can also inline the current_fashion local variable and rename the getter method, as well as getting rid of the else statement as the second if statement can also serve as a quasi-guard clause

[@emi3955]

Great advice, did not know "any" . Thanks a lot

[@Mutual_Information]

Really high information density on these vids. Very nice and not often seen.

[@patloeber]

thank you :)

[@anneest]

Thanks for those tips, they are great! I have been refactoring a lot of my code lately, guess it shows I am progressing 😀 So refactoring tips: YES PLEASE! Great vid format as well 👍

[@bobsalita3417]

Well balanced information. Concise. Thanks.

[@patloeber]

Glad you like it!

[@ChrisHalden007]

Great tips. Thanks

[@estevaoyt]

Python Engineer, you are amazing!

[@helovesdata8483]

I'm trying to become a data engineer and Python is my first coding language. My goal is to improve my programming skills and this video is super helpful to me.

[@michealhall7776]

Update: any(generator) --> Stops at the first true result of the generator, without processing the rest. Which is very useful and something I'm glad I now know Original comment: Can someone run that any( check I believe the whole generator is first evaluated then any checks the result. If so this is not what you want on most large datasets

[@TMQuest]

For number 5 (if expressions), then I think the if expressions can simplify code assuming that the code is not too long. For your example, I think that the shortening does not make it less readable. However, for if-else statements with longer assignments and conditions, the shorthand if expression can make the readability go way down (this is the same problem that long list comprehensions have). There is also the disadvantage that programmers from other languages can find the syntax a bit weird (although ternary operators still exist in e.g. JavaScript). I've purposefully avoided using the if expressions in my videos since I am not sure that everything knows about them. However, I think it would be good if more people knew :)

[@AlphaWatt]

Excellent video. Thanks!

[@patloeber]

thanks for watching :)

[@Param3021]

Thanks for the 8th tip, it is useful. Actually, your all tips are great and useful, Nice tips

[@patloeber]

Glad it was helpful!

[@quixzotic]

Love the new video! 🔥

[@patloeber]

Glad to hear that!

[@CodingIsFun]

Hi Patrick, Great video as always! Thanks for sharing your knowledge! Also, your new Website design is outstanding. 👍 Beste Gruesse, Sven

[@patloeber]

Thank you! Just noticed you have a channel, too. Great work :)

[@michealhall7776]

I prefer to only have return per function, it's much cleaner and easier to debug. Returning results as the var IMO is best practice. It allows you to easily debug and read the code output = 'hello' * 2 return output #> 'hellohello' That advice is only true when dealing with large numpy arrays where creating the variable is time consuming.

[@alex_linhares]

Nice. Subscribed!

[@patloeber]

thank you :)

[@nano7586]

I have no idea why but I have always been doing these 8 things. I'm not even a good programmer but I guess a lot of trial & error gives you a bit of intuition about what seems more readable.

these are true for any language, but good tips indeed

[@Yotanido]

3:57 I actually disagree with this one. Just checking the truthy-ness of a list is not always what you want. None is also falsy and is also recommended to be checked like this. What if you have a list that might be None? You now can't tell apart None and the empty list. Or, what if you have a list that shouldn't be None? If a None value makes it into your function somehow, it will be treated as if it were an empty list. It should just throw an exception instead, being given an invalid value. I always use "is None" and "len(x) == 0" checks to make it clear what exactly I am checking.

[@patloeber]

fair point! Checking for None and falsy can indeed be a pitfall in certain cases. I should have pointed this out...

[@MaZe741]

if you have a list thats "None" then you dont have a list, why would you design your code like that?

[@TheJacklwilliams]

@@patloeber Yeah I gotta jump in here with Random... To you and Yndostrul, from a newb, when will I have a list that is None? A little lost, even a simple example would help if you have a moment...

[@dl662]

@@TheJacklwilliams random's argument is not very pythonic. more often than not we would want to default a list variable to None instead of [] bc how python evaluates its default arguments (e.g. def func(a_list=None)). It's very common to have a list that's None; and in this case, if we want to treat None and [] the same in a single condition, it's perfectly fine to write "if a_list:"; but if None and [] deserves their own case we would wanna be more explicit about checking "len(a_list) == 0" for the [] value.

[@TheJacklwilliams]

@@dl662 Thanks Derek. I’m a complete newb and doing all I can to start out with good habits. Being pythonic and doing things in an optimum fashion are top of mind for me. I appreciate the explanation. Thank you.

[@georgethornburg9259]

Patrick, just subscribed too your channel. Love your work. I waa trying to find out where you're from. You sound Canadian ie Letterkenney vibe.

[@patloeber]

Haha thank you so much! I am German ;)

[@nested9301]

python is beautiful than javascript but ilove them both xD nice video!

[@anelm.5127]

You should definitely do more code refactorings

[@patloeber]

thanks for the suggestion :)

[@aligator329]

Is sourcery and such extensions as copilot, recommended for a junior developer with 4 months experience?

[@dcy3223]

thank your tips, your code font is also beautiful, i like it, Can you tell me which one font?

[@SahilVerma-wm6ie]

For #6 since you aren't computing anything inside the if statements, you can also just do return weather.is_raining or is_stylish Does this make sense to others?

[@AntonioSanchez-bi3nu]

Nice.

[@patloeber]

thanks!

[@SecretSanta-hg5yh]

Why not use python black directly?

[@jagjitsinghramgarhia4766]

I write nested if expressions and have written a nested list comprehension which was 3-4 levels deep, can't even debug it anymore, it just works and no one knows why now.

[@lepidoptera9337]

Why would you want to touch it, if it works? Unless you need to change it to accommodate new functionality, in which case it's better to rewrite it from scratch, leave it alone. Only amateurs mess with working systems.

[@satishshah9507]

Sir, Please bring a series of #pywebio with best web app examples.

[@ThePirateHistory]

more pls.

[@patloeber]

I try to come up with some more :)

[@xellossek]

1:35 that's what type annotations and docstrings are for...

[@RobertBrunhage]

I don't even use Python but I am a simple man, If you upload I watch 😎

[@patloeber]

Haha thank you Robert, I don't use Flutter but I also watch a lot of your videos :D I can learn a lot from your video style!

[@Kevinschart]

I have always found the "pythonic" version of code to be non intuitive. I like the traditional if statements.

[@danlater]

what theme do you use for the ide?

[@patloeber]

Material theme

[@PritishMishra]

Which VS Code Theme you are using Sir?

[@patloeber]

Dracula!

[@PritishMishra]

@@patloeber Thanks for Quck Reply!

[@maahad767]

I follow every tips except the inline condition due to readability and any(list) because I forget 😂

[@pythonicworld5026]

Quick Python Refactoring Tips (30 Second videos): kzbin.info/www/bejne/emXbfYOcmtmNiLs

[@mikapeltokorpi7671]

#5 How about: x = 1 if !(condition): x = 2 #7: last else is unnecessary.

[@patloeber]

yep that's another good option 👍

[@toddkes5890]

For me the first variable would be my 'default' condition, then the subsidiary conditions would be tested against. I.e. you are taking in a multi-line file and depending on the data you output it into different files. The default setting for a line of data would be "unknown record type", then I see if the record fits into a condition. If the record never fits any of the conditions, that record gets tossed into an "unknown format" file for the user to figure out, and if needed add more conditions to the program

[@lmaootakedh]

Huh, I refactore my code alike.

[@dbldekr]

Nah, just right click on random code and click your IDE's "refactor" button and trust that your code is better. I'm a profession programmer.

[@SamrudhSwaminathan]

When You're First So You Don't Know Wut To Comment 🤔...

[@patloeber]

haha :D

[@SamrudhSwaminathan]

@@patloeber Omg Thx Soo Much For REPLYING!! I'm a Big Fan Of U And Uve REALLY Helped Me With PyTorch!! TYSM

[@patloeber]

@@SamrudhSwaminathan Thank you! Glad you like it :)

[@Hecticam]

why u gotta sound like that bro

[@vasiliigulevich9202]

These are all style fixes that do not affect readability or function. Are you changing working code just to satisfy your subjective sense of beauty? Please don't work for me.

[@lepidoptera9337]

Yep. You can tell that it's amateur hour. Worse, it's amateurs with OCD.

[@Aldraz]

One line if statements should be forbidden.. it is so unreadable, ugly.. nah no thanks man.