Yes, the tool could do it; but unless the tool is always applied to all
code, there's a chance that an unwanted change of indentation would not
be caught, whereas the non-comment version would use the compiler for a
consistency check, without much additional work (according to Guido). I
agree that your proposal of "require end on demand" would be yet safer.
> And are you explicitly disassociating yourself from those who want
> _Python_ to accept unindented input?
I agree with Guido's intention of not having the human eye be fooled by
bad indentation, but I don't like unintended indentation errors causing
semantic errors. I think the "end ..." version, together with the check
for correct indentation, would satisfy both goals.
> If block-closers aren't *required*, there's no gain in safety. A person
> is just as likely to forget to type a block-closer as they are to fiddle
> their indentation inappropriately,
Yes, but hardly both at the same time. Well, as I think about it ... we
should really have line numbers to find unintended line deletions. Hmm,
we could also require each line to be duplicated, thus finding yet more
unwanted modifications. Maybe add a MD5 signature for each source file,
to detect bad data in the file system? <grin>
> Ditto for a "block-closers required" pragma, defaulting to the current
> rules. At least that would _actually_ solve _some_ problem <wink>.
No problem, as far as I'm concerned (but I'm not so sure whether that's
likely to become consensus).
------------------------------------------------------------------------------
* wonder everyday * nothing in particular * all is special *
Marc Wachowitz <mw@ipx2.rz.uni-mannheim.de>