x + [] or x[:] still has a readability issue, to anyone who hasn't done much python before, it isn't immediately obvious that you want to create a new list. For personal scripts, this may not matter too much, but for code that is seen by other people, you may be inhibiting their understanding.
A good analogy is probably assuming that pointer sizes are the same as int sizes in C. This assumption was safe for many years, but broke when 64-bit came along. Slices and adding lists will probably always return new lists in python, but it is still good not to depend on such behaviour.
It's silly for you to dumb down code for people new to the language. If you treat newbies like they're dumb, they'll never learn how to write "real" code. The only way they'll do that is by reading real idiomatic code.
Slices and adding lists will probably always return new lists in python, but it is still good not to depend on such behaviour.
Not buying this. The behavior is documented and Python has a deprecation cycle for changes in documented behavior.
The reason to write list(x) is because that's the generic way to turn anything into a list. It's not for being future proof or being easy for newbies to understand. It's because that's the right way to do it.
Python is committed to code readability. It has nothing to do with people being dumb. It has to do with making a language which is cognitively compatible with a spoken language that we have been practicing every day since birth. var[:] is obscure and requires more mental effort to parse than list(var). Because of that, it's preferable to var[:] from a readability standpoint as well.
A good analogy is probably assuming that pointer sizes are the same as int sizes in C. This assumption was safe for many years, but broke when 64-bit came along. Slices and adding lists will probably always return new lists in python, but it is still good not to depend on such behaviour.