Re: Automated indentation

Tim Peters (
Thu, 12 May 94 14:38:22 -0400

> > [tim]
> > Those who want this stuff need to identify the problems they're trying to
> > solve and propose something that actually addresses them <wink>.

> [marc]
> Quite simple: If someone, for whatever reason (inattention, bad tools ...)
> fears to encounter Python code which isn't formatted correctly, he/she can
> use "end ..." _everywhere_ and then let some simple tool (a Python program
> working as filter, without the need for a powerful editor, could do it) do
> the tiresome work of doing the format right.

But you can do that today, without any help from Python. E.g., adapt
John Redford's suggestion, and stick stylized '# end ...' comments at
block ends. Your "simple tool" can recognize those, yes? (hint: take
what it was _going_ to recognize, and put '# ' at the front <grin>)

What is it that you're proposing that _Python_ do differently? If all
you're proposing is that Python _ignore_ block closers, then John's
suggestion to write them as comments to begin with accomplishes that

And are you explicitly disassociating yourself from those who want
_Python_ to accept unindented input?

> Correctly indented code, from those who don't see a need for "end ...",
> could also be automatically con- verted to use "end ..." everywhere (by
> those who want the safety, not as a requirement for everyone!).

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, and just as likely to delete or insert
tabs "by mistake"; if a mixture of indentation and block-closers is
allowed, it's still impossible to deduce the intended blocking structure,
because you can't tell a mistake when you see one.

> Note I'm not at all suggesting to remove the mandatory indentation,

OK, so you don't care about the "text widget" argument -- that's not "a
problem" _you're_ trying to solve.

> nor do I plan to enter ugly code - I just want some more safety against
> mistakes, and the addition of an optional "end ..." bracket could
> satisfy this wish,

Disagree (see above); but _required_ "end ..." brackets could -- if
"safety" is the problem you're actually trying to solve (I'm not sure).

> without imposing any burden upon those programmers who don't want/need
> it.

Ditto for a "block-closers required" pragma, defaulting to the current
rules. At least that would _actually_ solve _some_ problem <wink>.

bemusedly y'rs - tim

Tim Peters
not speaking for Kendall Square Research Corp