Of course Python doesn't automatically ensure good code.
But the Python code in your example is readable -- pretty match as readable as it gets, considering the constraints I mentioned.
I still disbelieve. Ruby is as much a general programming language as Python, yet supports a syntax that I find much more readable. I even find the deprecated os.popen interface in Python to be more readable than the official Python 2.6 interface. And, of course, the Python 2.7 syntax is better.
Therefore I can't agree that the Python that I presented is as good as is possible for a general purpose programming language.
I'd have to disagree. In this case, the backticks are quite idiomatic, whereas the Python is less so.
The Python example can be broken down by someone who knows OOP concepts in general, but not Python. It says:
Invoke function Popen on the object subprocess, giving the arguments (for example) 'ls' and '-al' in a list. Standard output should be handled in some way that is indicated by the value of PIPE. On the object returned from Popen, call communicate(), which returns an array; take the first element off that returned array.
Now, in order to make sense of this you would need to know what the arguments to Popen are, what communicate() means and what it returns.
Does that require a trip to the documentation? Yes. Is it less readable? No, it's more readable. The understanding of what was read is not immediately conveyed, however.
The Ruby/Perl/Bash backticks mean nothing even if you have an OO background. Maybe if the command is 'ls' and you know some Unix, you can work it out in your head to understand that it's invoking a command in the shell. What if it's calling something obscure with a string of arcane arguments appended? That will tell nothing, and the backticks will also add zero information.
Backticks are more convenient, but readability is the ability of someone who doesn't know that particular concept, or even that language, to still parse a statement and extract some level of understanding.
Disagree with which? That the Python version is as readable as it could be? Don't argue that with me, argue with the decision to add a utility method that makes Python 2.7 better.
As for readability, I emphatically disagree with you on how it should be defined. Readability is the result of the interaction between the programmer and the code. The interaction cannot be left out of this. There is such a thing as well-written, readable Greek. But if you don't speak Greek, it will all be Greek to you. COBOL was designed to be readable. Can you read any significant COBOL program? Old FORTRAN programmers complained that Smalltalk hideously unreadable because they didn't understand the basic concepts of OO.
That said, something that is long and full of moving parts is inherently a challenge to read. Even if you understand every piece of that Python example (I happen to), when you encounter it in code there is a lot of semantic noise to what is written. That complexity can and should be hidden. As the Python 2.7 API does.
I think you've mistaken my argument. I didn't say that the Python version looks good or is the best way to do it. It's not.
I was saying that "something that is long and full of moving parts" is easier to read than something that is short and idiomatic. I am not saying either of them represent the ideal way to do it.
My definition of readability includes the ability to convey the programmer's intention to the mind of the reader. The reader should be able to work out what is intended by the code with minimal requirements placed on them, and I think I detailed earlier why I think the Python code does a better job than simple surrounding a shell command with backticks.
Unless I'm writing training material for novices, I write code with the assumption that anyone else maintaining it is reasonably competent with the languages, libraries, and tools in question. That to me is a minimal requirement.
