BartC <b...@freeuk.com>:
> On 29/07/2016 20:43, Terry Reedy wrote:
>> So put in 'pass' whether or not there is no debugging code,
>> commented-out debugging code, or debugging code that runs, or whatever.
>
> But that's inelegant.
>
> The language requires that blocks always contains 1 or more
> statements. Fair enough, except that 0 statements are often needed so
> that a dummy statement - 'pass' - is required just to keep the code
> legal.
>
> That's untidy, as is your suggestion to keep the dummy statement lying
> around anyway so that the number of statements will always be N+1 and
> can never reach 0 as N changes.
Yes, untidy, albeit only slightly. What you gain is visible blocks.
The gods have spoken and have decided for visibility over philosophical
elegance.
I *have* been hit with analogous untidiness in classic C, which didn't
accept empty structs or empty arrays. I was generating C arrays from a
compiler and--annoyingly--had to place special checks in the compiler to
place a dummy element in an array where none would be generated
naturally.
I have also had to spend some time debugging some segmentation faults
caused by #ifdef's and surprising sizeof calculations in (classic) C and
(modern) C++. Look at this structure:
struct S {
int x[0];
};
Gcc claims sizeof(struct S) == 0 in C and C++.
Well, that's natural, right?
How about:
struct S {
};
Now gcc claims sizeof(struct S) == 0 if the language is C but
sizeof(struct S) == 1 if the language is C++.
That's because Stroustrup is allergic to 0-size data structures the way
GvR is allergic to 0-size blocks.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
