10 Nooby Mistakes Devs Often Make In Python 

00:00 If I'm not wrong, Python has a predefined list of objects, including numbers from 0 to 255, that's why when you create variables with these values, they'll have the same id

Dude forgot to mention the most important difference between "is" and "==", so I will. `is` is a Python command. It does what the interpreter tells it to do (similar to "for", "if", "while" and "in") and cannot be changed normally. `==` is a OPERATOR and each class has it's own definition of what "equals" even means, by defining it with the `__eq__` method. That's why objects from different classes can equal each other. The most important difference between `==` and `is` is that the first can be a different logic for each class, which means someone can implement a class that always equals everything or never equals anything (or use really any logic) while `is` will always check for the objects id, not to check if both objects equals but to check if they are the same object (usually by checking the memory address that holds the values). Now, for a beginner this usually doesn't make much difference and for most cases `==` is encouraged, but you should ALWAYS use `is` when checking for None values, since `is` can only match a None if it really is None and will never use a different logic that can falsely match None.

[item for item in items if item != "B"]

Numer 11: not using the programing thigh high socks

"a lot of beginners" oh... come on ... There are enough experienced programmers who make these mistakes

19:35 I feel like the poor exception handling isn't as much a "nooby" mistake as it is a flaw in python's design philosophy. Well, ok it is a nooby mistake, but that's because python makes it tedious to find all the throwable exceptions an operation might do. Either in docs, or in lsp's too. Why you can't just get static analysis of "what are all the possible exceptions this function can throw?" I do not know. I have to imagine it's possible and I've just never seen it.

...been using python for years, never knew about the enumerate() start argument. Thanks!

7:48 Optimization trick: if you already know the final size of your list, you can use `[None] * len` to already have space saved in memory, but you can't use methods like `push` (because your list is already filled with None values), you have to manually index it.

Building immutable strings that way is actually faster than you would expect on CPython. There's an optimization that allocates extra storage to a string object when it's built by repeated concatenation so copies can be avoided in most cases, but only if there is at most one reference to it, like here where it's a local variable. But even having that string part of a list already breaks this optimization, and it's not available e.g. on PyPy. Otherwise, if you have a small and fixed number of strings to join, format strings are the fastest since Python 3.6 because you skip the construction of a temporary list or tuple.

The second example can be a bit misleading for the viewers. Granted one should avoid modifying a list in place. But the resulting list after deleting "B" does contain "C". One can verify that, when the for loop is done, items = ["A", "C'", "D", "E"]. But indeed it's still recommended to create a copy or declare a empty list to populate.

This was really helpful. Hope you do another one in the future.

I really enjoy your videos and find them very informative. I was wondering if you could create a more advanced video on common mistakes in Python, particularly related to code design. I've noticed that many people tend to duplicate code excessively. Specifically, I'd love to learn more about why inheritance is often not recommended and why composition is considered a better structure in many cases. Thanks in advance if you decide to make such a video! 😄

1:50 For integers, Python creates objects for numbers -5 to 256 when it starts, so references to these will use the same object. I believe these values are chosen as they are commonly used. For strings, when creating a string literal of length

Regarding exception handling: I understand why you'd use specific exception types if you handle them all in different ways. You should probably specify KeyboardInterrupts for example. But if all you are doing is logging the error, maybe display an error message and closing the program, what is the benefit of writing code for every exception individually? That just seems like a lot of wasted time and extra lines for no reason. What does it matter what kind of exception it is if I am just gonna handle it the same regardless?

Thank you very much, I love your videos!

when I write code that is a tool, let's say something about LEO assets... when python goes wrong, I throw a builtin exception, (and if it;s I/O, I import errors and figure out which I/O thing went wrong), but if it's a domain specific user mistake, I send a custom exception. for example, they set orbit altitude to 2000 km, I'll throw a: >>>class LEOAltitude(ValueError): telling them LEO is 200 - 1600 km. If it's more general, I may go nuts and have an mro that looks like: LEOAltitudeError [or MEO, GEO] AltitudeError. [or Inclination, RightAscension, Eccentricity, MeanAnomaly, ...] OrbitParameterError [or Epoch or Classification... any thing in aTwo Line Element] ValueError. [now it's python's mro from here on out] StandardError Exception BaseException object

Some cool stuff to think about. Generally, good. I'm making notes for my improvement. I have some quibbles with the text concatenation versus list append/join contrast - but I don't disagree with your efficiency test, the numbers don't lie. It's just that most large format text will be written with JSON, XML, CSV modules - most human readable text would be output from a triple-quoted template with variable substitutions in practice. I wouldn't sacrifice readability for that mild resource gain - and it's unlikely I would need to. Also regarding exception blocks using print(). Standard out may be a team's preference if the code is deployed to a container cluster and logging aggregation is handled via a third party tool like datadog or loggly. I wouldn't be quite so hard on using print() - even though I agree that a logger with the standard-out flag set would be better and easier to maintain. The important bit was catch and report the exception - which is key! Keep up the good work. I really enjoy the attention to nuances that you bring us. Thank you.

