Why not allow empty code blocks?

Joel Goldstick joel.goldstick at gmail.com
Sun Jul 24 08:28:40 EDT 2016


On Sun, Jul 24, 2016 at 8:17 AM, Steven D'Aprano <steve at pearwood.info> wrote:
> On Sun, 24 Jul 2016 08:35 pm, BartC wrote:
>
>> I didn't want to get into this subject again, but Python's indentation
>> scheme is fragile.
>
> *shrug*
>
> Okay, it's fragile. In 20 (give or take a couple) years of programming in
> Python, do you know how many times this fragility has been an *actual*
> problem? Why don't you take a guess?
>
>
>> Given an otherwise correctly typed program that compiles with no errors,
>> then it is very easy (if Backspace or Delete is inadvertently pressed
>> for example), for an indent to disappear without your noticing,
>
> Not really. It depends on the editor, but typically you need to have your
> text insertion point somewhere in the indent.
>
> And when you do accidentally press Delete, what happens? The high-level
> structure of the code changes. Typically things will no longer align:
>
> def f():
>     for x in seq:
>         do_this()
>     do_that()
>         do_more()
>
> which is a SyntaxError. It requires quite the coincidence before you can
> accidentally delete an indent and have the code still run. Far more likely
> is that accidentally pressing delete will break the code in a way that
> can't be detected until runtime:
>
> def f():
>     for x in seq:
>         do_this()
>         d_that()
>         do_more()
>
> Conclusion: if you're the sort of person who habitually presses the Delete
> or Backspace key without paying attention, you're going to have a bad time.
>
> (Do other professions make arguments like this? Do carpenters, say, argue
> against nail guns because "well if you accidentally hold a loaded nail gun
> to your head, then press the trigger, bad things will happen"? Or is it
> just programmers who make a common practice of arguing that the programming
> language should protect the user from sheer carelessness?)
>
>
>> but a
>> program still compiles. And still runs without execution errors. But
>> might now be subtly wrong.
>
> That's certainly *theoretically* possible, but its really not likely. The
> only way it could happen is:
>
> - you have a block with at least two lines;
> - your insertion point is in the indent of the last line of the block;
> - but not the actual text part;
> - your editor is configured to dedent on Delete/Backspace, not just
>   delete a single space; or you're using tabs to indent;
> - and the block isn't followed by another block (e.g. if...else...)
>
>
>
>> Deleting any other character than a leading space or tab I think is more
>> likely to result in an error that would be noticed, generate a compile
>> error, or execute error ('variable not initialised'), or that goes wrong
>> more obviously.
>
> pi = 314159  # oops accidentally hit delete
>
>
> [...]
>> But my suggestion is simply that you can write:
>>
>>       for x in sequence:
>>       end
>>
>> instead of:
>>
>>       for x in sequence:
>>           pass
>>
>> The first now allows statements to be added or removed from the body of
>> the loop without needing to change the 'end'; it wouldn't look out of
>> place as a trailing 'pass' would.
>
> You know, I suspect that you've probably spent more time talking about the
> effort required to delete and insert "pass" than the *actual* effort spent
> by a hundred programmers deleting and inserting "pass" in their code.
>
>
>> But thinking about it some more, it wouldn't work. All the blocks that
>> don't now use 'end' would look odd. I think it would either have to be
>> all or nothing. I guess nothing.
>
>
>
>
> --
> Steven
> “Cheer up,” they said, “things could be worse.” So I cheered up, and sure
> enough, things got worse.
>
This thread is beginning to feel like a dog whistle for people who
like braces.  I've been python coding since 2009 I think, and I think
I have used pass less than a handful of times. ... and except for sets
and dicts, I can't remember using a {

-- 
Joel Goldstick
http://joelgoldstick.com/blog
http://cc-baseballstats.info/stats/birthdays



More information about the Python-list mailing list