Indent testers needed (Prothon)

[Mark Hahn]

We're proud to say that Prothon has grown out of the indent space/tab flame
war stage and has moved on to more serious discussions.

We've decided to allow space-based indents and tab-based indents but not in
the same file. We are also adding some improvements in the area of line
continuations (see the algorithm at the end of the message).

Since there were zillions of messages here on c.l.py about spaces vs. tabs
and Guido has said he wants to remove tab support, I thought maybe some of
you might help us test our implementation of this indentation algorithm.

Can I get a few space lovers and tab lovers to download this windows
executable and tell us if this makes them happy? If you keep your Python
code simple and free of class statements, you don't have to learn Prothon to
try it. You can't use the interactive console to evaluate the algorithm,
you will need to write *.pr code files and run them. Note: This is not a
real Prothon release. It has not been through normal testing. Use it only
for indent testing.

The zip file (350K) is at:

http://prothon.org/pub/prothon/Prothon-unstable-b255-win32.zip

Unzip the file which will make a folder called win32. Drop your .pr file
into the folder. Open a dos command window. CD to the win32 folder and run
the prothon.exe file with the .pr file name:

prothon.exe code.pr

Features:

1) You must use only tabs or only spaces for indents in any one file. You
cannot mix them.

2) Each indent level can have any number of characters more than the
previous level, whether you are using tabs or spaces. If you drop back to
the left to dedent, and your column position does not match any level above,
you will get a lexer error.

3) If you increase the indentation level above the previous line by even
one space, and that previous line does not end in a colon, then the new line
will be considered a continuation of the previous line.

4) If a line contains an active (not quoted or commented) (, {, or [
without a matching end character, then the following line is always a
continuation, no matter what that following line contains.

5) There is still support for using the trailing backslash ( \ ) to indicate
that the next line is a continuation. This may be removed in the future if
everyone agrees to do so.

 

[Peter Hansen]

We're proud to say that Prothon has grown out of the indent space/tab flame
war stage and has moved on to more serious discussions.

We've decided to allow space-based indents and tab-based indents but not in
the same file.

I've (thankfully) missed all the Prothon-related wars about indentation,
clearly, but I have to ask, isn't this "solution" rather ill-conceived
still?

What about copy-and-paste from one file (which was done with spaces)
to another which is using tabs? Kind of puts a crimp in one's style
there, I would think...

Just a thought.

I heard a rumour Python is heading for "no tabs", period. Why not just
simplify everyone's life and do the same for Prothon, and leave the
whole darned issue in the past. In a year no one will be complaining
about their beloved tabs anyway...

(Oooh... won't that get another flame war started? I think I'll
skip it... I just wanted to make the first point. And should probably
have stopped there.)

-Peter

 

[Mark Hahn]

This was a bit premature. Some of our test cases give indentation errors.
I'll post another file when it is really ready for testing.

Meanwhile comments on our intended solution would be greatly appreciated.

 

[Mark Hahn]

I heard a rumour Python is heading for "no tabs", period. Why not just
simplify everyone's life and do the same for Prothon, and leave the
whole darned issue in the past.

I first said tabs-only since I'm a tabs lover and the tabs-haters came out
and crucified me. Because of that and the fact that I found out that Guido
wants to pull tabs from Python, I said we were going to spaces-only and then
the space-haters did the same. I don't think Guido has a chance in hell of
ever pulling tab support from Python.

In a year no one will be complaining
about their beloved tabs anyway...

Yeah right (giant laugh).

 

[rzed]

This was a bit premature. Some of our test cases give
indentation errors. I'll post another file when it is really
ready for testing.

Meanwhile comments on our intended solution would be greatly
appreciated.

Some odd-looking things can happen, as it stands. These two
loops parse correctly:

alist = [3,7,11]
blist = [1,2,
3]

# loop 1
ix = 2
for item in blist:
alist[ix] = alist[ix] + item
print alist[ix]
ix = ix - 1

/* loop 2 */
ix = 2
for
item
in
blist
:
alist[ix] =
alist[
ix
]
+
item
print alist[ix]
ix =
ix
-
1

 

[Mark Hahn]

/* loop 2 */
ix = 2
for
item
in
blist
:
alist[ix] =
alist[
ix
]

Do you think this is a good thing or a bad thing? You could do the same
thing or worse in C or Java.

 

[Mark Hahn]

I have a newer better-working version to download and test:

http://prothon.org/pub/prothon/prothon-unstable-b266-win32.zip

The instructions are the same except the folder name will be Prothon:

Unzip the file which will make a folder called Prothon. Drop your .pr file
into the folder. Open a dos command window. CD to the win32 folder and run
the prothon.exe file with the .pr file name:

prothon.exe code.pr

Features:

1) You must use only tabs or only spaces for indents in any one file. You
cannot mix them.

2) Each indent level can have any number of characters more than the
previous level, whether you are using tabs or spaces. If you drop back to
the left to dedent, and your column position does not match any level above,
you will get a lexer error.