One of the thing with drives me crazy with Python is that it does adhere with namespace, for example with the with ... file, you create a variable within the block, but later outside the block you address the variable (print(content)). If you would do something similar in a language like C, C++ or Java then you would get an error as it would not be a know variable.

Note it is ok to change the elements of a list while iterating to it, something like this for i, n in enumerate(nums): nums[i]=10*n is fine, eventhough in this case (overwriting) list comprehension is better: nums=[10*n for n in nums].

Regarding enumerations, one has to remember there's a lot of 'black magic' that happens when the 'for item enumerate(items)' happens. It's creating /using the 'iterable' part of the object and determining the starting and ending points before running the loop. So some things like changing a value is fine, but changing the start or end points by appending or removing is problematic. Using a filter clause is great because then each item is 'tested' against the filter before each new pass through the loop and skipped if fails.

If you use the Exception e catch-all, you can actually use "raise" to make sure the exception you got but don't/can't handle gets re-raised to the code that called your function. This can be handy sometimes. Edit: A somewhat contrived use case: You catch FileNotFound, but you don't explicitly catch IO errors. Maybe your code doesn't need to know that IO errors are a thing. In both cases, you want to act on the information that the file was not processed correctly. Maybe this is not a hard error in your library. You pass the catch-all exception to the calling function using "raise" after logging or something similar. Perhaps you want to revert your DB update that was probably corrupted, but you don't really care about the specifics of the error raised? Re-raising lets you do just that. I use this to great effect when using complicated libraries like BeautifulSoup.

Thank you for the video! Regarding mistake #6, using isinstance can be useful to check the type of a variable, by after your explanation it is still not clear to me how to check if two variables have the same type. If I know in advance what type to check, I could do: if isinstance(name, str) and isinstance(number, str): ... But if I do not know to what I need to compare, then something like this would be required?: if isinstance(name, type(number): ... In that case, if I'm going to use the "type" function anyway, wouldn't it be better to just compare the types?: if type(name) == type(number): ... 🤔

Is it ok to use " var is not None"

3:04 you can also loop through the list backwards to avoid issues when changing the list as you loop through it. It doesnt sound like it should work but if you play out the logic it will.

My suggestion for removing items from a list, use either a list comprehension or the filter function, since they both are easily optimized by your Python runtime/compiler.

10:11 In my opinion this can be simplified even more using `Path("notes.txt").read_text()` or `Path("notes.txt").write_text()`. If you are doing some fancy file handling things where you explicitly need to open the file (or append to it or stream parts & not read it all at once), then sure, use `with open("notes.txt") as file:`. However all too often I see code that opens a file just to read/write it all and then close it again. Why not remove all the hassle of worrying about opening and make use of the stdlib provided to you. There's even a bytes read/write function as well if you need that. `pathlib.Path` FTW!

It is very common to remove elements without having to recreate the whole list (for performance reasons)! The common practice for all languages is always to iterate from END to start by index (only). That's all. For a new list, as you already know, a list comprehension with if clause, would be more pythonian (instead of a loop). Other than that, great video!

Old people tend to use smaller variable names because if I am not mistaken it used to be a problem.

Please make a video on python Selenium,getting confused in type hinting while declaring the necessary variables

3:04 it does work if you modify the current element, you just have to reassign it. for example: for index, item in enumerate(items): if item == "B": items[index] = "new value" item = "new value" else: print(item) its a very niche use case and definitely a janky approach, but i've used it before and it doesn't cause any bugs since it doesn't change where the iteration is occurring.

How does 'text'*50 perform?

Thank you for the enumerate() index. I was doing the math like a fool lmaoo

Underrated channel fr

Finally. 0/10 mistakes made by me. All those years were worth it.

That's the second time I've heard a RU-vidr say that just today. Though, you're the only one of the two that I believe.

How do we then name GUI variables. I encountered this mental block a lot.

With example 3, doesn't appending a list with a string also create a new string at the end of that list? If so, why is it faster since in both functions you are creating a new string? If I had to guess, maybe it's because the memory has already been allocated at the end of the list so it's faster to access, whereas the first example, new memory has to be allocated. Is that right?

I was actually told, that fast string concatenation should be done with a StringIO() object. Jesus, I now compared the three methods and it's the worst, double as slow as the list method. I was lied to. So thanks for that input!

to the second point: you can just iterate though a copy of the original list

