Indentation/whitespace

[Guest]

I consider myself a fairly experienced Python coder and although I am
not "uncomfortable" with significant whitespace there are a few places
where I do find it annoying and I wouldnt mind an alternate block
delimitation syntax.

The problem with that is that a few people would prefer to use this all
the time, damaging the (almost) uniform indentation among Python
programs.

 

[Steven D'Aprano]

I consider myself a fairly experienced Python coder and although I am
not "uncomfortable" with significant whitespace there are a few places
where I do find it annoying and I wouldnt mind an alternate block
delimitation syntax. I would prefer something like the ruby "end"
though rather than '{' and '}'.

Python already has support for begin/end if you want it. It is spelt
"# BEGIN" and "# END" (or "#END IF", etc.), and is case-insensitive.

In most programming languages, begin/end markers are syntactically
significant while indentation is recommended but not enforced by the
compiler. In Python, it is the other way around.

The place I find it annoying is in
pasting snippets of code from say web pages. I very often google for a
piece of code and then paste it into my editor and almost always the
pasted piece of code has different indentation and causes a compiler
error.

That's hardly Python's fault. That's a problem with lousy browsers,
editors etc. which add word-wrapping or remove whitespace. Complain to the
browser developers.

 

[thakadu]

That's hardly Python's fault. That's a problem with lousy browsers,

editors etc. which add word-wrapping or remove whitespace. >Complain to the
browser developers.

While I have no doubt that there are lousy browsers out there, the
problem is not only with browsers, but also I agree with you its not
Python's fault. The issue is that the code I am pasting may have used a
DIFFERENT indentation scheme, so lets say I used four spaces and the
code I am pasting used two spaces, or worse yet, a tab, that is where
the problem arises. Now assuming that the browser and the copy and
paste buffers dont screw up the indentation, when I paste that code
into my editor that is where the problem arises. Sure if everyone stuck
to the recommended 4 spaces in the style guide it would help. But even
then in the context of your program you may be a further level of
indentation.
I dont know if trying to make the editor any cleverer would help
either. You could get it to simply replace the indentation in the newly
pasted code to the same as the surrounding code, (and there may even be
some Python modes that do that already) but that may not always be what
you wanted!

 

[Alex Martelli]

syntax. Honestly I wonder how so many coders actually came to be
interested in the field -- one that pretty much thrives in part on its
neverending ability to vary, grow, and change -- if something so small
can warrant so much attention.

An obsession with details can be a good thing in, as you put it, "a
coder" -- the grand vision may matter, but the details always do (if you
don't get every detail right, the program won't run correctly). So, I
am not surprised if many people predisposed to devoting lot of attention
to small details get attracted to programming (and, more generally,
engineering and even science), in preference to other careers...


Alex

 

[Lee Harr]

You've got the visible/invisible aspect of things
*exactly* backwards.
The point on a line of text where things change
from white space to
non-white space is *highly* visible. The several
pixels that represent a
{ or } are nearly invisible within a line of text.
(So one usually
compensates by putting them alone on a line,
making them somewhat more
visible.)

Along these lines, I was wondering recently if it would be
nice to have the editor put in some subtle gradation in the
background color or maybe some faint gridlines at each
indentation stop.

Has anyone ever experimented with that?

 

[=?iso-8859-1?B?QW5kcuk=?=]

Along these lines, I was wondering recently if it would be
nice to have the editor put in some subtle gradation in the
background color or maybe some faint gridlines at each
indentation stop.

Has anyone ever experimented with that?

