Python's 5 Worst Features 

I read this title as Python 5 and thought I woke from a coma

"It will print nothing because we didn't print anything" -Python development in a nutshell

Regarding the `else` statement. Raymond Hettinger once mentioned he had proposed renaming it to `nobreak`, but in hadn't been accepted. In any case, I consider it the best Python feature with the worst name.

To avoid confusion, you have to think that the "break/else" are working together, which means if there is no "break" statement in the loop then there shouldn't have "else"

The for-else thing caught me off guard. I never used it but I assumed it got triggered only when the body wasn't run, since in most languages the for loop is a while loop with batteries included, and the while loop is an if with a hidden goto. Very, very unexpected behavior!

I don't mind "else" with "try" since it would naturally follow an "except".

The real issue with `import *` is not shadowing in the way you showed, because you can understand that kind of shadowing statically from your environment. The real issue is actually that you may be deploying your code in an environment where each module has different versions, and if they are using semantic versioning then *adding a new feature* to those modules only bumps the *minor* version, which is assumed to always be backwards compatible. If anything changes that is not backwards compatible, the module would have bumped the *major* version instead, and package managers on the deployment end will use this standard to automatically get the most up-to-date but still compatible version of the dependent modules. However, if you use `import *` then this new feature will be imported into your program, possibly shadowing part of another module that you could not have possibly known about at the time you wrote the code, which turns industry standard backwards compatible updates into automatic code breakage!

In case someone still doesn't know, R language does not have the import as syntax at all, so functions from various libraries often override each other. You often need to use syntax like base::mean(), which means using the mean function from the base library. The dummies behind tidyverse have created some tools, like forcing users to explicitly specify the library origin for each function when namespace conflicts are detected. It's just replacing one nightmare with another nightmare.

Sometime you’d use a for loop to go through some data looking for a feature, then if you don’t find it you’d exhaust the loop and drop to the else block. In that case it’s not success, it’s failure.

Else block has imo fairly solid intuition: You often loop things to find something. Once you find it, you'd break out of the loop, and be happy. However, sometimes you don't find what you were looking for, so you now have to do something... else. With exceptions likewise, the intuition seems clear enough, you expect an exception of some sort... But if you don't get that exception? You do something else. I find it a bit underused syntax tho, and as such, maybe it should be removed. But it's very helpful syntax for many common use cases.

This topic is very close to my heart. I love Python as a programming language but I have faced these issues. Since I code in multiple languages, I have been gravitating more towards syntactically rigid languages.

The real problem with “try … except Exception” is that python does not document what exceptions a function can raise, which encourages the use of Exception… 😢

I don’t think it’s fair to say Python’s string literal juxtaposition causes concatenation is “poorly thought out”, because this was a feature of C. In C, it made more sense in the context of macros and automatically generated code. And Python has borrowed a lot of other syntax from C, so at the time *not* having this feature would’ve been more conspicuous.

Big hater of implicit string concatenation - recently caused a large amount of calculations to silently not run for me

One thing close to copies is when you try to initialize a 2d array like this: a = [[0]*5]*5, it wouldn't do a proper 2d array (an array with multiple different arrays in it), but an array with multiple references of the same array, so if you were to go a[0][0] = 1, it would change the first elements in all of the rows, not only the first one

What?! No mention of package dependency management? :)

My most terrible feature is that a += b and a = a + b can have different semantics in Python if a and b are objects.

The mutable default is the closest we got to C's static variables inside functions, so i think they are a valuable tool, despite being limited to only lists and dictionaries (no, global variables don't count as they can be accessed from anywhere).

I think shallow copies make more sense than you'd realize. Generally speaking you want to copy the least ammount of memory possible and be very explicit over deep copies.

You see, try, except, else works for me. I would agree with you however that in the case of 'for' and 'while', it does seem unintuitive... but, hey, at least I learnt something more about looping! 😊

