Why not allow empty code blocks?

[Chris Angelico]

On Sat, Jul 30, 2016 at 9:39 PM, Rustom Mody <rustompmody at gmail.com> 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 3the modulo operator
>>
>> 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
>
> For example:
>
> - Prior Art: Its builtin and special in Fortran, Pascal, Basic

And it's not built-in or special in C, or a bunch of other languages.

> - More immediate : It was a special in python2

Which resulted in unmitigatable problems, such as that you can't mock
it for testing or redirection purposes, and it demands syntactic magic
to do its work - for instance, the only option is a "soft space" in
place of a newline, where the print function allows full customization
of both end= and sep=. The print function is DEFINITELY an
improvement. I would also posit that an sprintf() built-in function
instead of str.__mod__ would have meant there was less kickback
against printf-style formatting, because it wouldn't have had the
strange behaviour around single-argument use. (It's pretty simple to
write, of course, but built-ins are extremely significant to
perception. def sprintf(fmt, *args): return fmt % args) Syntax is NOT
always an improvement.

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

Huh? Aside from the fact that you're constructing a useless list of
Nones, what's the error?

Also: Why is print special here? Maybe you accidentally called
frobnicate on those x's and you shouldn't have. How is Python supposed
to know that that's an error?

ChrisA