Why not allow empty code blocks?

[Steven D'Aprano]

On Sat, 30 Jul 2016 09:39 pm, Rustom Mody wrote:

> On Saturday, July 30, 2016 at 4:56:01 PM UTC+5:30, Chris Angelico wrote:
>> On Sat, Jul 30, 2016 at 8:15 PM, BartC wrote:
>> > Anyway, if you're going to talk about annoying things forced upon you
>> > by the language, what about:
>> >
>> > "()" in "print (x)" for Python 3
>> 
>> Why are you singling out print? It's just a function like any other.
>> Are you complaining about the way function calls need parentheses?
> 
> Its a function… ok.
> Its ‘just’ a function… Arguable

"Granny Weatherwax, you are a natural-born disputant."
"I ain't!"


> For example:
> 
> - Prior Art: Its builtin and special in Fortran, Pascal, Basic

Possibly Fortran. But which version of Fortran? Do we really want to take
decisions made in 1953 for the first ever high-level language as the
epitome of good design?

Pascal? There is no "print" in standard Pascal, there are a pair of
procedures writeln() and write().

Early BASIC has a built-in print statement, but BASIC had very little
facility for functions or procedures. *Every* built-in command
was "special" to a language where you used GOTO and GOSUB instead of
functions.

And in any case, Python's print is a built-in, so it is *just as special* as
Fortran, Pascal and BASIC versions.


> - More immediate : It was a special in python2

It was *too* special in Python 2.

Being a statement, there's nothing you can do with it except use it
directly. You can't pass it to another function, or use it as a callback,
or apply functools.partial to it, or monkeypatch it. When people proposed
adding new functionality to it, the ability to print to a file, instead of
adding a simple keyword argument, the actual grammar of the language had to
be changed to support a hideously ugly variant:

    print >>file, args

If Python had originally been a function, and somebody proposed making it a
statement, what do you think the chances are that proposal would be
accepted? Some design decisions are simply bad ideas, and making print a
statement was one of them.


> - Poorer error catching: What was a straight syntax error is now a
> lint-catch (at best)
>   [print (x) for x in range(20)]

Using a list comprehension just for the side effects is *poor practice* but
legal. Besides, perhaps print() has been monkey-patched to return a useful
value, which you wish to collect in a list.

Its not the compiler's job to decide what is and isn't good code. There are
an infinite number of things a programmer can do which is "poor practice".
Should we try to make them all syntax errors?

# Calculate x plus ten.
y = x + 1
y = y + 1
y = y + 1
y = y + 1
y = y + 1
y = y + 1
y = y + 1
y = y + 1
y = y + 1
y = y + 1
y = y + 1
y = y - 1  # Oops, we went too far, go back one.


Should we insist that Python must have a "add 10" statement, and forbid the
plus operator, so that poor quality code like the above will be a syntax
error?

# new and improved special syntax
addten x as y


print never should have been a statement. Being a built-in function is
special enough.




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