Check spe (Stani's Python Editor). It does allow one to put
gridlines.

André

 

[gene tani]

Along these lines, I was wondering recently if it would be
nice to have the editor put in some subtle gradation in the
background color or maybe some faint gridlines at each
indentation stop.

Has anyone ever experimented with that?

i think you can't call an editor python capable unless it shows you
clearly hard (yuck)or soft tabs like View / Show Invisibles in
textmate, View / view whitespace in komodo.

 

[Joe]

My original post was based on reading on Pythons developer list that it
was seriously considering some alternate grouping scheme, just because
"so many people keep asking". But, it seems that never happened.

As for me, I'm not suggesting that braces are better than indentation.
In fact, requiring indentation is a good idea, and I agree that braces
can be quite ugly. It is the lack of visible block closing when there's
more than one level that I dislike.

That would probably not be so bad if, like the recent post, you used an
editor that showed faint vertical lines. In fact, that's a very good
idea, since you really need a Python-aware editor anyhow.

 

[James Tanis]

My original post was based on reading on Pythons developer list that it
was seriously considering some alternate grouping scheme, just because
"so many people keep asking". But, it seems that never happened.

As for me, I'm not suggesting that braces are better than indentation.
In fact, requiring indentation is a good idea, and I agree that braces
can be quite ugly. It is the lack of visible block closing when there's
more than one level that I dislike.

That would probably not be so bad if, like the recent post, you used an
editor that showed faint vertical lines. In fact, that's a very good
idea, since you really need a Python-aware editor anyhow.

You can always just document the end of the block with a comment, such as
# end: if usr.password == password
or something less elaborate .

 

[Paul McGuire]

Along these lines, I was wondering recently if it would be
nice to have the editor put in some subtle gradation in the
background color or maybe some faint gridlines at each
indentation stop.

Has anyone ever experimented with that?

The Scintilla Text Editor (simple, lightweight, open source, free -
http://www.scintilla.org/SciTE.html) has this feature by default.

-- Paul

 

[Ilias Lazaridis]

Of course.

I estimate it will take around 1 to 2 years from now, until this
whitespace-concept will become optionally.

Backwards-compatibility will be kept, thus those who love this feature
will remain happy python users.

Python accepts the diversity of its userbase - at least where
technically possible.

And in this case it is.

Characterizing indentation as "invisible" isn't really fair.

[...]

This has nothing to do with fairness.

..

 

[Robert Hicks]

I disagree...I don't think the whitespace rule will ever be "optional".
Why would it be so? If someone doesn't like it...choose another
language. It is that simple really.

Robert

 

[Ilias Lazaridis]

I disagree...I don't think the whitespace rule will ever be
"optional". Why would it be so? If someone doesn't like it...choose
another language. It is that simple really.
> Robert

It's not that simple.

But let's simply await.

We will know in 2 years.

-

TAG.python.evolution.whitespace

..

 

[jussij]

i think you can't call an editor python capable unless it

shows you clearly hard (yuck)or soft tabs like View /
Show Invisibles in textmate, View / view whitespace in
komodo.

Zeus for Windows has this View / View whitespace feature:

http://www.zeusedit.com
Note: Zeus is shareware (45 day trial)

Jussi Jumppanen
Author: Zeus for Windows

 

[Robert Hicks]

No, it is that simple. You don't want it to be is all.

Robert

 

[James Tanis]

Zeus for Windows has this View / View whitespace feature:

I personally don't care to see it, I'd rather it just did the soft ->
hard conversion for me so I don't have to worry about it. Thats
assuming hard tabs is defined as actual spaces rather then a tab
character. If I'm getting those mixed up, switch 'em around or
whatever. I find true tabs to be very annoying since different
editors/programs seem to translate them differently, just give me
spaces . Their are plenty of freeware and proprietary programs that
do both and everything in between, don't feel like you have to be
pushed into buying something.

 

[Jon Perez]

Is Python going to support s syntax the does not use it's infamous
whitespace rules? I recall reading that Python might include such a
feature. Or, maybe just a brace-to-indentation preprocessor would be
sufficient.

Nope never.

Because that would destroy one of the most important things
about Python. *Enforced* indentation is one of the reasons why
we love Python.

 

[Jon Perez]

Of course.

I estimate it will take around 1 to 2 years from now, until this
whitespace-concept will become optionally.

Backwards-compatibility will be kept, thus those who love this feature
will remain happy python users.

If enforced indentation ever became optional, it would
completely defeat its purpose, because it would then
make 'creatively' indented python code possible which
would be an absolute nightmare to maintain.

Python accepts the diversity of its userbase - at least where
technically possible.

And in this case it is.

Don't forget Python is also very much about language feature
aesthetics, and non-enforced indentation violates Python's
creator's design sensibilities completely.

 

[Jon Perez]

While I have no doubt that there are lousy browsers out there, the
problem is not only with browsers, but also I agree with you its not
Python's fault. The issue is that the code I am pasting may have used a
DIFFERENT indentation scheme, so lets say I used four spaces and the
code I am pasting used two spaces, or worse yet, a tab, that is where
the problem arises. Now assuming that the browser and the copy and
paste buffers dont screw up the indentation, when I paste that code
into my editor that is where the problem arises. Sure if everyone stuck
to the recommended 4 spaces in the style guide it would help. But even
then in the context of your program you may be a further level of
indentation.

Although the below does work, I believe:

def fun1():
print "I use two space indentation"
while (1):
print "but"
print "four space works just as well"
print "and can coexist"


It just has to be consistent within a *single* block.

 

[Dave Hansen]

On Thu, 12 Jan 2006 11:56:05 +0800 in comp.lang.python, Jon Perez

[...]

Although the below does work, I believe:

Verified example:
if n==4:
print "You like four spaces"
elif n==3:
print "I like three"
elif n==2:
print "Others like two"
else:
print "But don't mix TABs and spaces!"

check_indent(n)


You like four spaces
I like three
Others like two
But don't mix TABs and spaces!
Regards,
-=Dave