Why not allow empty code blocks?

[Steven D'Aprano]

On Sun, 31 Jul 2016 12:16 am, BartC wrote:

> On 30/07/2016 14:06, Steven D'Aprano wrote:
> 
>> 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.
> 
> You mean languages that allow code like this:
> 
> a = (
>             b
>   +c *
> 
> 
> d)
> 
> ?

Touché :-)


But the layout of an expression is not really what I'm referring to. The
whitespace between terms in an expression is meaningless. Yes, the example
you give is particularly ugly, but it's no different from:

a = (   b  +c *   d)

on one line. Allowing parentheses to cross over line boundaries is a case of
Practicality Over Purity: there are simply far too many cases where we
want, *need*, a single expression to go over two or more lines, and the
original solution (use a line continuation backslash) wasn't good enough.

I'm referring to flow control elements (if...else, for, while, try...except,
etc), plus a handful of other grouping elements (def, class, with). That's
what I call "logical structure" of the code, not incidental whitespace
between terms of a single expression.

Unfortunately, there's sometimes a conflict between these disparate wants. I
want the logical structure to be obvious; I want the freedom to arrange
expressions over multiple lines. Sometimes they conflict, in which case, I
do my best not to write ugly code. I'd be reluctant to prohibit expressions
from starting at the left of the current indent:

    # This should always be allowed
    def func():
        # current indent aligns here
        result = (
                  long expression
                  over multiple lines
                  )
        return result

    
    # But this moves to the left of the current indent
    def func():
        # current indent aligns here
        result = (
    long expression
    over multiple lines
    )
        return result



I don't like that second case very much at all, but I wouldn't prohibit it,
because I've found too many real world cases where I have big expressions
(say, a table of values) where I need all the space I can get and need to
visually outdent it without logically outdenting it. Its an ugly compromise
between my otherwise very strict view, but that's life for you.


> Another category is where code is written predominantly side-ways rather
> than vertically. (Multiple chained method calls for example, or trying
> to express something as a 'one-liner'.)

I don't see the relevance. If you are writing a chain of method calls, its a
single expression. There's no structure to express.

As for one-liners, Python simply doesn't consider it important or necessary
to support writing arbitrary one-liners. There's some limited support for
the simple cases:

python -c "for x in range(100): print(x**2)"

but beyond that, you have to use multiple lines.



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