Indentation/whitespace

[Joe]

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.

Many people think Python's syntax makes sense. There are strong
feelings both ways. It must depend on a person's way of thinking,
because I find it very confusing, even after using with Python for some
time, and trying to believe the advice that I would learn to like it.
The most annoying thing is that multiple dedents are very unreadable. I
still don't understand how anybody can think significant-but-invisible
dedentation is a good thing.

Note: No need to follow up with long opinions of why indentation is
good -- they have been posted hundreds of times. It just seems that
Python developers think the whitespace thing is only an issue for
newbies. I think that many experienced users don't learn to like it,
but instead just learn to live with it.

[Larry Bates]

Joe wrote:

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.

Many people think Python's syntax makes sense. There are strong
feelings both ways. It must depend on a person's way of thinking,
because I find it very confusing, even after using with Python for some
time, and trying to believe the advice that I would learn to like it.
The most annoying thing is that multiple dedents are very unreadable. I
still don't understand how anybody can think significant-but-invisible
dedentation is a good thing.

Note: No need to follow up with long opinions of why indentation is
good -- they have been posted hundreds of times. It just seems that
Python developers think the whitespace thing is only an issue for
newbies. I think that many experienced users don't learn to like it,
but instead just learn to live with it.

Characterizing indentation as "invisible" isn't really fair.
It it WAY more visible than a { character. IMHO the
indentation works very well. I've tried to wade through PHP,
JavaScript, C code that uses those <expletive deleted>
brace ({}) blocks until my head hurt, especially if they
didn't indent as well as using the braces. If they indent
so I can actually read the code, why also use braces to
clutter things up? I've solved the multiple dedent problem
by inserting a comment that shows where the indented blocks
end (sort of where the ending brace (}) would have been.
I also find that if I'm indenting more than a couple of
levels, I probably need to refactor my code into smaller
objects or rethink the process so that I process collections
of objects. I've written in many different languages over
a span of 32+ years and it seems to work for me.

-Larry

[Alex Martelli]

Joe <jk****@nc.rr.com> wrote:

Is Python going to support s syntax the does not use it's infamous
whitespace rules?
No, never (even apart from the "its" vs "it's" issue here...;-).
I recall reading that Python might include such a
feature.
And I recall reading that Elvis is still alive and was kidnapped by
aliens, but I don't necessarily believe all that I read.
Or, maybe just a brace-to-indentation preprocessor would be
sufficient.
Fine, then write one -- it's not too hard (about an average interview
question for hiring a programmer, I'd say). As for how to integrate
such a preprocessor with CPython, I would suggest you follow precedent
by allowing an arbitrary "source-code-reading hook" to be optionally
specified by setting sys.preprocessor (and/or via commandline flag,
environment variable, etc -- but, the ability to install the hook from
site-configure.py would probably be sufficient).

You could maybe get 99% of the way there by using the existing "import
hooks" mechanism (the same one that lets you import from zipfiles: it's
designed to be easily extensible), but I don't think that would help
with the "main script" (which doesn't get imported), interactive
interpreter sessions, etc; also, I'm not sure it would easily allow
seamless interoperation with other such hooks (e.g., to let you import
from zipfiles sources that need to be preprocessed).

The main reason I suggest a general-purpose mechanism for the hooking-up
of the preprocessor is that such a mechanism might stand a chance to be
accepted (via the usual PEP procedure), as long as other interesting use
cases can be found; I suspect that if the only use case was "turn braces
into indents/dedents", the PEP would stand no chance.

For example, a small but vocal minority has long campaigned for
non-ASCII characters to be allowed in identifiers; a preprocessor might
be able to do this by translating them into ASCII on the fly (though
that wouldn't necessarily work well with getattr and friends... but
then, neither do 'private' identifiers starting with two underscores;-).
still don't understand how anybody can think significant-but-invisible
dedentation is a good thing.
We're even, then, since I can't understand the reverse;-).
Note: No need to follow up with long opinions of why indentation is
good -- they have been posted hundreds of times. It just seems that

