Python is readable

[Steven D'Aprano]

On Mon, 19 Mar 2012 09:02:06 +1100, Chris Angelico wrote:

> On Mon, Mar 19, 2012 at 8:30 AM, John Ladasky <ladasky at my-deja.com>
> wrote:
>> What I would say is that, when PROGRAMMERS look at Python code for the
>> first time, they will understand what it does more readily than they
>> would understand other unfamiliar programming languages.  That has
>> value.
> 
> This is something that's never truly defined. 

I'm sorry, I don't understand what part of John's sentence you mean by 
"this". "Programmers"? "Value"? "Understand"?


> Everyone talks of how this
> language or that language is readable, but if you mean that you can look
> at a line of code and know what *that line* does then Python suffers
> badly and assembly language wins out; 

This is at least the second time you've alleged that assembly language is 
more readable than Python. I think you're a raving nutter, no offence 
Chris :-)

Assignment (name binding) is close to the absolute simplest thing you can 
do in a programming language. In Python, the syntax is intuitive to 
anyone who has gone through high school, or possibly even primary school, 
and been introduced to the equals sign.

x = 1234
y = "Hello"

In assembly language, not so much. I wouldn't even have begun to guess 
how to assign variables in assembly, or even whether such a thing is 
possible, but a few minutes of googling gave me this:

# 8086 assembly
x dw 1234
y db 'Hello', 0

# MIPS assembly
x:     .word       1234
y:     .asciiz     "Hello"


I don't know about anyone else, but I wouldn't have guessed that the way 
to get x=1234 was with "x dw 1234".

What's more, with Python, one example hints on how to do other examples. 
Having seen x=1234, most people would guess that x=1.234 would also work. 
I'm pretty sure that "x dw 1.234" will do something surprising, although 
I don't know what, but it certainly won't be to assign the float 1.234 to 
a variable x.

So there we have another measure of "readability" -- discoverability. 
Having seen one example, how easy is it to predict slightly modified 
examples?

In assembly's case, not very predictable. What's the difference between 
these two lines?

a db 127
b db 327

For that matter, what will the second line actually do?

The thing is, these aren't "advanced features" of assembly language. It's 
not like trying to understand metaclasses in Python. These are the basic 
foundations. You can read vast swathes of simple Python code without 
needing to learn the gory details of Python's data model (name binding of 
objects, everything is an object), but you can't even *begin* reading 
assembly language without a good grasp of the data model and jargon.

Assembly has a very steep learning curve. Python has a shallow curve.

Here's another indication of readability. There have been occasional 
suggestions on Wikipedia that they standardize on Python as "executable 
pseudo-code" for code samples. Now replace "Python" with assembly 
language. Unless you're Donald Knuth, the idea is ridiculous.

Another factor related to readability is the primitiveness of the 
toolset. Assembly has a very low-level, primitive toolset. How would you 
write this in assembly?

print(sorted(somelist))

If all you have is a hammer, the instructions you get are easy to 
understand because there's not much you can do with it. How complicated 
can "hit the nail with the hammer" get? But the right measure is not the 
simplicity of the tasks you *can* do, but the comprehensibility of the 
tasks you *want* to do.

"How do I build a tree house using nothing but a hammer?" I'm sure that, 
given sufficient ingenuity, you could build a tree house with nothing but 
a hammer, lumber and nails, but the detailed instructions would be 
complicated and difficult. How much simpler it becomes with a more 
powerful set of tools.

Assembly is simple, like a hammer. (Well, perhaps not *quite* as simple 
as a hammer.)


> but if you mean that you should be
> able to glance over an entire function and comprehend its algorithm,
> then I have yet to see any language in which it's not plainly easy to
> write bad code. Even with good code, anything more than trivial can't be
> eyeballed in that way - if you could, what would docstrings be for?

The measure of the readability of a language should not be obfuscated or 
badly written code, but good, idiomatic code written by an experienced 
practitioner in the art. Note that there is a deliberate asymmetry there: 
when judging "readability" (comprehensibility), we take idiomatic code 
written by somebody who knows the language well, and give it to a novice 
to interpret it.

On this measure, Python has actually become *less* readable in recent 
years, with the addition of powerful new idioms such as generators, list 
comprehensions, with statement, etc. They are very expressive, and Python 
is much better off with them, but they are less readable in the sense I 
am talking about: readable to somebody who is not an expert in the 
language.

For this reason, when dealing with beginners, or writing code intended as 
"executable pseudo-code", I try to stick with features that worked in 
Python 1.5 where possible. E.g. for-loops rather than list comprehensions.


> Really, the metric MUST be Python programmers. Intuitiveness is of
> value, but readability among experienced programmers is far more useful.

But by that metric, Brainf*** is readable, since an experienced expert in 
the art of writing BF code will be able to recognise BF idioms and 
interpret them correctly.

No, I'm sorry, I disagree that the standard of readability should be the 
experienced programmer. By that standard, "readability" is a no-op. All 
languages are, more or less, equally readable, to those who can read them 
well. I don't think it is useful to judge the readability of Forth on the 
ability of Charles Moore to read it. How does that help me decide whether 
to use Forth for my next project?


> If I write a whole lot of code today, and next year I'm dead and someone
> else has replaced me, I frankly don't mind if he has to learn the
> language before he can grok my code. I _do_ mind if, even after he's
> learned the language, he can't figure out what my code's doing;

Then he hasn't learned the language *sufficiently well*. Either that, or 
your code is obfuscated, unidiomatic crap. Perhaps you're trying to write 
BF in Python :)



-- 
Steven