[keeperofdakeys]

You are depending on an undefined side-effect, specifically that adding two lists returns a new list. This is a very bad habit, especially if you move to a different language that doesn't have such behaviour. When you are programming, you should be writing what you want to do, not depending on side-effects to do it for you. People reading your code (including yourself in the future) would have to spend a lot more time working out what the code does otherwise. The only real exception to this is C on embedded hardware, where you really need to use lots of these tricks.

What if you wrote `b = b + []`, some languages might just append to b, and not create a new list (python seems to create a new string). Slices can still be seen as having the same problem. Really you should be using the Copy module or the List constructor, which have the implicit guarantee of a new list.

[jrockway]

This argument is silly. Python is not some other programming language, so when you're writing Python, it doesn't matter what other programming languages do. If you use the same idioms in every programming language that you use, you're writing bad code in every programming language that you use. So don't do that.

The reason why list(x) is better than x + [] is because list(x) works regardless of what type of iterable x is. x + [] only works on lists.

[keeperofdakeys]

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.

[jrockway]

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.

[ak217]

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.

[kingkilr]

That isn't an undefined side-effect, that's the definition of the operation.

[keeperofdakeys]

It depends on which scope you define it at. Within the python interpreter, and the guarantees it gives, it is one of the definitions. However, at a higher level, the definition is really to give one variable the value of one list appended to another; without knowing how python works, you can't guarantee that it will be a new list.