Indent testers needed (Prothon)

[Michael Geary]

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

Oh man, you caught me there: I used a strawman to argue against your
strawman! :-0

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

I don't see how automatic continuation violates "flat is better than
nested". When I use \ continuation in Python, I indent the continuation
lines anyway--I don't usually put them at the same level as the first line.

    foo = \
        bar()

not

    foo = \
    bar()

(Obviously, I wouldn't use line continuation at all in that specific
code--it's just an illustration.)

Python has already broken the "one way to do it" and "explicit is better
than implicit" zens on this anyway, by allowing both explicit (\) and
implicit (parens, brackets, braces) continuation.

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

Mark has talked about dropping \ continuation from Prothon, but your point
about converting Python libraries may convince him not to--or to make sure
that any automatic translator handles this conversion.

Anyway, I rather like the automatic line continuation. It doesn't seem to me
that it would encourage people to write unreadable code when they would
otherwise write readable code, and it seems cleaner than \ continuation. But
I'd be happy enough with either, especially considering that I don't
continue lines that often anyway--I'm more inclined to split up a long
statement when I can.

Thank goodness Python doesn't use curly braces like C and C++. That way we
can argue about spaces and tabs and line continuation instead! ;-)

-Mike