Indent testers needed (Prothon)

Discussion in 'Python' started by Mark Hahn, Apr 3, 2004.

  1. Mark Hahn

    Mark Hahn Guest

    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.
     
    Mark Hahn, Apr 3, 2004
    #1
    1. Advertising

  2. Mark Hahn

    Peter Hansen Guest

    Mark Hahn wrote:

    > 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
     
    Peter Hansen, Apr 3, 2004
    #2
    1. Advertising

  3. Mark Hahn

    Mark Hahn Guest

    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, Apr 3, 2004
    #3
  4. Mark Hahn

    Mark Hahn Guest

    "Peter Hansen" <> wrote ...
    > 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).
     
    Mark Hahn, Apr 3, 2004
    #4
  5. Mark Hahn

    rzed Guest

    "Mark Hahn" <> wrote in
    news:b5rbc.132699$cx5.63133@fed1read04:

    > 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

    --
    rzed
     
    rzed, Apr 3, 2004
    #5
  6. Mark Hahn

    Mark Hahn Guest

    "rzed" <> wrote

    > /* 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, Apr 3, 2004
    #6
  7. Mark Hahn

    Mark Hahn Guest

    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.
     
    Mark Hahn, Apr 3, 2004
    #7
  8. >>/* 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
     
    Josiah Carlson, Apr 3, 2004
    #8
  9. Mark Hahn

    Ville Vainio Guest

    >>>>> "Peter" == Peter Hansen <> writes:

    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 http://tinyurl.com/2prnb
     
    Ville Vainio, Apr 3, 2004
    #9
  10. Mark Hahn

    Ville Vainio Guest

    >>>>> "Mark" == Mark Hahn <> writes:

    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.

    --
    Ville Vainio http://tinyurl.com/2prnb
     
    Ville Vainio, Apr 3, 2004
    #10
  11. Mark Hahn

    Mark Hahn Guest

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

    > >>/* loop 2 */
    > >>ix = 2
    > >>for \
    > >> item \
    > >> in \
    > >> blist \
    > >> :
    > >> alist[ix] = \
    > >> alist[ \
    > >> ix \
    > >> ]
     
    Mark Hahn, Apr 3, 2004
    #11
  12. Mark Hahn

    Peter Hansen Guest

    Mark Hahn wrote:

    > "Peter Hansen" <> wrote ...
    >
    >>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.


    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
     
    Peter Hansen, Apr 3, 2004
    #12
  13. Mark Hahn

    rzed Guest

    "Mark Hahn" <> wrote in
    news:2Msbc.136673$cx5.2385@fed1read04:

    > "rzed" <> wrote
    >
    >> /* 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.

    --
    rzed
     
    rzed, Apr 3, 2004
    #13
  14. Josiah Carlson wrote:
    > >>/* 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
     
    Michael Geary, Apr 3, 2004
    #14
  15. Mark Hahn

    Mark Hahn Guest

    "Ville Vainio" <> wrote

    > 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.

    "rezed" wrote ...

    > 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?
     
    Mark Hahn, Apr 3, 2004
    #15
  16. Mark Hahn

    Aahz Guest

    In article <>,
    Ville Vainio <> wrote:
    >>>>>> "Peter" == Peter Hansen <> writes:

    >
    > 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.
    --
    Aahz () <*> http://www.pythoncraft.com/

    "usenet imitates usenet" --Darkhawk
     
    Aahz, Apr 3, 2004
    #16
  17. >>>>/* 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
     
    Josiah Carlson, Apr 3, 2004
    #17
  18. Mark Hahn

    rzed Guest

    "Mark Hahn" <> wrote in
    news:KFDbc.148020$cx5.28330@fed1read04:

    >
    > "Ville Vainio" <> wrote
    >
    >> 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.
    >
    > "rezed" wrote ...
    >
    >> 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?
    >
    >
    >


    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.

    --
    rzed
     
    rzed, Apr 3, 2004
    #18
  19. >>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 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
     
    Josiah Carlson, Apr 3, 2004
    #19
  20. Mark Hahn

    Neil Hodgson Guest

    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
     
    Neil Hodgson, Apr 3, 2004
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Robert Weatherford
    Replies:
    0
    Views:
    369
    Robert Weatherford
    Apr 12, 2004
  2. Richard

    loading testers needed

    Richard, Oct 7, 2003, in forum: HTML
    Replies:
    5
    Views:
    393
    Richard
    Oct 7, 2003
  3. Mark Hahn
    Replies:
    41
    Views:
    939
    Paul Boddie
    May 27, 2004
  4. Mark Hahn
    Replies:
    20
    Views:
    623
    Mark Hahn
    Jul 13, 2004
  5. dt
    Replies:
    4
    Views:
    528
    CBFalconer
    Dec 31, 2006
Loading...

Share This Page