Respecting your wish, I'm not discussing the issue at all (although, by
trying to make some point AGAINST it, you really make it very hard: if
you don't want such a discussion you shouldn't start one yourself and
then try to impede your opponents from rebutting your points, that is
really an extremely unfair attempt on your part). I'm pointing you to
ways you might get your wish, if you're willing to do some work for the
purpose. Coding the preprocessor is the easy part -- the work is mostly
in doing the PEP, including a variety of strong use cases for a general
purpose preprocessor. (Of course, forking Python to hardcode your
preprocessor is easier, but forking always has other problems).
Alex

[Dave Benjamin]

Alex Martelli wrote:

The main reason I suggest a general-purpose mechanism for the hooking-up
of the preprocessor is that such a mechanism might stand a chance to be
accepted (via the usual PEP procedure), as long as other interesting use
cases can be found; I suspect that if the only use case was "turn braces
into indents/dedents", the PEP would stand no chance.

+1 on the preprocessor idea, especially if it would allow us to hook in
at the AST level as well. (No comment on the curlies. ;)

Dave

[Thomas Bartkus]

"Joe" <jk****@nc.rr.com> wrote in message
news:11**********************@g47g2000cwa.googlegr oups.com...

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.

Many people think Python's syntax makes sense. There are strong
feelings both ways. It must depend on a person's way of thinking,
because I find it very confusing, even after using with Python for some
time, and trying to believe the advice that I would learn to like it.
The most annoying thing is that multiple dedents are very unreadable. I
still don't understand how anybody can think significant-but-invisible
dedentation is a good thing.

Note: No need to follow up with long opinions of why indentation is
good -- they have been posted hundreds of times. It just seems that
Python developers think the whitespace thing is only an issue for
newbies. I think that many experienced users don't learn to like it,
but instead just learn to live with it.

Okay - I'll take your note and not argue about "why indentation is good"

But - why should Python
"support s syntax the does not use it's infamous whitespace rules"
It's unique to Python. That's what Python *is*.

If one doesn't like it, one needn't waste one's time with it. No other
other language abides by those rules except Python.

So just choose a different language to work with.
Thomas Bartkus

[Terry Hancock]

On Fri, 23 Dec 2005 11:51:23 -0700
Dave Benjamin <ra***@lackingtalent.com> wrote:

+1 on the preprocessor idea, especially if it would allow
us to hook in at the AST level as well. (No comment on
the curlies. ;)

Only +0 on it myself, but I do know of a use-case -- certain
types of web-templating frameworks can be easier to use if
the inserted code can be put on one line.

Some people have been agitating for some way to do this with
Python for some time (on Zope lists), and a preprocessor
would provide a means for them to get what they want.

OTOH, I have been able to manage with the way things are. It
encourages good separation between templates and code, which
is supposed to be a good thing according to the "Zope Zen".
;-)
--
Terry Hancock (ha*****@AnansiSpaceworks.com)
Anansi Spaceworks http://www.AnansiSpaceworks.com

[BartlebyScrivener]

What's needed is STRICTER whitespace enforcement, especially on April
Fools Day. Some call it whitespace fascism.

http://www.artima.com/weblogs/viewpo...?thread=101968

rpd

[James Tanis]

On 23 Dec 2005 10:01:37 -0800, Joe <jk****@nc.rr.com> wrote:

It just seems that
Python developers think the whitespace thing is only an issue for
newbies. I think that many experienced users don't learn to like it,
but instead just learn to live with it.

