Why not allow empty code blocks?
Steven D'Aprano
steve at pearwood.info
Sat Jul 30 10:47:08 EDT 2016
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.
More information about the Python-list
mailing list