20 : 54 is there any simple way to check if none without using try cath,i was c# developer it was '?' key to check if is null...

The second one is interesting. I am using a lot of pandas, so I am usually working and modifying some Dataframe. How does the looping behave with df.iterrows? Should i still create a new list/dataframe? And how should I save the modified data ?

5:12 Actually, why not just do 'for item in list(items)' to make a copy so we are not iterating through the list can get elements removed?

num: list[int] = [1, 2, 3] c_num: list[int] = num.copy() c_num.append(4) print(f'{id(num)=}') print(f'{id(c_num)=}') print(num) print(c_num)

Hey, got a concern about the 3rd section, please, consider the following: elements = [] for i in range(50): elements.append('text') print(all([elem is elements[0] for elem in elements]))

I knew not to do all these things, but it's great to hear why they're bad practises Like I never considered a crash before .close()

You can actually iterate through a list while modifying the original and without making a copy, you just have to iterate through the indices in reverse. Yes, deepcopy() is slow. That's why we shouldn't use it. When we copy things, we should already know the structure of what it is we are copying, and we can use that knowledge to maintain any level of shallow copying we want. matrix = [[1, 2, 3, 4], [5, 6, 7 ,8], [9, 10, 11 12], [13, 14, 15, 16]] new_matrix = matrix.copy() # slicing, or [:], can be new_matrix[0] = matrix[0].copy() # used in place of .copy() as well. new_matrix[0].append(17) print(matrix) print(new_matrix)

for lists iterations, why don't you just create a copy of the initial list: for item in items[:]: ...

Isn't the best way to iterate over a list that you want to modify, this: for item in list(mylist): # do stuff to mylist

Not a fan of typed lists--since list doesn't respect type. If you need an ordered container of characters, python has a standard library thing: array.array('c', ....) The point is the latter tells devs: this is an ordered container of characters by definition, and that respects POLA. (principle of least astonishment).

Pycharm always highlights not using is with booleans so I suppose it's ok for that?

For second one adding [:] will solve the issue...for item in items[:]:.....

12:00 how is that not readable? In fact, you can read it from left to right very well "type of name equals type of x". In contrast, isinstance(name, str) is more unreadable in my opinion. You also didn't refactor the original example, where you're checking that both variables have the same type, in which case, it would now look like isinstance(name, type(x)) and now we get REALLY unreadable PS: I still think isinstance is preferable, just pointing out that readability is not its strong suit

excellent

What about 'text' * 50?

print("Hello!" * 50)

I know there is a lot of negativity around type(a) == type(b) , but most of the time I do want it to be that strict for comparisons, I want to know are they both cats or both animals so that way I can treat them the same way.

I see that's the reason for deepcopy

in 2024 you should use content: str = Path('notes.txt').read_text() ...after from pathlib import Path

I rate with a passion poor exception handling. It is not only a beginner mistake. There is poor exception handling in gigantic projects backed by the best universities in scientific programming software. I let the software run for an entire night only to discover that they were literally hiding an error and discarding every generetated data because of poor exception handling.

ye i always use with

Print(“text” * 50)

for the 3:04 problem, instead of creating a new list with a new name, you can just use "for item in items[:]" which clones the list for the loop only, and you can continue to modify the original list in the loop

id = memory address

I don’t really understand the closing files things. I mean, it does still close when program terminates for any reason. Like, what is going to happen?

Magic numbers 😅

That was very dismissive for exception wildcards. Who knows every possible error for their code is either someone with too much time on their hands or someone that is likely very arrogant and will likely be wrong. Just saying.

what does the colon : mean? I thought you write a = "bob" in python

First

not second nor first

3:55 items = [i for i in range(1, 20)] >>> for item in items: ... if item == 13: ... items.remove(item) ... else: ... continue ... >>> print(items) [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 14, 15, 16, 17, 18, 19] Why does the example I've provided work as intended, but yours doesn't? This also works if I type "items.remove(13)" instead of "items.remove(item)".

Not first

Second

catching a true bare exception is: try: [statement] except: print('something went wrong, but we have no idea') this will take down your project.

H

10:45 you can ignore this, but I'm interested what other pythonistas think (esp. those unsullied by other languages): type hinting an "open" call and even a "read" seems extraneous...more so for strongly typed magic methods, I mean if you don't know dunder init must return None, then don't be writing classes. Any,way I find that whole look at the time stamp cluttered and difficult to parse. I mean try to read this sentence: [Subject] I [pronoun][first person] [verb] like [verb][transitive] [object] Indently [noun][proper] import this: Readability counts.

Actually, it’s supposed to be spelt “newbie” and not “nooby”.

NICE VIDEO !!! (HOPING YOU READ THIS COMMENT AS WELL)