I disagree, I don't think you can be an experienced python programmer
and not be comfortable with its syntax. On the other hand you *can* be
an experienced programmer, but that's not the same thing. I don't care
how much code you've written in Python, if your not comfortable with
the syntax then you clearly don't use it with enough consistency to
bring yourself to that point where you "own" it. There's nothing wrong
with that, for whatever reason, maybe Python isn't for you.. but
certainly don't blame it on something as small as significant
indention, because we've all been there and its just not that hard to
make the change. There are quite a few good high-level languages out
there these days. This may be out of place, but I'd suggest checking
out Ruby if you want something as powerful and "fun" to code in as
Python but with more Perl-like syntax. It doesn't quite have as much
of a diverse module selection as Python and Perl but that will change
with time. Open source gives us an unprecendented amount of choices,
try them all out.. I have, and I came up with Python because for me it
is the "best fit." That may not be true in your case, which is
perfectly fine.

--
James Tanis
jt****@pycoder.org
http://pycoder.org

[thakadu]

It is not really unique to Python as I have pointed out on this or
other forums before. The Occam (OCCAM?) language also uses significant
whitespace in much the same way as Python and there may also be others.

[rbt]

BartlebyScrivener wrote:

What's needed is STRICTER whitespace enforcement, especially on April
Fools Day. Some call it whitespace fascism.

http://www.artima.com/weblogs/viewpo...?thread=101968

I've only been coding Python for about 3 years now. C is the only other
language I'm moderately good with. Most of the people on
comp.lang.python have _much_ more coding experience than I do. I don't
know who came up with this PEP, but I like it a lot. To me, it makes
sense, just like Python makes sense. Any time-line on implementing this?

[thakadu]

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 '}'. 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. Sometimes in vim "100==" fixes it but very often not. It would
be nice if you could use an "end" delimiter for quick experimentation
with code and then later on go and remove the "end" and fix the
indentation.

[Gary Herron]

Joe wrote:

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.

Only over our dead bodies! ("our" = the large and
always growing Python
community.)
Many people think Python's syntax makes sense. There are strong
feelings both ways. It must depend on a person's way of thinking,
because I find it very confusing, even after using with Python for some
time, and trying to believe the advice that I would learn to like it.
The most annoying thing is that multiple dedents are very unreadable. I
still don't understand how anybody can think significant-but-invisible
dedentation is a good thing.

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

Try this experiment: Print out a page of C++ code,
tape it to the wall,
and start walking backwards. You will still be
able to discern the
structure of the code *long* after you can no
longer identify the
curly-braces. (Provided you properly indented you
C++ code -- you *do*
indent you C++ code don't you?)

Gary Herron
Note: No need to follow up with long opinions of why indentation is
good -- they have been posted hundreds of times. It just seems that
Python developers think the whitespace thing is only an issue for
newbies. I think that many experienced users don't learn to like it,
but instead just learn to live with it.

[Gary Herron]

rbt wrote:

BartlebyScrivener wrote:

What's needed is STRICTER whitespace enforcement, especially on April
Fools Day. Some call it whitespace fascism.

http://www.artima.com/weblogs/viewpo...?thread=101968

I've only been coding Python for about 3 years now. C is the only other
language I'm moderately good with. Most of the people on
comp.lang.python have _much_ more coding experience than I do. I don't
know who came up with this PEP, but I like it a lot. To me, it makes
sense, just like Python makes sense. Any time-line on implementing this?

Look at the date. That was an April Fools joke.

Gary Herron

[rbt]

Gary Herron wrote:

rbt wrote:

BartlebyScrivener wrote:

What's needed is STRICTER whitespace enforcement, especially on April
Fools Day. Some call it whitespace fascism.

http://www.artima.com/weblogs/viewpo...?thread=101968

I've only been coding Python for about 3 years now. C is the only
other language I'm moderately good with. Most of the people on
comp.lang.python have _much_ more coding experience than I do. I don't
know who came up with this PEP, but I like it a lot. To me, it makes
sense, just like Python makes sense. Any time-line on implementing this?

Look at the date. That was an April Fools joke.

Gary Herron

I still think it makes sense :) ... perhaps I'm a fool.

