Indent testers needed (Prothon)

[Michael Geary]

I could write a long Python program that uses no functions, classes, or

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

 

[Jon Perez]

Just a question for the pro-tabs people, don't you find it
annoying to keep changing your editor's tab settings if you
need to view code for which the default tab setting does
not match yours?

Further, what is it about all spaces that bothers you?
Perhaps the pro-spaces people can explain how they deal
with it. I used to be pro-tabs but quickly realized the
evils of their usage.

 

[Jacek Generowicz]

Perhaps the pro-spaces people can explain how they deal
with it.

Emacs

 

[Jon Perez]

Emacs

Asking people to stop switch away from their favorite editors
(and to a horribly unfriendly one at that) just to fix this
one problem is not a satisfactory answer.

 

[Carl Banks]

Asking people to stop switch away from their favorite editors

He wasn't doing that, bub.

 

[Jon Perez]

He wasn't doing that, bub.

So what was he doing... bub?

 

[Jon Perez]

He wasn't doing that, bub.

My point is that it is a flippant answer that really doesn't
help. The pro-tabs people have their reasons for not liking
all spaces, and telling them that Emacs is how some of us are
able to live with all spaces achieves nothing. I'm sure there
Emacs users who still can't get used to all-spaces as well as
pro-spaces people who don't need to use Emacs to prefer them
(like me).

I am pro all spaces, and the reason I can't stand tabs is
the fact that tab width settings are not the same across
different source code and that leads to code that's doesn't
display properly with cat (if it doesn't use 8 space tabs) or
with my default editor settings (I have to keep switching as
there's no such thing as autodetect tabwidth).

If the pro-tabs people explained to me how they deal with this,
then maybe I wouldn't so anti-tabs. The converse applies to
them - I'd like to hear what it is about all spaces that's giving
them grief and maybe I can tell them how I deal with it (in a
non editor-specific way as much as possible).

It may not convince everyone on either side to switch religion,
but the hope is that it would make dealing with source code that
uses the opposite convention more palatable.