I know when you're using default mutables for a dataclass it requires you to use a function that returns the mutable to get around this, would that work in an ordinary function call as well? I don't think it's any easier to read than the boilerplate you have, but it would be a different way of doing it

I am starting to learn Python and even if the subjects are more relevant to people who already have mastery of it, I found it very interesting to follow the video (by reproducing the examples, because I learn better by doing it even if it's shown, that way I can test a little more) And I already liked seeing certain practices often seen in tutorials which could go against the good practices that you mentioned and therefore avoid getting into bad habits and in addition I learned some things with the video that I I don't know enough about it yet but it will probably be useful to me one day.

I personally use for else in my code, but i you are also right, it doesn't justify for what it actually means. I used to use from module import * but then i got to know the importance and i don't use it. And btw i never knew the difference between shallow copy and deepcofee until i watched this video 😅

Dude got some serious issues with Bob 🤔

Shallow copies are spain without the p

the else block is like the exact opposite of what you would think it doesn't even make sense compared to how it works with if if anything it should run only when broken out i think it shouldve been named 'also' block

I thought that you goinng to say, that else is worst feachure bc you can mistakenly make else not for if, but for for, like: for i in range(10): if i == 5: print(five) -else:- -print(i)- _else:_ _print(i)_ and you get an error

The else in try block makes sense to me as I've always understood it as "(if) except: ... else (no exception: ... The else in the loops is less intuitive to me. It seemed to me like it should run if there were no iterations at all

An addition to the star imports: Not using star imports also benefits to the speed and the file size of your application. If you use a big library like PySide6 (for creating GUIs) and you import everything, your compiled app will be roundabout 200-300 megabytes. If you only use the Widgets, Gui and Core (which most applications do), then you will end up with like 20 megabytes and a MUCH better startup time AND in addition to that it also helps your IDE, as it doesn't have to index dozens of docstrings and functions. But if you only use small libraries like colorama it doesn't really matter, but still a good habbit to not do star imports :)

Thanks for the useful video; I learned some things. For implicit string concatenation, that comes in very handy when needing to do deeper escaping of strings containing a mix of single and double quotes. Used right, it's a huge help. I agree that used wrong, it's a mess. Maybe best to not use it unless it's actually needed. Great video overall, though. Thanks!

Great video, thank you. I am mainly a C# and JS dev but like to see what other languages share/do differently. What about else with 0 runs? So while (false) else print('yes') or no? Why would you use "else" in a real example? Just to avoid checking count/state afterwards like if count < length / isAllGood = false?

counter point: funny enough when i taught my ex programming she intuitively guessed the else feature for for loops. i couldnt understand why her code run correctly and ended up finding it in the docs most of us that already program find it unintuitive because no other language does it. but i here its us who cannot think outside of the box and the feature imho actually in wonderful because you actually have to do this quite often and i always hated flag invalidating loops when i had to write them in any language

import * and mutable defaults are both caught by pylint, at least. But yeah these aspects of Python all have sharp corners. Also, when did the | syntax for type hints show up? I use typing.Optional and typing.Union since I wasn't aware of that bit of syntax sugar.

The last feature is quite expected. After all, a list in the memory of a computer is just a pointer to a memory address :) Actually I mostly write code in php and its copy-on-write behavior was confusing me for a long time in the past.

List comprehension usage would be useful for a lot of these vs what you do like in mutable example . Or using inline defaults Time and performance gains too

because of this video I've just realized that I might have a mutable default problem in one of my private libraries. Thanks!

I think the most irritating part about else block is that for "if" statement it means that "if" *did not* work

Good list learnt something new today. 1.) Didn't know this, can't really see a use for it and can see how that would be annoying. 2.) Didn't know this either, could be useful. 3.) Did know this, but never use star imports personally. 4,) Bit by this before, when my editor didn't warn me. I spent hours trying to figure out why something wasn't working. 5.) Come up against this before but don't think it's too bad.