[BartlebyScrivener]

The PEP is not a joke. It's a sensible set of guidelines. The blog post
advocating enforcement is, shall we say, a sportive modest proposal?

rpd
www.dooling.com

"There is no human problem which could not be solved if people would
simply do as I advise."--Gore Vidal

[Steven D'Aprano]

On Fri, 23 Dec 2005 15:22:39 -0800, thakadu wrote:

It is not really unique to Python as I have pointed out on this or
other forums before. The Occam (OCCAM?) language also uses significant
whitespace in much the same way as Python and there may also be others.

Python doesn't have any more significant whitespace than any other
language:

x=12*sum([3,5,7,9,2][1:4])+3#comment

means the same thing as:

x = 12 * sum ( [ 3 , 5 , 7 , 9 , 2 ] [ 1 : 4 ] ) + 3 # comment

(although there are recommendations for where you should use whitespace).
You can mix spaces and tabs between tokens.

Like most computer languages, line breaks are significant in Python.
Nobody worries about that except maybe Forth programmers.

Also, *indentation* is significant, unlike most languages which treat
indentation as syntactically optional but enforce it via coding standards,
code beautifiers, pretty-printers, etc.
--
Steven.

[Alex Martelli]

thakadu <th*****@gmail.com> wrote:

It is not really unique to Python as I have pointed out on this or
other forums before. The Occam (OCCAM?) language also uses significant
whitespace in much the same way as Python and there may also be others.

Haskell. Rules not identical to Python (they have something called "the
offside rule" which is at least as subtle as the one in soccer;-) but
practical effects that are quite close.
Alex

[James Tanis]

On 23 Dec 2005 15:22:39 -0800, thakadu <th*****@gmail.com> wrote:

It is not really unique to Python as I have pointed out on this or
other forums before. The Occam (OCCAM?) language also uses significant
whitespace in much the same way as Python and there may also be others.

Your right of course, but I don't think it really even needs to be
said. I mean whether or not Python is the only language that uses
white space in a significant manner doesn't change the fact that..
well Python can do whatever the heck Python wants to do with its
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.

--
James Tanis
jt****@pycoder.org
http://pycoder.org

[bonono]

James Tanis wrote:

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.

That is what a "cafe" type newsgroup is for, nothing but time killing
:-)

For those who really cannot stand it, they would have moved on to
whatever other language that they feel better(or more tolerable in
whatever sense).

[Steve Holden]

thakadu wrote:

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 '}'. [...]

Of course, therein lies the answer: the "I don't like indentation" crowd
should all be put in a room and not allowed out until they can all agree
on the best alternative.

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

[Björn Lindström]

"thakadu" <th*****@gmail.com> writes:

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.

--
Björn Lindström <bk**@stp.lingfil.uu.se>
Student of computational linguistics, Uppsala University, Sweden

[Steven D'Aprano]

On Fri, 23 Dec 2005 15:31:55 -0800, thakadu wrote:

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.

--
Steven.

[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]

James Tanis <jt****@pycoder.org> wrote:
...

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]

On 2005-12-23, Gary Herron <gh*****@islandtraining.com> wrote:

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?

[André]

Lee Harr wrote:

On 2005-12-23, Gary Herron <gh*****@islandtraining.com> wrote:

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?

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

André

[gene tani]

Lee Harr wrote:

On 2005-12-23, Gary Herron <gh*****@islandtraining.com> wrote:

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?

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]

On 24 Dec 2005 18:36:32 -0800, Joe <jk****@nc.rr.com> wrote:

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 :P. --
http://mail.python.org/mailman/listinfo/python-list

--
James Tanis
jt****@pycoder.org
http://pycoder.org

[Paul McGuire]

"Lee Harr" <le*@example.com> wrote in message
news:5%**************@news02.roc.ny...

On 2005-12-23, Gary Herron <gh*****@islandtraining.com> wrote:

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?

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

