allowing braces around suites

[Alex Martelli]

Kjetil Torgrim Homme <kjetilho at yksi.ifi.uio.no> wrote:
   ...
> code I read can be using "#fi", "# end if", "# }", "pass" or nothing.
> sure, I can write a tool to enforce a single coding standard for my
> project, but external code will naturally not comply.  that's why I
   ...
> my hope is that my solution can be ignored by those who don't need it,
> and used by those who like it.

Unfortunately, if you make it optional, "external code will naturally
not comply" still applies.  Either for your solution or for any of those
you list above, you need in any case a simple tool that will take
noncomplying (but otherwise assumed to be correct) code and insert the
terminators.  Given that you need this tool, why not also have the tool
able to CHECK that a module complies?  This way you don't need to change
Python to give a syntax error for non compliance.

Best of all, the hypothetical tool almost exists, you have it:

...whereveryoukeeppython.../Tools/scripts/pindent.py

It uses the '# end if' style, but you could alter that in your copy.
The 'almost' is because I don't think it has the 'just check and tell me
if something wrong' functionality -- it's just able to insert or remove
the terminators into/from an otherwise correct source, and to fix up
indents in a source file which has proper terminators -- from the
latter, a switch to have it just check shouldn't be hard to add (exit
with error indicator if any fixup would be needed, say).


Once you have scripts that do whatever checking you wish and have a
uniform specified way to signal errors, you could think of a general and
truly useful addition to Python: a commandline switch (ideally settable
as a sys. attribute at runtime too) that makes it run checking scripts
automatically as part of the compilation process when it imports any
source (.py) file.  This would put pay to the problem common to all
"offline" checkers -- "the checker would have diagnosed the problem but
I did not run it".  You could run pindent, pychecker, unit tests,
_whatever_ -- possibly at the price of slowing down imports of newly
edited sources, but that depends on how thoroughly you want to check,
only.  What we need, I think, are good conventions to determine what to
run on the source (before compilation), what on the bytecode (right
after compilation, or possibly even, every time, even when importing a
bytecode .pyc file), how a checker lets Python know about problems, how
Python in turn diagnoses them to the user.

Hmmm -- I'm thinking that the existing import hooks might be enough to
let one prototype this "automatic checking" functionality, not quite as
smoothly as a fully architected system maybe, but enough to get some
early adopters, shake out teething problems, build a constituency to
lobby for smoother integration in a future Python version...


Alex