Hey, fun video! What editor are you using? It looks like VSCode but not quite... I'm really curious.

Regarding splitting a long string over mutliple lines, i was gonna say i would write this in a triple quoted string and then unfold it with some stdlib tools. But when i looked for such tools i realized that neither textwrap nor shlex have them ready to go. You would have to do it in two steps (like textwrap.dedent().replace(" ", "") ) or use a full on regular expression. Or i guess you could make a proper tuple of your string lines and use str.join(). There's a lot of option, but they all seem like a lot (ish) of work just to make your source code prettier :)

Absolutely valid criticisms for the string concatenation and shallow copies. There is also a problem when you're trying to make a list with multiple copies of the same thing (ie. lista = [[item1], [item2]] # if you do [[item1] * 2, [item2]] * 2 and then try to adjust item 1, it will adjust all of the first elements of all of the copies of lista. There is a way around it, but to find out the easy solution you have to go to the Q&A section of the documentation -_- I disagree on you star imports point, if you are making a function that is already defined... I feel like you're setting yourself up for failure! Why would you do that?! But yeah, good video.

regarding star imports: pylint will throw various warnings at you about them, such as to not use them in general, but it also has a lint for star imports shadowing each other. pylint, with a lot of configuration about which issues you care about, is actually a very nice tool to use in any project. there really isn't an alternative for it yet.

Calling the else branch of the for or while loops a success is somewhat questionable. One could consider the break statement execution to be a success instead, actually. For example, it might mean we found something we looked for.

I agree with you when it comes to "else" blocks on loops, but try/except/else actually makes perfect sense to me (first try this, then if there is an exception do this, otherwise do this), and it can be very useful, especially in cases where you want to do something with a result that won't be there in the exceptional case, without accidentally catching errors you didn't mean to. I'd even go so far as to say that if you find yourself writing more than a single function call inside a "try" block, you should consider whether some of it should go in an associated "else" block instead.

Your videos are helping me learn and giving me also idea how to present my videos

If I make a shallow copy, is there any way to display the list that displays the references so that I _know_ I'm dealing with a shallow copy? (I figure this might be useful in debugging.)

I mean... For try/except/else, the else is after the exceptions. So it's like, "else, if there are no exceptions, do this". Makes sense to me. For for loops, it makes even more sense. You break out of the loop because you are done with whatever you were doing. If you reach the end of the loop, you're probably not done, so you fall through into the else block. Best example is searching for a particular element. Once you find it, you break out of the loop. If you reach the end, you didn't find it.

to the star imports: Namespaces are one honking great idea -- let's do more of those! - the zen of python

wow using else in a for loop as a sort of confirmation that everything had looped through successfully was something I would have never have thought of. though it does make a lot of sense in a while loop. I literally used it in my very first python script to close off a loop. It just seemed very intuitive to me since while is a sort of logical statement. It also makes sense in a try block. Less obvious but still it makes total sense. Actually all of them do make kind of sense if you just build a regular sentence out of them like: - if condition is true do a thing else do another thing - while condition is true do a thing else do another thing - try to do a thing, if it breaks do another thing, else do a different thing - for current thing in collection of things do a thing, else do another thing for is definitely the most confusing one though. Especially with break although it does make sense if you understand what break breaks you out of the current block entirely and else is part of that block so it won't be run if interrupted by a break.

Excellent video! Very useful. 🤯🔥👋

It was a very informative and helpful video, I just feel like the 'else' is actually intuitive, and that it is one of the things that any programmer should read the docs about anyway, besides that I have the same opinions.

Thanks for a great video. Coming to Python from Julia I can tell that most of these problems have better solutions there.

I've been trying to get back to programing Python more intensely after many years; and one of the things that has been bothering me is it has way too many ways to do the same thing to different things, but it's not always done the same way for different types sometimes; and it can get even worse when using libraries that come with their own additional types...

