I've done quite a bit of Python and I agree. If you want to be "readable" or explicit that you want to copy the list, then you use copy.copy().
There is absolutely nothing wrong with [:]. This kind of judgmental critique of code is completely absurd IMO. If someone doesn't know something as basic in Python as slices, he or she shouldn't be reading Python code. If by all means you want to have people who don't know Python reading and understanding your code somehow, try copy.copy(). It's not like the performance hit is meaningful compared to list() and [:] is the fastest of the three.
Comments
As somebody who doesn't know python, I find a = list(b) to be not very intuitive. b is a list already, why call list() on it?
So I don't think you gain any readability over the slicing syntax.
I've done quite a bit of Python and I agree. If you want to be "readable" or explicit that you want to copy the list, then you use copy.copy().
There is absolutely nothing wrong with [:]. This kind of judgmental critique of code is completely absurd IMO. If someone doesn't know something as basic in Python as slices, he or she shouldn't be reading Python code. If by all means you want to have people who don't know Python reading and understanding your code somehow, try copy.copy(). It's not like the performance hit is meaningful compared to list() and [:] is the fastest of the three.
Copy constructors are a much more common idiom in programming than taking a slice of an entire list.
For instance, Java, .NET, ruby, C++ STL and Objective C. Most languages use them.
http://download.oracle.com/javase/1.4.2/docs/api/java/util/A...
http://msdn.microsoft.com/en-us/library/fkbw11z0.aspx
http://www.ruby-doc.org/core-1.9.3/Array.html
http://www.cplusplus.com/reference/stl/list/list/
http://developer.apple.com/library/mac/#documentation/Cocoa/...