-- Paul

[Ilias Lazaridis]

Larry Bates wrote:

Joe wrote:

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

Many people think Python's syntax makes sense. There are strong
feelings both ways. It must depend on a person's way of thinking,
because I find it very confusing, even after using with Python for some
time, and trying to believe the advice that I would learn to like it.
The most annoying thing is that multiple dedents are very unreadable. I
still don't understand how anybody can think significant-but-invisible
dedentation is a good thing.

Note: No need to follow up with long opinions of why indentation is
good -- they have been posted hundreds of times. It just seems that
Python developers think the whitespace thing is only an issue for
newbies. I think that many experienced users don't learn to like it,
but instead just learn to live with it.

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

[...]

This has nothing to do with fairness.

..

--
http://lazaridis.com/core/eval/python.html

[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]

Robert Hicks wrote:

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

..

--
http://lazaridis.com

[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]

On 26 Dec 2005 04:10:11 -0800, ju****@zeusedit.com <ju****@zeusedit.com> wrote:

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:

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

--
James Tanis
jt****@pycoder.org
http://pycoder.org

[Jon Perez]

Joe wrote:

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]

Ilias Lazaridis wrote:

Is Python going to support s syntax the does not use it's infamous
whitespace rules?

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]

thakadu wrote:

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
<jb********@yahoo.com> wrote:

[...]

Although the below does work, I believe:

Verified example:

def check_indent(n): 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!"

for n in range(4,0,-1): check_indent(n)
You like four spaces
I like three
Others like two
But don't mix TABs and spaces!

Regards,
-=Dave

--
Change is inevitable, progress is not.

[Jon Perez]

Joe wrote:

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. ... I'm talking about double un-indent at the end of a nested loop,
where the inner-most code is long enough that the end is a double
dedent. It is especially bad because one persons single dedent can be as
big as another persons double dedent. I agree with dislikes for brace
notation, but I think it goes against the argument that Python's way is
natural and right.
For me, I just feel Python's approach is simple and works.
If one includes an end-thing for every start-thing, I think it is more
natural, and still far better than C, but also more verbose.
Indeed. I don't like unnecessary verbosity.
In Python, one can use comments where needed, like below, which is what
I eventually started doing. But, Python is supposed to require 'easy to
read' code.

if ...
for x...
for y...
... lots of code ...
#end for
#end for
#end if
Well doesn't that mean that in Python, you get the best of both worlds?
You can make it verbose if you need the security of closing tokens,
but it is not necessary.

I suspect you may still have some sort of hangover from using C-style
indentation in that you are subliminally not confident that a block
is properly closed unless there is a visible closing token.

The main thing that I just don't get is why Python promoters are so
sure that everyone will like the Python syntax once they get used to it.

I myself would never assume that 100% of people will like Python syntax. But
I know I took to it (including and *especially* the enforced indentation)
like a duck to water, and apparently so do many people. But then that's
why there are other languages out there. ;-)

[thakadu]

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

Correct, and therein lies the problem I am describing.
If someone has used two spaces and you paste into
the SAME block where you are using four spaces
you will break your code.

[Diez B. Roggisch]

thakadu wrote:

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

Correct, and therein lies the problem I am describing.
If someone has used two spaces and you paste into
the SAME block where you are using four spaces
you will break your code.

And then you invoke your "in/dedent block" function of your editor, and
things work. Similar to hitting "Format Source" in eclipse for JAVA.

Diez

[thakadu]

Yes, thats what you have to do. And that was my original point, you
cannot just paste and go, you have to first reformat.

[Dave Hansen]

On 16 Jan 2006 20:41:24 -0800 in comp.lang.python, "thakadu"
<th*****@gmail.com> wrote:

Yes, thats what you have to do. And that was my original point, you
cannot just paste and go, you have to first reformat.

My heart bleeds.

Regards,
-=Dave

--
Change is inevitable, progress is not.