5 Bad Ideas In Python

In this video we’re going to be looking at five bad ideas in Python, and how you can avoid them.

▶ Become job-ready with Python:

▶ Follow me on Instagram:

00:00 Learning Python made simple
00:05 Intro
00:26 Modifying a list
03:35 Encountering exceptions
08:21 Endless if..else
13:43 Recursion
20:12 Mutable defaults
25:18 Conclusion

[Millar]

I'm not arguing that removing while iterating causes an index skip. But the reason "indently" is getting printed is because it's the current value stored in the variable "channel" during that iteration. Than the index skip happens which results in bool. It would have been more appropriate to print the list itself on each iteration not just the indexed value.

[edwolt]

In the recursion question, both functions are doing different things. The recursion is doing a lot of recalculations, while the iterative function calculate each number once. If you wanna say recursion hurts performance, it's better to compare two functions that are well written.

[prok]

I am not convinced handling 'exception as e' is wrong. This is more like pushing one opinion as a standard or "good practice".

[Tactical_Nerd_Clash]

You can cache the result of the recursion to make it faster

[tamasburghard]

i think the recursion part is wrong. First, you mix the dynamic programming part(nothing to do with python) with the recursion overhead. Avoiding recursion is great if you really need that, but honestly most people using python will never do anything where it really matters. If yes, a single (at)cache will solve the problem with maintaining the readability. If the recursion overhead would matter, python would already be a bad answer, tbh.
The second example in recursion is an antipattern, a simple loop would suffice with the possibility to setup a retry number.

[sumedh-girish]

19:43 Well this would only work soo long. If I enter the wrong stuff enough times, you will run into a snarly error for exceeding maximum recursion depth, or worse fill up memory and crash. Wouldn't it be better to use a while loop? Why recursion.

[kmn]

So the challenge is to produce an example of code that violates as many of these rules as possible whilst being readable and performant.
Bonus points for using descriptive names rather that type annotations.

[tigranav.]

the example of a good recursion usage is actually bad. This is not a case fir recursion, rather you can use while True, and break do loop on success. the recursion approach is bad because you fill the call stack, the stack can overflow

[DrDeuteron]

5:25 another thing about try/except blocks is minimizing the code in the try block, so the 1st print statement should be before:
try:
user_float = float(user_input)
except ValueError as err:
...
except TypeError as err:
...
else:
print ("etc...")

and note, the print statement is removed also, only the cast-to-float lives in try because only it is in question

[BizarePlayer]

"It's easy to debug if you know how error is produced."

KeyError: 0

[AirLight]

“We need to unindent” but I thought this was Indently!

[MatthewMakesAU]

For list modification, I loop through my list and append the ones I want to keep to a new list. No deletion at all. Much easier to debug

[dirtydevotee]

I get you're talking about indentation, but that function at 11:16 does NOT work as expected. The problem is that a "False" nested if will trigger a return, preventing evaluation of the rest of the options. The better way is:

def check_all(...the same parameters...):
temp_var = True
if not has_money:
temp_var = False
print ("No money...")
...
if temp_var == True:
print ("You have everything!!!")
return temp_var

Now it will let the user know if more than one parameter is "False".

[starryknight]

Ironic that a channel named "Indently" is recommending against excessive indentation... haha😉

[Upload]

A good rule of thumb with guard clauses I use is " If statements that return can never have an else statement."

[arkazix]

Personally, the main reason I avoid using recursive algorithms in Python is the lack of tail call optimization, which unfortunately is very unlikely to ever be implemented. Some algorithms, particularly those operating on tree structures, are well-suited for recursion. However, Python is unfortunately not the best language for implementing them.

[luistabotelho]

The biggest issue I find with error handling is not the exception block, but handling the exception in the exception block and not passing the exception to the calling function. In an API this many times results in it returning a 200 response with no content, and the error being logged internally. So something interesting would be to cover how to do error handling in big multi-layer applications.

On example I have is in one program someone made a DB call which could return a not found exception, but then handled the exception to log out the error message and return an empty array. All good, user get's an empty response if not found, but if the DB connection fails (DB not found exception) it was also returning 200 with empty response instead of a 500 internal error.

[JustThatRandomTroll]

General exceptions are not always bad. For instance if your program is calling to a JVM instance (i.e. Databricks), Python can’t access the underlying exception types. So you have to catch it in a general except clause, check if str(e) contains the Java error you want to check snd raise again otherwise. So there are totally valid use cases

[Hendika]

Using guard clause will make you understand your logic better

[therealdebater]

13:22 I think (I'm not sure) that a better term would be 'early exit' rather than 'guard clause' (which tends to be used in connection with multi-tasking and synchronisation). Early exit is often a neat way to avoid spaghetti if-then-else structures, but it can also be a liability. In a large block of code, an early exit can be easy to miss, and it can make it hard to spot certain kinds of bug. So use it with care; try to avoid it getting buried in a mass of code.