Automated indentation
George Reynolds
constantly for the last couple of months writing a C++ code generator
for binding python to a large C++ class lib.
My experience with the indentation based scheme is not unrelated to
others (as I found by reading through the mail archive) that at first
its very annoying and then one learns to like it. I definitely found
this to be true AT FIRST. But, as the program expanded and evolved, my
annoyance returned and now I find it to be a very serious flaw in
python's usability. (I did read Guido's recent message trying to
justify this scheme...sorry I dont buy your argument.)
This is a serious problem since Python is in most other respects
a fantastic language which I am recommending to all my friends
and associates.
As a program is evolving (as opposed to simply reading the code) one
is often cutting, pasting and otherwise modifying code quite
frequently. My experience is that I am constantly annoyed at having to
re-indent every line when the indentation could be automated since I
already did it correctly once.
Also, mistakes do happen. For example when using python-mode in emacs,
I hit tab on a line by mistake and that line gets indented 5 levels.
Where was it originally? Impossible to know unless I stop and grok the
meaining of the function... again.
Thus the issue is that indentation can be automated if desired.
Suggestion:
1. Optionally allow replacement of the ':' after control
statements with 'do' (or another reasonable word)
2. If 'do' is used insted of ':' the statement block is
terminated with 'end <keyword>' indented at the level of
the control word.
3. Not indenting the delimited block would yield a syntax error.
NOTE: This would be optional. If someone wants the current version
fine, if someone wants the proposed version, ok. Thus automated
indentation is possible if desired.
For example:
Current Python:
--------------
def rotateAll( param1, param2 ):
List = param1
blah
blah
blah
for item in List:
blah
blah
blah
blah
Proposed Python:
---------------
def rotateAll( param1, param2 ) is
List = param1
blah
blah
blah
for item in List do
blah
blah
end for
blah
blah
end def
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ George Reynolds +
+ VI Corporation +
+ 47 Pleasant St +
+ Northampton MA 01060 +
+ +
+ geo...@vicorp.com "You can't count on consistency" +
+ 413-586-4144 X Toolkit Intrinsics Programming +
+ Manual, page 245. +
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Marc Wachowitz
> Suggestion:
> 1. Optionally allow replacement of the ':' after control
> statements with 'do' (or another reasonable word)
> 2. If 'do' is used insted of ':' the statement block is
> terminated with 'end <keyword>' indented at the level of
> the control word.
> 3. Not indenting the delimited block would yield a syntax error.
I second that proposal. Though I haven't looked at the parser code, I
guess it wouldn't be an extremely difficult change, and it's surely a
win in terms of maintainability. After all, the current style "fixes"
mistakes with "indentation should match semantics" by silently taking
intentation errors (likely to be lack of attention rather than intent
of delusion ;-) as the true meaning of the code. I.e. the bug is just
declared to be a feature ...
------------------------------------------------------------------------------
* wonder everyday * nothing in particular * all is special *
Marc Wachowitz <m...@ipx2.rz.uni-mannheim.de>
Guido.va...@cwi.nl
> > Suggestion:
> > 1. Optionally allow replacement of the ':' after control
> > statements with 'do' (or another reasonable word)
> > 2. If 'do' is used insted of ':' the statement block is
> > terminated with 'end <keyword>' indented at the level of
> > the control word.
> > 3. Not indenting the delimited block would yield a syntax error.
I still don't like it, but I suppose for the benefit of people who
simply can't live with indentation, maybe we can invent an optional
keyword to be introduced at the end of an indented block, like
if foo and bar:
important_stuff()
more_important_stuff()
else:
less_important_stuff()
end if
where the 'end if' line would be optional and would have to be
indented properly and could be used by a re-indent routine.
This would be fairly simple for me to implement in the grammar. Note
that code inside an end-terminated block would still have to be
indented properly (else I think it WOULD require a major rewrite of
the scanner and/or the grammar) but I think we all can live with that.
I will leave the coding of the re-indenter to someone who actually
thinks they need it. :-)
--Guido van Rossum, CWI, Amsterdam <Guido.va...@cwi.nl>
URL: <http://www.cwi.nl/cwi/people/Guido.van.Rossum.html>
Marc Wachowitz
[...]
> if foo and bar:
[...]
> end if
>
> where the 'end if' line would be optional and would have to be
> indented properly and could be used by a re-indent routine.
Fine, thanks.
> Note that code inside an end-terminated block would still have to be
> indented properly (else I think it WOULD require a major rewrite of
> the scanner and/or the grammar) but I think we all can live with that.
Certainly - even if one had to reindent some ill-formatted code, it
would then at least be possible to do, without having to understand
it in detail.
Tim Peters
mind the "end if" etc business, but in the meantime:
> [george]
> ... For example when using python-mode in emacs, I hit tab on a line by
> mistake and that line gets indented 5 levels. Where was it originally?
`C-x u' (advertised-undo) restores it to its original position.
> As a program is evolving (as opposed to simply reading the code) one
> is often cutting, pasting and otherwise modifying code quite
> frequently. My experience is that I am constantly annoyed at having to
> re-indent every line when the indentation could be automated since I
> already did it correctly once.
Study the pymode docs for
`C-c TAB' py-indent-region
`C-c C-b' py-mark-block
`C-c <' py-shift-region-left
`C-c >' py-shift-region-right
For example, suppose you want to get rid of the 'if' clause in
n = n + 2
if n < psq:
for fac in facs:
if n % fac == 0:
break
else:
primes.append(n)
suspend(n)
psq = p*p
1) Stick point anywhere on the `if' line.
2) Do `C-c C-b'. The entire 'if' block is then marked as the current
region, and point moves to the 1st column of the `if' line.
3) Do `C-k C-k'. This deletes the `if' line.
4) Do `C-c TAB'. What was the body of the `if' block shifts 4 columns
left, to align with "n = n + 2".
Or suppose you have
n = n + 2
psq = p*p
in file A, have
def whatever(fac,facs,n):
for fac in facs:
if n % fac == 0:
break
else:
primes.append(n)
suspend(n)
return 1
in file B, and want to copy the `for' structure after the `n = n + 2'
line, and under the control of a new `if n < psq:' line.
1) In file A, go to the end of `n = n + 2' and do
LFD
if n < psq:
RETURN
2) Switch to file B, put point anywhere on the `for' line, and do
C-u C-c C-b
to mark the entire for/else structure.
Then the usual Emacs `M-w' (copy-region-as-kill) to copy it into
the yank buffer.
3) Switch back to file A, and do
C-y (Emacs yank; pastes the insanely indented for/else structure)
C-c TAB (reindents the structure wrt to the `if ...:')
If py-indent-offset is 4, you end up with
n = n + 2
if n < psq:
for fac in facs:
if n % fac == 0:
break
else:
primes.append(n)
suspend(n)
psq = p*p
I.e., so long as you're using Emacs, there's _never_ a reason to
"re-indent every line" by hand! pymode's `[C-u] C-c C-b' and `C-c TAB'
are pretty smart, but do take some getting used to. pymode's `C-c <' and
`C-c >' are stupid as nails, but can be used without surprise instantly
(they shift the current region left or right (respectively) rigidly, by
py-indent-offset columns, or by any other number of columns you specify
with a prefix arg). Note too that the region-shifting functions maintain
the current region, so can be chained (e.g., if `C-c TAB' doesn't get you
to exactly where you wanted to be, it can be followed immediately by a
`C-c <' (whatever) to fine-tune it).
Ironically enough, I suspect it won't really be much easier to cut/paste
if Guido does implement the "end if" etc gimmicks. It _certainly_ won't
be easier if pymode isn't taught about them too <wink>.
waiting-for-someone-to-exclaim-that-the-'end'-word-must-line-up-
under-the-block's-body-instead<0.4-grin>-ly y'rs - tim
Tim Peters t...@ksr.com
not speaking for Kendall Square Research Corp
Guido.va...@cwi.nl
> under-the-block's-body-instead<0.4-grin>-ly y'rs - tim
Personally, I'm waiting for one of the proponents of such a scheme to
come up with an implementation. If it works and doesn't render
existing Python code illegal (apart from adding the new reserved word
'end') AND enough people can agree one a solution, I'm happy to make
it a permanent part of Python.
Hint: if you want the 'end' line aligned under the block as Tim
suggests you're gonna have a lot more changes to the grammar and
compiler to make!
jred...@lehman.com
>> > waiting-for-someone-to-exclaim-that-the-'end'-word-must-line-up-
>> > under-the-block's-body-instead<0.4-grin>-ly y'rs - tim
>>
>> Personally, I'm waiting for one of the proponents of such a scheme to
>> come up with an implementation. If it works and doesn't render
>> existing Python code illegal (apart from adding the new reserved word
>> 'end') AND enough people can agree one a solution, I'm happy to make
>> it a permanent part of Python.
>>
>> Hint: if you want the 'end' line aligned under the block as Tim
>> suggests you're gonna have a lot more changes to the grammar and
>> compiler to make!
I've already done this. I did this a couple months ago and posted the
diff to the list.
def read(name):
if posixpath.isfile(name):
f = open(name,'r')
db = marshal.load(f)
f.close()
return db
# END
else:
return {}
# END
# END
def write(db,name):
f = open(name,'w')
marshal.dump(db, f)
f.close()
# END
Yes, the word 'END' lines up with the block body instead... py-mode
groks the '# END' tokens properly to allow indent-region & the like to
work.
And it requires no changes to python. I dont see a reason to add this
to python at this late date. Either use emacs, or write a 'indent' for
python code that also groks these.
If people want this, then pester Tim to add it to py-mode. (Tim, I
assume you still have the diff I posted. I havent mangled the new
py-mode yet.)
--
John Redford (AKA GArrow) | 3,600 hours of tape.
jred...@lehman.com | 5 cans of Scotchguard.
Tim Peters
> in the bodies of blocks as a side-effect of closing them with DEL,
> like ...]
> ...
> def read(name):
> if posixpath.isfile(name):
> f = open(name,'r')
> db = marshal.load(f)
> f.close()
> return db
> # END
> else:
> return {}
> # END
> # END
>
> def write(db,name):
> f = open(name,'w')
> marshal.dump(db, f)
> f.close()
> # END
> If people want this, then pester Tim to add it to py-mode. (Tim, I
> assume you still have the diff I posted. I havent mangled the new
> py-mode yet.)
Yup, I still have the mod. It requires more work to fit in smoothly with
_all_ of pymode's features, though, and since I personally (a) have no
problem with Python today, and (b) dislike the looks of this, wouldn't
put it in unconditionally in any case.
If people who want block-closers can agree on a specific scheme, I'll
volunteer the time to fiddle pymode accordingly afterward. But since I'm
not interested in it myself, I'm not volunteering time to debate the
merits of competing schemes. Well, one point: a scheme that can't deal
with a Python program presented as a single long newline-free string
doesn't achieve all the things block-closers _should_ achieve.
talk-about-quick-'n-dirty-hacks<wink>-ly y'rs - tim
George Reynolds
Thanks for the tips on Python-mode. I just wanted to add that
that a very important part of my proposal is that its
optional. I dont want to make people use the end construct
if they dont want to.
Your comments assume however that a human is writing the code.
We are doing alot with code generation here and looking in
particular at automated
code generation for testing. It makes the code generator alot
easier to write if it does not need to worry about indentation. If the
indentation can be automated then the indent program can
simply be inserted in the Makefile.
George
Ps. Don tells me he's willing to make to make the change, and will
make a proposal to do in the near future.
Chris Hoffmann
Another point. This also assumes that Python programmers have
python-mode.el available. Not everyone has emacs. Believe it or not,
other people actually refuse to use emacs even when it is available
(poor misguided souls...).
What I'm most concerned about at the moment are applications where
people type fragments of Python code into dialogs that are implemented
with stupid text-entry "widgets". With the optional "end" delimiters
the user can be somewhat sloppy about indentation. Without it, he or
she is forced to do a lot of reindenting, possibly without even the
minimal sort of reformatting support that "vi" provides. I don't think
that will be very popular.
I'm not just making this example up to be perverse. I really do have
some tools I'd like to create where I want the user to enter Python
bits into a Motif widget.
Chris
-----------------------------------------------------------------------------
Chris Hoffmann VI Corporation
chof...@vicorp.com 47 Pleasant St. Northampton MA 01060
Guido.va...@cwi.nl
> python-mode.el available. Not everyone has emacs. Believe it or not,
> other people actually refuse to use emacs even when it is available
> (poor misguided souls...).
>
> What I'm most concerned about at the moment are applications where
> people type fragments of Python code into dialogs that are implemented
> with stupid text-entry "widgets". With the optional "end" delimiters
> the user can be somewhat sloppy about indentation. Without it, he or
> she is forced to do a lot of reindenting, possibly without even the
> minimal sort of reformatting support that "vi" provides. I don't think
> that will be very popular.
>
> I'm not just making this example up to be perverse. I really do have
> some tools I'd like to create where I want the user to enter Python
> bits into a Motif widget.
Now seriously, don't you think that people will start complaining
about such primitive text entry tools when they need to enter indented
text? Entering C in a Motif widget isn't any more fun than entering
Python -- imagine what it would look like if a user did not indent
lines at all, relying totally on braces. Moreover, in that case,
selecting a block to move around would be a nightmarge without a
function to find matching parentheses...
The solution is to design a tool to match the task, not to change the
task to match the tools you happen to have lying around!
If you are at all serious about this, you'll have to give your tool at
least the following features: auto-indent (i.e. typing RETURN or
LINEFEED will insert whitespace at then beginning of the next line to
match the previous line), a simple way to change the indentation of
the current line, and a way to change to indentation of a group of
lines (the region selected with the mouse). Almost all the other
stuff that Emacs' Python mode does is mostly for power users, even the
automatic indent after a line ending in a colon...
Thomas Kofler
in python is a topic of general interest. The following tries
to summarize the most interesting statements (IMHO).
----------------------------------------------------------
Thomas Kofler |Email: kof...@ubilab.ubs.ch
Union Bank of Switzerland |Tel: +41-1-236 4567
Bahnhofstr. 45 |Fax: +41-1-236 4671
CH-8021 Zurich, Switzerland |
----------------------------------------------------------
[ Thomas...@ubilab.ubs.ch wrote: ]
> But: I dislike the fact that blocks of statements are not enclosed by
> balanced parentheses (or something like that)
[ Guido.va...@cwi.nl wrote: ]
> - Since there are no begin/end brackets there cannot be a disagreement
> between grouping perceived by the parser and the human reader. I
> remember long ago seeing a C fragment like this:
> if (x <= y)
> x++;
> y--;
> z++;
As much as one can forget to group statements correctly by
block begin/block end, one can indent code wrong.
> - Since there are no begin/end brackets there can be no conflicting
> coding styles.
If the syntax of a language allows automatic reformating no matter
how weird the code looks, a user can reformat the program according
to her taste (or to that of her manager, etc.)
> - Many coding styles place begin/end brackets on a line by themself.
> This makes programs considerably longer and wastes valuable screen
> space, making it harder to get a good overview over a program.
Many coding styles possible in C/C++ are quite compact, eg:
if ( bla1 ) { Error(cBla1); return -1; }
if ( bla2 ) {
Error(cBla2); return -1;
}
My experience shows that people do not always format code with one
one-size-fits-all rule.
[ George Reynolds <george.vicorp.com> wrote: ]
> As a program is evolving (as opposed to simply reading the code) one
> is often cutting, pasting and otherwise modifying code quite
> frequently.
This is perfectly true. For instance, selecting in a terminal emulator
(like xterm) some piece of code (no tabs, only space in the buffer
to paste from), and then pasting into a file loaded in vi...
> Also, mistakes do happen. For example when using python-mode in emacs,
> I hit tab on a line by mistake and that line gets indented 5 levels.
> Where was it originally? Impossible to know unless I stop and grok the
> meaining of the function... again.
Strong argument. Consider inadvertently removing
one tab (the time invested in finding the "bug" could be spent
on more interesting things...).
[ m...@ipx2.rz.uni-mannheim.de (Marc Wachowitz) wrote: ]
> Certainly - even if one had to reindent some ill-formatted code, it
> would then at least be possible to do, without having to understand
> it in detail.
The same strong argument in a slightly different context.
[ Guido.va...@cwi.nl wrote: ]
> I still don't like it, but I suppose for the benefit of people who
> simply can't live with indentation, maybe we can invent an optional
> keyword to be introduced at the end of an indented block, like
>
> if foo and bar:
> important_stuff()
> more_important_stuff()
> else:
> less_important_stuff()
> end if
>
> where the 'end if' line would be optional and would have to be
> indented properly and could be used by a re-indent routine.
This would be much better than the current state.
[ Tim Peters t...@ksr.com wrote: ]
[ ... ]
> a scheme that can't deal
> with a Python program presented as a single long newline-free string
> doesn't achieve all the things block-closers _should_ achieve.
I think that this is *the* criterion.
Chris Hoffmann
Except that with C you don't have to indent. You could enter:
if (x)
{
printf("a");
x = 2;
}
else
{
printf("b");
x = 3;
}
Sure is ugly, but if you're doing quick and dirty prototyping/querying
and you don't have a tool that has any auto-indent, it gets the job
done.
Believe it or not, actually I'm the only one I know of at my company
that actually liked using indentation for syntax when first shown
Python. And I still like it, especially when reading programs (as long
as they don't decrease nesting by more than one indentation level at a
time!). I certainly don't want to get rid of this feature, even if
backward compatability weren't an issue.
But I do have several concerns with not having the option to use
delimiters and not require indentation to be meaningful. This text
entry problem is just one of them.
Most importantly, as I've said before, this indentation feature was
literally the first complaint about the language from everyone else
here. [Lest I sound too negative I'll mention that it was sometimes
the only complaint amidst the praises. Personally, I now bow down to
the prophet Guido at least once a week (is that often enough?)]
Maybe our site is totally out-of-whack with the rest of the universe,
but the typical reaction here makes me concerned about how this
feature may affect the spread of Python. People seem to like having
delimiters and don't like having required indentation.
>> The solution is to design a tool to match the task, not to change the
>> task to match the tools you happen to have lying around!
I guess I don't like the task requiring me to design new tools when it
doesn't really have to, and there seem to be (to me at least) other
reasons for making the change as well.
Tim Peters
> [talk about python generated by other programs]
> ...
> If the indentation can be automated then the indent program can simply
> be inserted in the Makefile.
But then the "indent program" could easily remove the "end" brackets too!
I.e., if _that's_ the problem, you don't need Python's help to solve it.
For those talking about how great it will be if a mistyped tab no longer
ruins the program, the last proposal I saw still required correct
indentation on input. Ditto for those talking about entering unindented
Python in text widgets. If _those_ are the problems you're trying to
solve, the current proposals are inadequate.
Those who want this stuff need to identify the problems they're trying to
solve and propose something that actually addresses them <wink>. You
also need to decide what this means under your proposal:
if a == 1:
if b == 2:
print 'x'
endif
print 5
If you're not going to claim it's an error, then you might explain why
you're making "misplaced tab" and "don't need to manually indent in text
widgets" arguments you don't actually believe <frown>. If you do claim
it's an error, precisely what are the rules you're proposing?
suggesting-that-solving-it-wrong-is-worse-than-leaving-it-alone-ly y'rs
Marc Wachowitz
> Those who want this stuff need to identify the problems they're trying to
> solve and propose something that actually addresses them <wink>.
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. 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!).
Note I'm not at all suggesting to remove the mandatory indentation, 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,
without imposing any burden upon those programmers who don't want/need it.
George Reynolds
>> Various people write at cross-purposes:
>>
>> > [talk about python generated by other programs]
>> > ...
>> > If the indentation can be automated then the indent program can simply
>> > be inserted in the Makefile.
>>
>> But then the "indent program" could easily remove the "end" brackets too!
>> I.e., if _that's_ the problem, you don't need Python's help to solve it.
Absolutly correct! But the program could put them in too. Around here
we say: 'to Guido' and 'to de-Guido' ;)
>> Those who want this stuff need to identify the problems they're trying to
>> solve and propose something that actually addresses them <wink>.
Ok....Truce! We are talking at cross purposes here and we are on the
border between real language issues and esthetics. The reality is that
I am not trying to solve a problem with python, I'm trying to solve a
problem with writing python. Tim: the message you sent to me describing
the emacs bindings for python-mode, to me, just confirmed my thinking.
I.e...why should I have to learn all this? This is not intended as a
flippant comment. There is simply high cognitive load associated with
with getting something right that I think should be automated. At the
same time I can see that other people might think otherwise. Thats
why I want the change to be optional.
I suggest that we look at the proposal in a few days and see what it
looks like. If it turns out to be ugly lets reject it.
George
Chris Hoffmann
>> (Tim Peters)
>> You
>> also need to decide what this means under your proposal:
if a == 1:
if b == 2:
print 'x'
endif
print 5
The way I understood the original suggestion (which may not be exactly
what George Reynolds proposed) is that this is illegal, as the (bare)
":" states you're going to use indentation. If you don't want to use
indentation you would have to say:
if a == 1 do
if b == 2 do
print 'x'
endif
endif
print 5
Or, using the grammar modification Don Beaudry implemented, you could
write this:
if a == 1: :(
if b == 2: :(
print 'x'
:)
:)
print 5
Note that I'm pretty sure that Don's change even made sense out of
mixed-model code such as:
if a == 1: :(
if b == 2:
print 'x'
print 'y'
:)
print 5
Not that I recommend this as a style (although it would be a great
help for the obfuscated Python competition), just pointing out it
doesn't appear to be that hard to add optional delimiters that have
reasonable semantics.
Tim Peters
> > 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
instantly.
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
Marc Wachowitz
[...]
> 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?
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).
Guido.va...@cwi.nl
> looks like. If it turns out to be ugly lets reject it.
What proposal? Who's going to write it? Did I miss something?
I, for one, would love to see a concrete proposal, spelled out in
enough detail so that someone could implement it (even if it would
require massive changes to Python), and with ample justification (i.e.
explain every feature).
THEN we can talk.
Tim Peters
mind by working backward from the claimed benefits is too hard to sort
out -- and repeated questioning has shown that most of the proponents
really do have different things in mind. Agreed with Guido that a
specific handwaving-free proposal is surely in order.
What I _mostly_ hope is that, if new gimmicks are adopted, they're enough
so that we never have to read a message about indentation again <0.3
grin>. This implies that anything too weak to permit using m4 in a
straightforward way to write Python macros will keep the issue on the
eternal-recurrence list. If it's going to be an eternally-recurring item
anyway, I'd just as soon leave it where it is so we can enjoy the
efficiency of reposting the same arguments via scripts <wink>.
> [marc]
> ... we should really have line numbers to find unintended line
> deletions.
Don't forget unintended insertions! But then there are intended
insertions, too, so the line numbers had better be floating-point. No,
that's no good, they need to be genuine reals, else we can't always find
a unique new line number between adjacent line numbers. I really want to
keep the line numbers monotonically increasing, else pymode will run like
a pig.
> Hmm, we could also require each line to be duplicated, thus finding yet
> more unwanted modifications.
A subtle advantage of my scheme is that the text of each line can be
encoded in its line number. Then we can do away with the text entirely.
_That_ should stop complaints about indentation! I propose instead that
a line number be indented a number of column spaces equal to the floor of
its natural logarithm. This way indentation will never decrease as you
go down the file, so a simple tool can detect many kinds of corruption,
and Guido can throw out all that messy DEDENT logic. It also has the
pleasant property that the indentation of no Python program can be made
to resemble a fractal, thus keeping undesirable elements out of this
group.
> Maybe add a MD5 signature for each source file, to detect bad data in
> the file system? <grin>
"Grin"? I never know when you folks are joking!
sounded-like-a-good-start-to-me-ly y'rs - tim
Marc Wachowitz
1. Existing code should continue to work without modification. Runtime flags
deciding between two separate coding styles aren't very appealing, though
optionally increased checking wouldn't harm anyone if it's only depending
on a local context - at most a file at a time, but a per-code-block style
would be preferrable, allowing cut-and-paste between different files on a
per-block basis.
2. Indentation should not fool the human reader about limits of code blocks.
However, if the programmer wants improved safety, the reinterpretation of
editing mistakes resulting in wrongly indented code should be unlikely. A
pretty-printer alone wouldn't be sufficient, since it would force this on
everyone (and old code), which appears unlikely to find consensus.
3. For automatically generated code, including usage of a preprocessor which
doesn't respect indentation rules, it should be possible to reindent such
generated code automatically. In that case, the application of some other
tool than the Python parser would be acceptable.
4. For the benefit of poor editors as part of a Python application, the tool
mentioned above should be available as a Python function mapping a string
of arbitrarily indented code to something acceptable by the parser. Since
this kind of editing seems unlikely to be used for the development of big
programs, the restriction to a safer coding style - checked by the tool -
should be acceptable. (In the case of an integrated development system, a
more sophisticated editor would be a reasonable requirement.)
Language modification:
Where the language now accepts a colon and an indented code block, the colon
may be replaced by the keyword "do" and the block be closed with "end" "???"
on the level of the block statement (i.e. not the indented code) where "???"
is the keyword of the block statement ("if", "while", "try" etc.). Using the
keyword "do" also requires the closing statement, whereas using a colon does
not allow the end bracket. Different statements need not use the same style.
Incompatibility:
The addition of the new keywords "do" and "end" may invalidate some old code
using them as normal identifiers. If the discussion reveals the existence of
large amounts of such code, and the change of those identifiers would appear
too problematic (even when supported by some tool), it should be possible to
find another syntax. Otherwise, I'd prefer using keywords over using special
characters.
Tools:
The exact nature of support tools may better be deferred, until the language
modification is agreed upon. Anything from a simple string transformer up to
a standardized parsing module with a clearly defined interface to the syntax
tree might come out - depending on the effort of the tool builders.
Donald Beaudry
There at least seems to be agreement on why the current indentation
scheme is both good and bad. And since nearly everyone else has
summerized, I thought I would do the same.
The current scheme is good because of the following features:
1) You cannot be fooled incorrect indentation.
2) It is very clean and easy to read.
But it has some problems.
1) It makes editing difficult (or at least requires a
different mind set from that required by other languages)
2) It makes it difficult or impossible to manipulate Python
code with tools, such as m4, that don't respect indentation.
3) It makes it impossible to write complete statments in a
single line. (remember that multi-line lambda thread...)
Unfortunately, any solution to problems 2 and 3 would negate feature
1, so some sort of compromise is in order. I have already posted not
only a proposal, but also an implementation (ok, ok, a hack) that
addresses problems 2 and 3 but at the expense of both features 1 and 2.
Marc Wachowitz has made a proposal which addresses problem 1, but not without
problems of its own.
m> [m...@ipx2.rz.uni-mannheim.de (Marc Wachowitz)]
m> Where the language now accepts a colon and an indented code block,
m> the colon may be replaced by the keyword "do" and the block be
m> closed with "end" "???" on the level of the block statement
m> (i.e. not the indented code) where "???" is the keyword of the
m> block statement ("if", "while", "try" etc.). Using the keyword "do"
m> also requires the closing statement, whereas using a colon does not
m> allow the end bracket. Different statements need not use the same
m> style.
This proposal comes real close to what I have been thinking about, but
fails to capture some important details. For instance, what happens
with else and elif statements?
if a > b do
print a
end if
is fine, but is this?
if a > b do
print a
else:
print b
or do you need to say,
if a > b do
print a
else do
print b
end if
or is it,
if a > b do
print a
else do
print b
end else
I have been hacking at the grammar again and with luck I should have
an implementation "real soon now". Here is what I have been trying to
achieve:
Any colon that open a block following a compound statement, (if,
while, for, try, def, class) can be omitted. If the colon is omitted,
the block must be closed by either an 'else', 'elif', 'except',
'finally', or 'end' followed by either 'while', 'for', 'try', 'def',
or 'class' depending on what statement opened the block.
So the example given above would be written as:
if a > b
print a
else
print b
end if
And since this colon is optional, it could be written a few other ways
as well. Such as,
if a > b
print a
else:
print b
or,
if a > b
print a
else:
print b
end if
(note that in this case, the 'end if' is purly optional because the
else is followed by a colon)
or even,
if a > b:
print a
else:
print b
But, if the colon is omitted, it would be a syntax error if the code
was not indented properly.
Admittedly, there are some problems here (at least I expect some,
since I haven't thought it all though yet). An automated formater
would have to be pretty smart about dealing with the cases where the
old style is mixed with the new.
I am not claiming that it is even possible to restructure the grammar
so as to allow this style of coding (I havn't done it yet), but this
should at least give you some idea about where I would like to see
things go.
--Don
______ ______
\_\_\_\ /#/#/#/
\_\_\_\ ______
\_\_\_V#/#/#/ Donald Beaudry d...@vicorp.com
\_\_/#/#/#/ V. I. Corporation uunet!vicorp!don
\_/#/#/#/ 47 Pleasant Street PHONE: (413) 586-4144
V#/#/#/ Northampton, MA 01060 FAX: (413) 586-3805
Marc Wachowitz
> This proposal comes real close to what I have been thinking about, but
> fails to capture some important details. For instance, what happens
> with else and elif statements?
Oops, I completely overlooked compound statements with multiple parts.
> Any colon that open a block following a compound statement, (if,
> while, for, try, def, class) can be omitted. If the colon is omitted,
> the block must be closed by either an 'else', 'elif', 'except',
> 'finally', or 'end' followed by either 'while', 'for', 'try', 'def',
> or 'class' depending on what statement opened the block.
Hmm, I don't think I'm going to like such a little thing as a colon to
decide about such a big matter.
As I think about it I'm even tempted to propose something very simple:
A code block may begin with the word "begin" and end with "end", which
both must be indented on the same level as the block. The two keywords
may only appear together or both be omitted.
E.g. def compare(a,b):
begin
if debug_flag: print "entering 'compare'" # no block
if a < b:
begin
if debug_flag: print "compare:", a, "is smaller"
return -1
end
elsif a > b:
begin
if debug_flag: print "compare:", b, "is greater"
return 1
end
else:
# no "begin...end" here, trust indentation
if debug_flag: print "compare:", a, "equals", b
return 0
end
Yes, it's a bit wordy, but then it's safe and simple, isn't it? ;-)
Marc Wachowitz
> elsif a > b:
> begin
> if debug_flag: print "compare:", b, "is greater"
... which is of course nonsense ;-)
Wondering whether too much worry about syntax is dangerous for semantics ...
Donald Beaudry
m> [m...@ipx2.rz.uni-mannheim.de (Marc Wachowitz)]
m> Hmm, I don't think I'm going to like such a little thing as a colon to
m> decide about such a big matter.
It is only a big matter from the perspecive of someone who has been
using the current Python syntax. From the point of view of a beginner
a colon simply means that a block terminator won't be used to
terminate the block.
m> As I think about it I'm even tempted to propose something very simple:
m> A code block may begin with the word "begin" and end with "end", which
m> both must be indented on the same level as the block. The two keywords
m> may only appear together or both be omitted.
Aside from the tokens used, this is pretty close to what is
implemented by the hack I posted a while back. The major difference
is that with my hack the indentation is not required.
m> Yes, it's a bit wordy, but then it's safe and simple, isn't it? ;-)
Well, yes, but... the wordy part bothers me quite a bit. The current
python syntax already provides enough information to delimit blocks in
most cases and is also quite terse (just a tiny bit too terse, IMHO).
We only need to cap off the remaining cases with an end statement.
So now I have to ask just how important is required indentation when
compared to being able to use m4 or write multi-line lambda
expression? Personally, I like the idea of required indentation and
formatting for many of the reasons that Guido has mentioned but the
current implementation makes me pay too high of a price for it. But,
like Tim, I am also interested in removing the restriction for certain
applications. Do we need two different mechanisms inorder to make
everyone happy? (everyone but Guido that is, I think the only way to
keep him happy would be to drop the thread and never bring it up
again:)
Donald Beaudry
m> [m...@ipx2.rz.uni-mannheim.de (Marc Wachowitz)]
m> Wondering whether too much worry about syntax is dangerous for semantics ...
Not worrying enough certaintly is...
--Don
Marc Wachowitz
> So now I have to ask just how important is required indentation when
> compared to being able to use m4 or write multi-line lambda
> expression?
>
I'm smelling some Lisp around; it gives you multi-line anything, great
lambdas, reader macros, syntax macros and pretty-printers ;-)
Wondering whether "improvements" will leave anything untouched ...
Ray Johnson
>> What I'm most concerned about at the moment are applications where
>> people type fragments of Python code into dialogs that are implemented
>> with stupid text-entry "widgets". With the optional "end" delimiters
>> the user can be somewhat sloppy about indentation. Without it, he or
>> she is forced to do a lot of reindenting, possibly without even the
>> minimal sort of reformatting support that "vi" provides. I don't think
>> that will be very popular.
>>
>> I'm not just making this example up to be perverse. I really do have
>> some tools I'd like to create where I want the user to enter Python
>> bits into a Motif widget.
>
>Now seriously, don't you think that people will start complaining
>about such primitive text entry tools when they need to enter indented
>text? Entering C in a Motif widget isn't any more fun than entering
>Python -- imagine what it would look like if a user did not indent
>lines at all, relying totally on braces. Moreover, in that case,
>selecting a block to move around would be a nightmarge without a
>function to find matching parentheses...
>If you are at all serious about this, you'll have to give your tool at
>least the following features: auto-indent (i.e. typing RETURN or
>LINEFEED will insert whitespace at then beginning of the next line to
>match the previous line), a simple way to change the indentation of
>the current line, and a way to change to indentation of a group of
>lines (the region selected with the mouse). Almost all the other
>stuff that Emacs' Python mode does is mostly for power users, even the
>automatic indent after a line ending in a colon...
If I may jump in... At Lockheed's AI center we do alot of high level
prototyping. We usually use TCL for power end users to customize and
extend a given tool. In almost all cases it is sufficient to use a
standard text entry widget for this purpose.
If we used python instead (because it's a better language) we would have
to develop a variety of features to handle python's tab structure. Futher
more, those features would have to be added to each and every prototype
that we develop (extra overhead). Futhermore, the editing features of
a standard text widget are more of less universal and well understood.
(delete, return, tab, space, up, down, etc.) However, the additional
editing features required by python (mainly block indent/unindent)
are not universial. (Was that Meta-x block-indent or command I or what).
This, unfortunatly, means that adding end user code is not as intuitive
or requires extra work by us to handle pythons unique differences (like
a graphical menu etc.)
There are other reasons why we still have yet to shift to python. However,
the largest reason we still use Tcl over python is python's tab block
structure.
Ray
--
_____________________________________
Ray Johnson
Lockheed Artifical Intelligence Center
Thomas Kofler
: In article <9405111940.AA19857=gu...@voorn.cwi.nl> Guido.va...@cwi.nl writes:
: >> What I'm most concerned about at the moment are applications where
: >> people type fragments of Python code into dialogs that are implemented
: >> with stupid text-entry "widgets". With the optional "end" delimiters
: >> she is forced to do a lot of reindenting, possibly without even the
: >> minimal sort of reformatting support that "vi" provides. I don't think
: >> that will be very popular.
: >>
: >> I'm not just making this example up to be perverse. I really do have
: >> some tools I'd like to create where I want the user to enter Python
: >> bits into a Motif widget.
[elided]
: >If you are at all serious about this, you'll have to give your tool at
: >least the following features: auto-indent (i.e. typing RETURN or
: >LINEFEED will insert whitespace at then beginning of the next line to
: >match the previous line), a simple way to change the indentation of
: >the current line, and a way to change to indentation of a group of
: >lines (the region selected with the mouse). Almost all the other
: >stuff that Emacs' Python mode does is mostly for power users, even the
: >automatic indent after a line ending in a colon...
:
: If I may jump in... At Lockheed's AI center we do alot of high level
: prototyping. We usually use TCL for power end users to customize and
: extend a given tool. In almost all cases it is sufficient to use a
: standard text entry widget for this purpose.
:
: If we used python instead (because it's a better language) we would have
: to develop a variety of features to handle python's tab structure. Futher
: more, those features would have to be added to each and every prototype
: that we develop (extra overhead). Futhermore, the editing features of
: a standard text widget are more of less universal and well understood.
This is perfectly true. I am making a similar argument in a draft
proposal (not yet finished) justifying a syntax change. I am considering
a spreadsheet where you can enter Python code into the cells. A simple
if-else-statement already poses problems: It needs two lines. Second:
How to enter tabs? Maybe, the tab is used to hop from cell to cell.
Etc, etc.
: (delete, return, tab, space, up, down, etc.) However, the additional
: editing features required by python (mainly block indent/unindent)
: are not universial. (Was that Meta-x block-indent or command I or what).
: This, unfortunatly, means that adding end user code is not as intuitive
: or requires extra work by us to handle pythons unique differences (like
: a graphical menu etc.)
:
: There are other reasons why we still have yet to shift to python. However,
: the largest reason we still use Tcl over python is python's tab block
: structure.
:
: Ray
:
: --
: _____________________________________
: Ray Johnson
: Lockheed Artifical Intelligence Center