Which developer’s version of Python do you recommend ? Which version has the fewest inherent 🐞 🐛 🐜 bugs ?

So you'd rather cleanup fails in your code because you didn't realize that some library that used another library that used another library didn't document one of the errors that can be raised deeper in the call stack, right? At least catch an Exception and log if the type of exception is unknown, unless you're absolutely sure the function raises only what you know it raises. Or unless your code doesn't have any important cleanup to do.

14:32 the if statement creates unnecessary branching, which could make the function run slower. a better way to do it is `target = target || [];`.

Totally agree on the else for the reason; if you don't go into the if you go into the else. So it would make intuitive sense if you don't go into the loop block you go into the else rather than its present logic. And there is far more cases where it would be useful to use else if you cant loop, rather than if you can.

Another alternative for the mutable default list, is create a function that returns an object of the given type (in this example, called "new"). def func(target: list[str] = new(list[str])) dunno if this is a good idea, but one that came to mind nevertheless

String concatenation is very useful, especially when creating error descriptions or string templates for complex terminal interactions, a good formatter usually is enough to detect those problems.

Calling the else block "success block" I consider confusing, as I would use it specifically in case of failure. For example if using a loop to find something, the else block will be executed if it was not found. What is entirely pointless, however, is an else block on try. Just put those statements at the end of the try block. On the impot * the problem isn't the ability to use that, but the fact that Python silently overwrites the value from the previously imported module. Instead you should get an error when trying to access the ambiguous name unqualified. On string concatenation, I think the Python developers got spoilt by C which also does that.

In the Ruby programming language, the role of the "else" keyword, as described in the second section, is performed by the "ensure" keyword. I think it's a much better name. It's also slightly different, because the "ensure" code block is always executed.

I love the first feature (using parentheses) you just need to be careful, but it declutters the code so much!!! Also a feature of C/C++ if you are wondering from where that came.

I think the worst feature is the copy, maybe is made it with shallow copy because Python itself is heavy. But I think they should change to specific copy like a.shallow_copy() instead of only copy method.

the else block for while is kinda weird.. the else block for the "for" loop is extremely unintuitive, since I would expect "for i in items .... else:

Thanks for helping us on these😊

The shallow- vs deepcopy is new to me. What would be a useful use case for a shallowcopy?

My least favorite thing in python is the bytes() constructor because it has one notable inconsistency with the str() constructor that is inconsistent with the other constructors in the same space. Here's an example: A = "1" int(A) # => the integer 1 str(int(A)) # Now we've roundtripped back to the string "1" A = "1" bytes(int(A)) # this is b"\x00", ie the null byte. Unlike the str() constructor which turns an integer into a decimal string representation of the number, the bytes() constructor creates a byte string with as many null bytes as the integer specified.

On the uses of `else`, i think the uses in `while` and `for` are better than the use in `try`. In the case of `while`, a condition gets evaluated to `False` and because of that, the else block run. It's unusual to have a structure retry the same condition over and over until it turns false but that the idea of a loop and `else` prividing code to execute then is a bit of a stretch but mostly fit. `for` is a `while` loop tied to an iterator so the same logic applies. `try` is different because the condition that would have to be false for the fallback analogie to works would be having the try block raise an exception. IMHO, you tend to look as the code execution as the "normal" path and an exception as being unsual. Having the "normal" path tied to the `else` keyword feels like a double negative (if not ok: except(); else: success()) and these tend to be awkward to work with. Also, in languages allowing valued break (giving a value to a loop construct), the else block can provide a fallback value which is also its behavior in a `if ... else ...` in such languages. (e.g. if a loop gets a value from its `break` but no `break` gets triggers during execution, the `else` can provide a fallback value and avoid not having a value)

