Why not allow empty code blocks?

Steven D'Aprano steve at pearwood.info
Sat Jul 30 09:06:11 EDT 2016


On Sat, 30 Jul 2016 08:15 pm, BartC wrote:

> Interesting use of 'pass' in this example:
> 
> http://pastebin.com/aYJdgEL4
> 
> (I do believe he's using 'pass' as 'end'! Although he misses some out in
> that case.)

I wouldn't call it so much "interesting" as "a good example of how not to
program".

All languages -- human and programming -- involve certain quirks, or
features which are matters of taste. If it a sign of a poor programmer that
ignores the common idioms of a language and writes in another
language's "grammar".

"If so smart Yoda is, how come English speak he cannot?"

People are more forgiving off grammatical errors and weird idioms than
computer programs, but still, there are conventions to follow. In English,
we can talk about having a quick meal of fast food, but not a fast meal of
quick food. Our computers are powerful, never mighty, and if we ever invent
a time machine, we'll travel into the past, not onto the past.

You can get away with breaking a language's idioms for humour:

https://www.youtube.com/watch?v=MNyG-xu-7SQ

or, if you're *really* talented, as art. See, for example, James Joyce's
Finnegan's Wake, which is as unidiomatic as it is possible to be while
still being (just barely) English, but deliberately so.

(As opposed to "ee cummings", who was and is lauded far beyond his actual
talent.)

Th same principles apply to programming languages. But outside of highly
optimized code, which is often ugly, or examples of code as art (like code
golf, Obfuscated C and Underhanded C competitions, multi-language hybrid
code, esoteric languages etc.), the aim of programming should be to
maximize *human* communication. And that usually means writing in the
idiomatic style of the natives. There are no awards for trying to hammer
the round pegs of Algol grammar into the square holes of the Python
interpreter.

(1) Using "pass" as a form of "end" is simply bizarre.

(2) Python allows the semi-colon for the convenience of command-line users,
where it is sometimes difficult to write multiple lines of code. Using it
inside a .py file is a sign of somebody who is not a native speaker.

(3) Separating statements by variable numbers of spaces, between 1 and 13 by
my count, is just weird.

Given the lack of Python fluency, the lack of documentation and meaningful
comments, the unusual (for Python) idioms that hurt readability, and some
very odd names (there is one constant called "ONE" with the value
1073741824), the overall impression I get is that the author of that file
simply isn't a good programmer.


[...]
> As I've mentioned, Python also uses explicit block delimiters in the
> form of else, elif, except, finally (and whichever ones I've misssed):


You are wrong. They are not delimiters. They *begin* a new block, they don't
end the previous one except as a side effect of beginning a new block.

if condition:
    block
new block

It is the dedent (outdent) that ends the if block. "new block" is permitted
to be an elif or else statement, of course, but you cannot write:


if condition:
    block
    else: statement

because "else" is not an "end of if" statement. It *begins* a new statement.


>   if x: a; b elif y: c; d elif z: e; f else: g

That's not legal Python syntax.


> In the above syntax, it would be:
> 
>   if x then a; b elsif y then c; d elsif z then e; f else g fi
> 
> Doesn't it look like there's something missing in the Python? 

No it does not.



> Both the 
> 'fi' or 'end', and the possibility of an 'h' statement.
> 
> Note the Algol68-style style is more free-format where indents are not
> significant.

Good for Algol. To my eyes, that makes it harder to read: too many
unneeded "ends", to great a risk that the visual structure of the code
doesn't match the logical structure of the code.


> Anyway, if you're going to talk about annoying things forced upon you by
> the language, what about:
> 
> ":" after "else"

What about it? When you write a list of items in English, it is more
idiomatic and natural to end the clause with a semi-colon:

- item one
- item two
- item three


than without it.

I've read Cobra code which is very like Python except (among other changes)
they've dropped the semi-colons It simply looks wrong Like sentences
without punctuation Or perhaps like an painting on a wall just every so
slightly on an angle


> "()" in "def fn():"

I could go either way with that.


> "()" in "print (x)" for Python 3

Why? Do you object to other functions using parentheses?


> "for i in range(N):" just to repeat a block N times...

Why should there be special syntax just for repeating a block N times?
There's a general purpose for-loop which performs iteration. Why do you
need special syntax to do what it already does?

We have a general "if" clause for doing conditional branching. Would you
insist on a special purpose if syntax for testing if a number is 2?

if number == 1:  # general case
if number == 7921  # general case
iftwo number:  # special syntax


> That's apart from the obligatory indents which, with an 'end'-delimited
> scheme, are not always necessary.

Of course they're necessary. The participants of the old "indent style wars"
of the 80s and 90s didn't agree on much, but they did agree on one thing:

- if you write code without indentation that matches the logical structure
of the code, you're a bad programmer.

End of story. As far as I am concerned, the 97% of languages which allow the
visual structure of the code to differ from their logical structure are BAD
LANGUAGES.




-- 
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.




More information about the Python-list mailing list