The first code is equivalent to:
list_multiply([x], 4)
(the function is actually called list.__mul__, but that's an unimportant detail). The latter is a syntax sugar for:
out = [] for _ in range(4): out.append(x)
(actually a bit more complex, but close enough).
When you understand it, the behavior is obvious in both cases.
There’s a separate type called tuple specifically designed to represent lists-as-values.
If you do [()]*4 then you get exactly what you want.
tuples are also references, but to an immutable object.
> If you do [()]*4 then you get exactly what you want.
I think what is actually wanted here is four different mutable lists rather than the same mutable list four times, something like what you would get from:
[[] for _ in range(4)]I can't think of anything that's a value? At least since Java, the idea of "everything is an object" seems pretty dominant in most languages.
There are a few immutable types, like ints, strings and tuples, but you still refer to them by reference.
It is always clear, and it is 100% always a reference, with a set of cases where that reference is to a singleton or immutable object, and a subset of those cases where, in particular Python implementations, that singleton may effectively be implemented as a special case value.
If you treat it as a reference, you will never, ever be wrong.
The critique here is that it's a badly designed language in that it's design decisions often get in the way of writing software that works as you expect. We're not discussing about whether you can learn such a system. The discussion is a lament on why it had to be this way.
Maybe. But that's largely irrelevant since we are discussing the impact of a syntax choice regarding an operator on an explicitly-mutable container type, and specifically the behavior of it used when the container also contains a member of the same type.
And the alleged surprising thing is not the mutability of anything, but thar after the operation, all the members of the other container are the same instance of the inner mutable container type.
Python being designed ground up with immutability by default and explicitly opt-in mutability would not directly have any bearing on this issue, as long as it still had the capacity to express immutable lists and the capacity to apply something like the list-reptition operation to them. Except it would probably make all of the involved examples more verbose.
I think the small example is misguiding the intuition here.
If I write `my_list = f(expensive operation); long_list = my_list * 4`, I don't expect python to recreate the whole thing four times. I justly assume `f` will be evaluated once, and then copied.