3) If you increase the indentation level above the previous line by even
one space, and that previous line does not end in a colon, then the new line
will be considered a continuation of the previous line.

4) If a line contains an active (not quoted or commented) (, {, or [
without a matching end character, then the following line is always a
continuation, no matter what that following line contains.

5) There is still support for using the trailing backslash ( \ ) to indicate
that the next line is a continuation. This may be removed in the future if
everyone agrees to do so.

6) A continuation line is effectively added to the end of the previous line
so any line following a continuation line uses the last non-continuation
line for the "previous line" in all the rules above.

 

[Josiah Carlson]

/* loop 2 */

ix = 2
for
item
in
blist
:
alist[ix] =
alist[
ix
]

Do you think this is a good thing or a bad thing? You could do the same
thing or worse in C or Java.

It is a bad thing. Just because you could do worse in a language that
is indentation agnostic, doesn't mean that you shouldn't discourage (if
not disallow) such behavior in a language that is bases scope on
indentation.

The above code shows how you can make Prothon code extraordinarily ugly
by exploting the continuation rules. Certainly most people don't see
such ugly continuations in Python, but I think rule #3 is begging for
trouble.


- Josiah

 

[Ville Vainio]

Peter> I heard a rumour Python is heading for "no tabs", period.
Peter> Why not just

I find this rumor hard to believe - there would have been some more
official announcement, and the resulting code breakage would be
major. Not all legacy code can be run through reindent.py either...

I think the most sensible thing would be to give warnings on mixed
indenting by default, not by some command line switch nobody
uses. Newbies get burned by it all the time.

Alternatively, change the tab size as interpreted by Python to 321
spaces. The current assumption of 8 violates "explicit is better than
implicit".

 

[Ville Vainio]

Mark> I first said tabs-only since I'm a tabs lover and the
Mark> tabs-haters came out and crucified me. Because of that and
Mark> the fact that I found out that Guido wants to pull tabs from
Mark> Python, I said we were going to spaces-only and then the
Mark> space-haters did the same. I don't think Guido has a chance
Mark> in hell of ever pulling tab support from Python.

Just allow both spaces and tabs, but not in the same block. If someone
with a crippled editor (e.g. non-programmers which might default to
notepad, or someone not on his own computer) tries to create a new
function in a spaces-only file, he's going to be so pissed because he
has to hit spacebar 4 times instead of one tab to make the code look
the same.

 

[Mark Hahn]

But you can do this without rule 3 which is even uglier...

/* loop 2 */
ix = 2
for \
item \
in \
blist \
:
alist[ix] = \
alist[ \
ix \
]

 

[Peter Hansen]

I first said tabs-only since I'm a tabs lover and the tabs-haters came out
and crucified me. Because of that and the fact that I found out that Guido
wants to pull tabs from Python, I said we were going to spaces-only and then
the space-haters did the same. I don't think Guido has a chance in hell of
ever pulling tab support from Python.

I knew I shouldn't have gone there... it led you to ignore my real
point.

Which was don't you think that this is going to make cut-and-paste
a really significantly dangerous/difficult thing compared to even
Python's current (accept either) approach?

-Peter

 

[rzed]

/* loop 2 */
ix = 2
for
item
in
blist
:
alist[ix] =
alist[
ix
]

Do you think this is a good thing or a bad thing? You could do
the same thing or worse in C or Java.

My first reaction was negative, but in fact I don't think it makes
as much difference as it appears to. I'm not going to code like
that, and I don't know anyone who will. But the absurdist approach
to coding won't necessarily be used just because is possible. The
continuation lines in general are more convenient than Python's
stricter rule, though I liked the first version of Prothon's rule
(a double indent implies continuation) as well. The open-bracket
rule in particular seems intuitive. I think either Prothon rule is
handier than \
continuations.

But I agree with Josiah, in that cut and paste will become
problematic if the mixture is not allowed. I tried to make the
point to Michael earlier (though apparently in a muddled way). I
don't show visible tab marks in my editors, and I don't want to
have to, but if I don't, I haven't any good way to know whether a
piece of code contains tabs or spaces. Until I run it, at least.

 

[Michael Geary]

/* loop 2 */
ix = 2
for
item
in
blist
:
alist[ix] =
alist[
ix
]

...
The above code shows how you can make Prothon code
extraordinarily ugly by exploting the continuation rules.
Certainly most people don't see such ugly continuations
in Python, but I think rule #3 is begging for trouble.

That's a strawman. The fact that you *could* write strange code like that
doesn't mean that there is anything wrong with Mark's continuation rules.

I could write a long Python program that uses no functions, classes, or
anything else to break it into smaller understandable pieces. Just one big
long piece of code that is indented to twenty levels. While I'm at it, I'll
use variable names that obscure what the code does.

Does that imply that there should be a maximum length to a Python source
file, a limit on the level of indenting, and restrictions on what variable
names I can use? Of course not.

-Mike

 

[Mark Hahn]

Just allow both spaces and tabs, but not in the same block.

This is a good idea. I could reset the flag for the indent type whenever
the indentation goes to zero. I'll pitch this on the Prothon list.

...

I don't show visible tab marks in my editors, and I don't want to
have to, but if I don't, I haven't any good way to know whether a
piece of code contains tabs or spaces. Until I run it, at least.

I agree this is a problem, but the whole problem we are trying to solve,
that of mixed spaces and tabs, would cause you the same grief, or worse,
right?

 

[Aahz]

Peter> I heard a rumour Python is heading for "no tabs", period.
Peter> Why not just

I find this rumor hard to believe - there would have been some more
official announcement, and the resulting code breakage would be
major. Not all legacy code can be run through reindent.py either...

It's not precisely a rumor; Guido has stated that this is one of the
things he's thinking seriously about for Python 3.0. There will be
enough incompatibilities that this one won't add much extra strain,
given that the official rules for Python (PEP 8) have mandated only
spaces for several years.

 

[Josiah Carlson]

/* loop 2 */

ix = 2
for \
item \
in \
blist \
:
alist[ix] = \
alist[ \
ix \
]

Certainly that is uglier, but at least there are backslashes saying
"hey, something is happening here". If this were Python, it would
violate the "explicit is better than implicit" zen.

- Josiah

 

[rzed]

This is a good idea. I could reset the flag for the indent type
whenever the indentation goes to zero. I'll pitch this on the
Prothon list.

...


I agree this is a problem, but the whole problem we are trying
to solve, that of mixed spaces and tabs, would cause you the
same grief, or worse, right?

Not necessarily, at least in Python. I can paste a function in its
entirety and not need to know whether it uses tabs or spaces. In
Prothon (at the moment), a mixture would give me a parse error.

But in the more general case, yes it could cause the same grief. If
I made wholesale cut and paste changes to a file, scattering many
tab-indented statements in among my space-indented ones, it would
take at least a little while to straighten it out. In any case, it
is more an annoyance than a showstopper, I'd say. If I got into the
habit of bringing all external code into a file and saving it, my
editor would convert the tabs to my default and the code would be
usable without difficulty. I can live with that little thing.

 

[Josiah Carlson]

The above code shows how you can make Prothon code

That's a strawman. The fact that you *could* write strange code like that
doesn't mean that there is anything wrong with Mark's continuation rules.

I state almost as much, "most people don't see such ugly continuations
in Python", which expresses that we don't see that kind of ugly code in
Python. I believe that the reason for it is because most people don't
like to see such ugly code. However, as I said, I think that #3 is
begging for some schmuck to exploit it.

I could write a long Python program that uses no functions, classes, or
anything else to break it into smaller understandable pieces. Just one big
long piece of code that is indented to twenty levels. While I'm at it, I'll
use variable names that obscure what the code does.

Does that imply that there should be a maximum length to a Python source
file, a limit on the level of indenting, and restrictions on what variable
names I can use? Of course not.

You're going a few steps beyond what I was saying. I stated that it
makes sense to discourage ugly code. The code that you are describing
is functionally impossible to maintain (unless it was generated by
inlining all module-level function calls, something that you, I, or
anyone else could technically do, or even write a program to do). I
think that by people using Python (or in this case Prothon), by
definition it is implied that we should be writing maintainable code.

Personally, I don't find implicitly continued lines to be more
maintainable than explicitly continued lines, and because explicit
continuations (with '\') do the job already, if this were Python, it
would violate both the "flat is better than nested" and "there should be
one-- and preferably only one --obvious way to do it" zens.

As for whether Mark wants to follow the Zen of Python, that is up to
him. However, considering that he's using the c.l.py newsgroup to
discuss Prothon, using a very large portion of the syntax of Python, and
has talked about translating a large portion of the standard library of
Python to Prothon via some sort of automatic method, I would say that
violating the Zen is a foolish "early optimization".

- Josiah

 

[Neil Hodgson]

Aahz:

It's not precisely a rumor; Guido has stated that this is one of the
things he's thinking seriously about for Python 3.0. There will be
enough incompatibilities that this one won't add much extra strain,
given that the official rules for Python (PEP 8) have mandated only
spaces for several years.

PEP 8 is a 'style guide' which does not 'mandate' anything. It does not
deprecate tab usage, merely strongly recommends spaces-only for new
projects.

Neil