Indent testers needed (Prothon)

[Aahz]

Re: Indent testers needed (Prothon)

In article <du7wu4xlbd7.fs f@lehtori.cc.tu t.fi>,
Ville Vainio <ville@spammers .com> wrote:[color=blue][color=green][color=darkred]
>>>>>> "Peter" == Peter Hansen <peter@engcorp. com> writes:[/color][/color]
>
> 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...[/color]

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 incompatibiliti es 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 (aahz@pythoncra ft.com) <*> http://www.pythoncraft.com/

"usenet imitates usenet" --Darkhawk

[Josiah Carlson]

Re: Indent testers needed (Prothon)

>>>>/* loop 2 */[color=blue][color=green][color=darkred]
>>>>ix = 2
>>>>for \
>>>> item \
>>>> in \
>>>> blist \
>>>> :
>>>> alist[ix] = \
>>>> alist[ \
>>>> ix \
>>>> ][/color][/color][/color]

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]

Re: Indent testers needed (Prothon)

"Mark Hahn" <mark@prothon.o rg> wrote in
news:KFDbc.1480 20$cx5.28330@fe d1read04:
[color=blue]
>
> "Ville Vainio" <ville@spammers .com> wrote
>[color=green]
>> Just allow both spaces and tabs, but not in the same block.[/color]
>
> 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 ...
>[color=green]
>> 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.[/color]
>
> 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?
>
>
>[/color]

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

[Josiah Carlson]

Re: Indent testers needed (Prothon)

>>The above code shows how you can make Prothon code[color=blue][color=green]
>>extraordinari ly 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.[/color]
>
> 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.[/color]

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.

[color=blue]
> 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.[/color]

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]

Re: Indent testers needed (Prothon)

Aahz:[color=blue]
> 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 incompatibiliti es 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.[/color]

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

[Michael Geary]

Re: Indent testers needed (Prothon)

> > I could write a long Python program that uses no functions, classes, or[color=blue][color=green]
> > anything else to break it into smaller understandable pieces. Just one[/color][/color]
big[color=blue][color=green]
> > long piece of code that is indented to twenty levels. While I'm at it,[/color][/color]
I'll[color=blue][color=green]
> > 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[/color][/color]
variable[color=blue][color=green]
> > names I can use? Of course not.[/color][/color]
[color=blue]
> 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.[/color]

Oh man, you caught me there: I used a strawman to argue against your
strawman! :-0
[color=blue]
> 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.[/color]

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.
[color=blue]
> 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".[/color]

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]

Re: Indent testers needed (Prothon)

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.