def a(arg = []):
return arg
a([1]) #==> [1]
arr = a() #==> []
arr.append(1)
a() #==> [1]The obvious alternative in this case would be to reconstruct the default value. This doesn't work very well with the language's evaluation model - since the function definition is only evaluated once, and it's very inefficient and in fact surprising to perform later re-evaluations.
Furthermore, this behavior can be useful. If you don't want it, you just use `None` as the default and then assign in the function body. However, if you do want it, there would be no other way to get it, and no similarly easy workaround.
Finally, had there been a consensus of it being a wart, it would have been removed in Python 3.x. It wasn't.
There are many warts that will never go away simply because they're embedded so much within the culture of the language and because undoing the wart would break so much working code.
I love python and I've used it every day for 15 years but there are core parts of the language I hate with a passion.
If in 3.9:
* "if x" started failing with an exception for most non-boolean values of x (e.g. lists, strings, numbers, etc.)
* strings stopped being iterable by default
then I'd be celebrating, but I know it's never going to happen.
I would call that a personal preference, and one that is far from consensus, rather than a "wart".
A wart is a known problem in the language, that most users consider to exert a negative impact on their usecases. Example would be Type Erasure in Java, which is there for historical reasons, can not be fixed, and is generally agreed by Java programmers to be a Bad Thing.
There isn't anything like this consensus for the changes you are suggesting.
All other mainstream languages support use of non-booleans as predicates, including for example C++ and Java, which are statically typed.
This change would make Python more strict about typing than virtually all mainstream static languages! Given how Python is dynamically typed, I'd suspect this change would be extremely unpopular.
> strings stopped being iterable by default
Again, not something most people would use. There are many fields in which strings are used to store sequences of characters where each character has a meaning. In all those fields, `for char in string` is a very useful idiom.
I'm not sure how this is a wart or what's your usecase that string iterability is breaking. Indeed, strings being iterable is in line with the general iterability philosophy and unlikely to change (which is a good thing for most users).
shrug it's two features that I see causing two classes of bugs on an extremely regular basis.
It's a trade off that affects everybody, but it's hard to weight up the trade off without a lot of experience.
>There isn't anything like this consensus for the changes you are suggesting.
Exactly what I said, yes...
>This change would make Python more strict about typing than virtually all mainstream static languages!
I think dialing up the strictness is a good thing and so do the language designers (that was the idea behind introducing type hints).
>Again, not something most people would use.
That's exactly the point. Making strings iterable list of characters isn't something that most people use - its primary function is to cause weird bugs for functions that take lists of strings (and you get an output like 'm', 'y', 'd', etc.).
Changing it so that you'd have to do string.chars to get an iterable list would, at very little cost, cut out a pretty common class of bug.