Why not allow empty code blocks?
BartC
bc at freeuk.com
Sat Jul 30 08:27:16 EDT 2016
On 30/07/2016 12:49, Chris Angelico wrote:
> On Sat, Jul 30, 2016 at 9:39 PM, Rustom Mody <rustompmody at gmail.com> wrote:
>> 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.
The parentheses are a nuisance in C too, as are obligatory format codes.
And C created a lot of bad precedences (literally in the case of binary
operators!)
For an informal, rapid development language, the less formality about
these things the better.
>> - 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,
The language finds other solutions so that programs using "print A"
don't need changing. Perhaps 'print <list>' is syntactic sugar for
'_print (<list>' or something.
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=.
This is one thing I can never get right in Python: controlling when a
newline is or isn't generated and what happens with separators.
(In fact when I used Python as a target language, I had to generate
calls to sys.stdout.write instead as it had more predictable behaviour.)
So if it's the advantage of using () then it's one I never benefit from!
Newline control should be one of the simplest things in the language,
part of the very first programs you write.
(Some languages use 'write' or 'writeln', or 'print' or 'println'; what
could be simpler? Or you just explicitly output a "\n" string.)
--
Bartc
More information about the Python-list
mailing list