This all looks like problems with dev environment not language itself. It would be 'nice' to have warnings for these (in vs code, maybe someone can program a plugin for it, or already did?), but then again, all these features work in a way one would expect them to. - string concatenation - somewhat useful I guess. Would be nice if it worked with variables: 'some text ' variable ' more text'. - the 'else:' should probably be called 'finally:'. The 'break' skipping that is reasonable, as it terminated the loop. - star imports - well, it does exactly what you asked it to. Same thing happens in javascript mixins, last one wins. - mutable defaults - I hoped to see some 'overwrite core language values' stuff here. It was fun to replace console.log in js. - copying - The problem exists in many languages, to the point of some of them (c#) not containing any built-in copy interfaces because of possible misunderstanding between shallow/deep copy.

I'm totally with you with the first 4 features, but the last one do you have in any language i know, because of the reference type of the nested list (or to be clearer in python because of the mutable type, because in the end everthing is a reference type in python). Therefore, copy behave as expected in my opinion. What would be nice on the other hand, an additional deepcopy method for example.

I only agree with two of your features being bad (import * which the documentation notes is mostly for trying things out at the REPL rather than for using in scripts [although, I have another valid use case for this...]) and mutable defaults. It would be nice to go into why miracle defaults behave the way they do... I don't think it is so much of a "feature" as a product of semantics of the language. When the function is created, its function definition is processed and the defaults specified are created. This is why that same container type is used every single time the function is called. Knowing why this happens can help you remember to avoid it ;-) The use case for import * is niche: when you are creating a wrapper around another module, import * is the most robust way to ensure your wrapper handles whatever you are wrapping, now and into the future. These types of wrappers are especially useful when writing code that will run on multiple versions of python. An example from my distant past: try: # modern python from json import * except ImportError: # old python that doesn't have the json module in the stdlib from simplejson import *

I only create basic scripts that help me with work, but I have come across the deepcopy issue myself. (Work not related to programming)

I also don't like how enums work, the fact that you have to call auto() for each of them when in 90% of applications you are going to use auto anyway. Why not make that the default, while still allowing overwriting with a value in the rare cases you need a specific value. Also having to import packages for such basic features always seemed a bit hacky. Almost like its not part of python but you had to rely on someone else's implementation.

The deepcopy can yield unexpected behaviors when it acts on objects without recursive memory calls, which may be another reason for why it's not default. I don't know what the cause of these unexpected behaviors are, but I've run into situations where performing a deepcopy on an object makes it unusable, while performing a shallow copy works perfectly. My guess is that more complex integrated objects are more likely to have internal parameters that you don't want to copy, and so are more likely to want to be shallowly copied instead of deepcopied.

How many time have people needed to check whether a loop has reached its natural conclusion? The else clause to a loop is in principle a great idea! It's just that using the else keyword because it's already there is a lazy implementation of this feature that can cause confusion. What if there is an if statement in your for loop?

I guess the problem with the "success" case else is the indentation typo with if block. It can happen easily when you copy and paste from other parts of the code. else in if..else and else in for...else mean two completely different things, so they should be named differently.

From a Python beginner: • Are there any benefits of using deepcopy vs a_copy = a[:]? • There’s no need to import when using a[:]. • Could this syntax be a fairly new addition?

My thoughts on all of this: Implicit string concatenation is fine, it does have unfortunate things that can happen with missing commas, but those are revealed if you run a formatter like black. It is also nice for separating strings across lines without the indent behavior of multi line strings. While poorly named, I have used for…else a couple of times, and it is nice to not have to use an additional variable to store that state. It should have a better name, but I think that python would be worse without it. Star imports are terrible. Mutable defaults are definitely a curve ball when first learning python, but once they are understood that’s it. They are also fun for golfed caches. Unmentioned in the video, but there is a second, harder to explain stage when using lambdas since they bind late. Shallow copies by default are also a learning barrier, but again it’s a thing that you only have to learn once. There is also the unmentioned tuple interior mutability, which feels like the same sort of issue.

Nice video ! Usually i put inside the try: some lines to be executed after de dangerous code, if nothing triggers an exception that code will execute, otherwise it won't... so i don't really get the purpose of the else: at all...

I’ve written thousands of lines of Python over 10ish years using it, and have never encountered that missing comma issue.

What about global and nonlocal?

6:13 f.. didn't know about this else block. Xd, this is something I didn't expected

2:23 That's not a bad feature. It's a bug in the compiler/interpreter. The compiler/interpreter is apparently interpreting a LIST as a concatenated string. That's not the fault of implicit concatenation, it's the fault of the compiler/interpreter.

It absolutely amazes me that Python has been so widely used for anything numerical, given that it makes shallow copies by default. That one feature is almost a deal-breaker all by itself. I use Python occasionally, but will never trust it.

I think shallow copying, variables don't need declared, == Implicitly returns False when comparing different types, using generators to support lazy evaluation (exhausting iterators), exception capture cannot specify the source, strings are iterable, module import design, explicit asynchronous design, etc. are the main causes of errors. Implicit string concatenation can be used to solve some troublesome string, f string, r string switching problems. Using + concatenation will become very confusing because + often appears in regular expressions. for...else is actually bad, because Python itself does not support breaking nested loops, so it is better to use generators and next() to do the search. Modify default is less of a problem. Functions are supposed to return variables instead of modifying variable parameters. If you need a modify default value, you should use a closure. P.S.: I think concatenating strings with + is a bad idea, the semantics of + are very ambiguous, like def addMr(s): return 'Mr. '+s you can't tell if it throws an exception or does something weird. You really should use f-strings to format string content instead of +.

Shallow copy is a common thing across programming languages, and makes sense, but default values being created statically for each function is unforgiveable.

Also star import: you import anything that was imported in the imported module. I saw logging being imported and used this way. Definitely agree this is bad feature.

Regarding the mutable defaults, when you fixed it why did you write “target | None = None”? Inside the function you checked to see if target was None anyway, so why not just make it “target = None”?

Sometimes, for-else block is very useful!

In R, star imports are pretty much the defacto standard. However, you get a warning when a library masks a function from another imported library

it mentions coffee, it gets a thumps up. simple

There is a great linter called Ruff. It's a combination of all popular flake8 etc. and it's really fast because written in rust. And it warns the import *

I always import the entire module/package instead of importing single functions, is this bad practice? I prefer to access copy.deepcopy() than to access it as deepcopy() because if someone is reading or glancing at the code they will think deepcopy is an independent module/package

I think you can target=list() for mutable defaults

The `else` keyword in a for loop has been very useful for me when searching through some kind of interable. If you do *not* find a match (so there is no success) then you can handle that in some way. That's why I don't think `success` would be a better name. Technically it ran the for loop "successfully" but in terms of the intent/purpose of the code we were definitely not successful in what we were trying to achieve. Therefore in my opinion it makes sense that python uses the neutral `else` which is less confusing than a `success` block that runs when there is a failure. Perhaps there is an even better name than `else` or `success`?

What is your addons list?

I think you’re more or less right, except the last part. I needed a deep copy maybe 2 times in my life, compared to 27286373 times of shallow copies

For me as a hobby python code writer the worst feature is the limitations of input, I write mostly scripts that are utilities for my own use and almost all of them use user input, sometimes you need a bit more flexibility than what input has to offer, actually I would love to see you do a video about tricks to use with input.

Honestly the mutable defaults issue is easily the worst thing here. I have never once seen anyone have the issue with missing commas in a string list. I don't understand at all why `try:`, `except:`, `else:` doesn't make sense to you. It comes right after the `except`, so, it's `else, if no exception`.

one really good solution for the copy problem would have been never using the "copy" word in itself. Instead having "shallowcopy" and "deepcopy". Beginners would immediately get suspicious about the "shallow" part and quickly realize what it does. For most beginners learning that "copy" is shallow copy actually can be quite difficult at first,even if they already know the difference between shallow and deep copy.