There's more than one way to do it *vs* there should be one, and preferably only one, obvious way to do it
Loops, list/dict comprehensions, if statements, and ternary expressions would all like a word
The "never have to know or touch" argument applies only to the lone hacker working on a completely new project with no inherited legacy code.
I’m baffled as to how it retains its reputation of being a simple language.
In [5]: def cap(x):
...: xs = []
...: for i in range(3):
...: x+=1
...: xs.append(x)
...: return xs
...:
...:
In [6]: cap(numpy.array(0))
Out[6]: [array(3), array(3), array(3)]
In [7]: cap(0)
Out[7]: [1, 2, 3] >>> a = b = (1, 2) >>> a = b = (1, 2)
>>> a += (3,) >>> a = a + (3,)
>>> print(a, b) >>> print(a, b)
(1, 2, 3) (1, 2) (1, 2, 3) (1, 2)
Sometimes it does something different: >>> a = b = [1, 2] >>> a = b = [1, 2]
>>> a += [3] >>> a = a + [3]
>>> print(a, b) >>> print(a, b)
[1, 2, 3] [1, 2, 3] [1, 2, 3] [1, 2]
IMO if that behaviour had been "carefully thought out" by the language designers, it should have been obvious that it's a bad idea.Failing that, the implementation of that behaviour is convoluted - so the designers should have paid attention to the Zen of Python: "If the implementation is hard to explain, it's a bad idea".
Failing that, if the behaviour had been "explored to great lengths", the designers would have understood how it interacts with other language features - in particular, nested mutable and immutable objects.
Python's designers failed to do any of these things, so we've ended up with an operator with unpredictable behaviour and a long FAQ entry [0] about how its possible for an operator to both succeed and fail at the same time:
>>> a = ([1, 2], 4)
>>> a[0] += [3]
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: 'tuple' object does not support item assignment
>>> a
([1, 2, 3], 4)
[0] https://docs.python.org/3/faq/programming.html#why-does-a-tu...Either you get Scheme, or languages with features.
Even C isnt' as "simple" as people take it to be.