Indenting with tabs vs spaces
David Bolen
> > >Tabs are wrong, because different editors will treat them differently.
> > >
> > >Spaces are right, because a space is a space is a space, everywhere you
> > >go.
>
> Indenting with tabs can be done such that it will look the same on every
> editor that uses fixed-width fonts, meaning everything will line up
> correctly, it least in the sense that really matters.
Um, that's only true if your visual display uses the same indentation
for tabs as someone else's. E.g., if your fixed-width editor has "tab
stops" at 4 spaces, and someone else's has it at 8, then obviously
what lines up on yoru screen won't on theirs and vice versa. It just
gets worse if you include a mixture of tabs and spaces, since then it
probably won't even be aligned in general on the other system.
The above only works if you both agree on the visual display of the
tab character.
> Besides this I know of no problems with using tabs. I find them
> cleaner and more efficient. I'd rather tab 10 times than hit the
If only we could all agree on how tabs in a file should be displayed
there wouldn't be a problem (technically, there's no parser problem
anyway it's all visual but then that's part of coding). But clearly
as past discussions have shown we can't, so the general rule of
sticking with spaces makes it easier for everyone to see the same
visual representation of source.
Your example code is a good example - it showed up in my newsreader
(fixed font) as:
function helloThere("hello",
"there"){
}
so I'm not quite sure what it was supposed to look like, but I expect
it certainly didn't look like that on your screen :-)
> cleaner and more efficient. I'd rather tab 10 times than hit the
> space bar 40 times. I never have to go through a whole file and
> manually line things up because at one place in the file I
> accidentally didn't indent with the right amount of spaces and half
> the file needs fixing. Auto-indent helps, but still....
As someone else pointed out, we do need to keep distinct the concept
of pressing the tab key, and using a tab character within the source.
There are many ways to minimize input while not requiring hard tabs in
the source. There's absolutely nothing wrong with using the tab key
to indicate that you want some sort of logical indentation, but it's
probably best if the tool decides to do it with spaces.
For example, Python mode in emacs will auto-indent a line on tab, but
if it guesses wrong, a single backspace will step back a full
indentation level (4 spaces) so it can still be very efficient to key
in even though spaces are being used.
--
-- David
--
/-----------------------------------------------------------------------\
\ David Bolen \ E-mail: db...@fitlinxx.com /
| FitLinxx, Inc. \ Phone: (203) 708-5192 |
/ 860 Canal Street, Stamford, CT 06902 \ Fax: (203) 316-5150 \
\-----------------------------------------------------------------------/
Peoter Veili
> >Tabs are wrong, because different editors will treat them differently.
> >
> >Spaces are right, because a space is a space is a space, everywhere you
> >go.
Indenting with tabs can be done such that it will look the same on every
editor that uses fixed-width fonts, meaning everything will line up
correctly, it least in the sense that really matters. Here's an example of
what I mean:
function helloThere("hello",
"there"){
}
The proper way to do this is the second line needs to be typed with one tab
followed by enough spaces to line up the "hello" and "there". This way the
"hello" and "there" will line up correctly on any editor. If the person was
lazy and tabbed all the way out to right before "there" and then filled in
with a
few spaces, it may not line up depending on what your tabwidth is set to.
Besides this I know of no problems with using tabs. I find them cleaner and
more efficient. I'd rather tab 10 times than hit the space bar 40 times. I
David Eppstein
"Peoter Veili" <peoter...@hotmail.com> wrote:
> Indenting with tabs can be done such that it will look the same on every
> editor that uses fixed-width fonts, meaning everything will line up
> correctly, it least in the sense that really matters. Here's an example of
> what I mean:
>
>
>
> function helloThere("hello",
> "there"){
> }
I viewed your message with fixed-width fonts, and it came out unaligned as
you see above. So I think your claim that "it will look the same on every
editor" is false, and it is safer to stick with spaces only.
--
David Eppstein UC Irvine Dept. of Information & Computer Science
epps...@ics.uci.edu http://www.ics.uci.edu/~eppstein/
John Roth
"Peoter Veili" <peoter...@hotmail.com> wrote in message
news:mailman.1006387828...@python.org...
> Indenting with tabs can be done such that it will look the same on
every
> editor that uses fixed-width fonts, meaning everything will line up
> correctly, it least in the sense that really matters. Here's an
example of
> what I mean:
>
>
>
> function helloThere("hello",
> "there"){
> }
>
>
> The proper way to do this is the second line needs to be typed with
one tab
> followed by enough spaces to line up the "hello" and "there". This
way the
> "hello" and "there" will line up correctly on any editor. If the
person was
> lazy and tabbed all the way out to right before "there" and then
filled in
> with a
> few spaces, it may not line up depending on what your tabwidth is set
to.
>
> Besides this I know of no problems with using tabs.
The trouble with this is that all of your tools need to agree on where
the tab stops are set. In the example above, you probably used four
character tabs, and the tool you used formatted it as 8 character tabs.
(At least, it looks that way to me.) If you disagree with the
interpreter,
you've lost it. In particular, if you try using four character tabs, and
the
Python interpreter thinks you are using 8 character tabs, you're going
to
have lots of indentation errors that your editor won't show.
> I find them cleaner and
> more efficient. I'd rather tab 10 times than hit the space bar 40
times. I
> never have to go through a whole file and manually line things up
because at
> one place in the file I accidentally didn't indent with the right
amount of
> spaces and half the file needs fixing. Auto-indent helps, but
still....
A good syntax aware editor does all of this for you. If you're arguing
with your editor, you can:
1. get a new editor you agree with
2. find another job where you can use the editor of your choice,
3. get over it.
4. suffer.
John Roth
>
>
>
>
>
Peter Bismuti
"David Eppstein" <epps...@ics.uci.edu> wrote in message
news:eppstein-41FDAD...@news.service.uci.edu...
> --
> http://mail.python.org/mailman/listinfo/python-list
>
Kaden
> For example, Python mode in emacs will auto-indent a line on tab, but
> if it guesses wrong, a single backspace will step back a full
> indentation level (4 spaces) so it can still be very efficient to key
> in even though spaces are being used.
The following will do the same type of thing you describe (and more) if
you use vim:
set expandtab " expand tabs out to spaces
set sw=4 " shiftwidth set to 4 spaces
set tabstop=4 " indent 4 spaces per tab
set softtabstop=4 " BS and DEL see multiple spaces as a tabstop
set bs=2 " allow backspacing over everything in insert mode
set ai " always set autoindenting on
set list " visualize whitespace
set listchars=tab:»·,trail:· " show spaces as · and tabs as »·
" Whenever you type any of the words in the list, it will automatically
" set the cursor at the next indention level.
au BufRead *.py set smartindent \
cinwords=if,elif,else,for,while,try,except,finally,def,class
Of course you could change all these to only take effect when editing a
python file, as the last example does, if you don't like tabs expanded or
tabwidths of 4 chars in your regular text.
One argument I hear from advocates of tabs in source is that it's
difficult to see if one line's indention is off by just one space.
That's what the list and listchars lines help with. For each tab you
should see two of those arrows and three dots. If you don't, something's
not lined up right.
Peter Hansen
Peter Bismuti wrote:
> "David Eppstein" <epps...@ics.uci.edu> wrote:
> > "Peoter Veili" <peoter...@hotmail.com> wrote:
> >
> > > Indenting with tabs can be done such that it will look the same on every
> > > editor that uses fixed-width fonts, meaning everything will line up
> > > correctly, it least in the sense that really matters. Here's an example
> > > of what I mean:
> > >
> > > function helloThere("hello",
> > > "there"){
> > > }
> >
> > I viewed your message with fixed-width fonts, and it came out unaligned as
> > you see above. So I think your claim that "it will look the same on every
> > editor" is false, and it is safer to stick with spaces only.
> >
> Be that as it may, I think what I have written is correct in general.
Unfortunately, you are wrong to think that, as it is quite false.
Maybe if you rewrote it as follows it would be "correct in general":
""" Indenting with tabs can be done in such a way that it
will look correct on some editors. """
--
----------------------
Peter Hansen, P.Eng.
pe...@engcorp.com
Ron Stephens
indeented with single tabs (four spaces I think). Since I use IDLE or sometimes
PythonWin when I code, will my tabs screw up anyone else trying to run my code?
H9ow about if I use Windows Notepad?
I hate spaces, like tabs.
Hans Nowak
>
> OK, now you all have got me worrying about a new thing. All my code so far is
> indeented with single tabs (four spaces I think). Since I use IDLE or sometimes
> PythonWin when I code, will my tabs screw up anyone else trying to run my code?
> H9ow about if I use Windows Notepad?
>
> I hate spaces, like tabs.
Single tabs are alright. So are spaces. It's the mixing of the two that
causes
indentation errors.
--Hans
Ron Stephens
Ron Stephens
Tim Roberts
>
>> >Tabs are wrong, because different editors will treat them differently.
>> >
>> >Spaces are right, because a space is a space is a space, everywhere you
>> >go.
>
>Indenting with tabs can be done such that it will look the same on every
>editor that uses fixed-width fonts, meaning everything will line up
>correctly, it least in the sense that really matters.
That's just not true. The crux of the problem is that "tab" does not have
a universal meaning. As long as there is a physical tab character at the
beginning of a line, the file will look different in my vim, where tabstop
is 8, and in my Visual C++, where the default hard tab is 4. It might look
similar, but it will not look the same.
>Here's an example of what I mean:
>
> function helloThere("hello",
> "there"){
> }
>
>The proper way to do this is the second line needs to be typed with one tab
>followed by enough spaces to line up the "hello" and "there".
You're still assuming that the first tab you typed means "4 spaces". Plus,
I should not have to type a jillion spaces to get that to line up.
Now, I certainly should be able to TYPE that line with the tab key, but
when it's written to file it should have spaces. That's the only way to
guarantee that it will look the same in your editor as it looks in mine.
>Besides this I know of no problems with using tabs. I find them cleaner and
>more efficient. I'd rather tab 10 times than hit the space bar 40 times. I
>never have to go through a whole file and manually line things up because at
>one place in the file I accidentally didn't indent with the right amount of
>spaces and half the file needs fixing.
Right. You should be able to hit the "tab" key 10 times (or 5 times) to
get 40 spaces, but the file you save to disk should have spaces.
--
- Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
Dave Cinege
> Right. You should be able to hit the "tab" key 10 times (or 5 times) to
> get 40 spaces, but the file you save to disk should have spaces.
Damn, that's stupid!
A tab has a byte value of '9'. How it's is displayed is completely arbitary,
subjective, and the job of your editor. The fact the file will look
different between editors is a good thing. The idea all source files should
not be able to be displayed any otherway then how the author first created
them is:
_DUMB_
(^^Yes and I just tabbed you!! HAHA)
Quite moot however....GOD has already decided.
Steve Lamb
> Indenting with tabs can be done such that it will look the same on every
> editor that uses fixed-width fonts, meaning everything will line up
> correctly, it least in the sense that really matters. Here's an example of
> what I mean:
Uhhh....
> function helloThere("hello",
> "there"){
> }
...no.
> The proper way to do this is the second line needs to be typed with one tab
> followed by enough spaces to line up the "hello" and "there".
A tab is a variable. I have tab set to 2 spaces. You have it set to 8.
So by your logic you hit tab + 32 spaces. To you that would b 40 spaces. To
me that is 32. 40 != 32, even for large values of 32.
> This way the "hello" and "there" will line up correctly on any editor. If
> the person was lazy and tabbed all the way out to right before "there" and
> then filled in with a few spaces, it may not line up depending on what your
> tabwidth is set to.
Which is what happens if you use a single tab or 32 tabs. A space is a
space. 1=1. All others are variable.
> Besides this I know of no problems with using tabs. I find them cleaner and
> more efficient. I'd rather tab 10 times than hit the space bar 40 times. I
> never have to go through a whole file and manually line things up because at
> one place in the file I accidentally didn't indent with the right amount of
> spaces and half the file needs fixing. Auto-indent helps, but still....
So does moving blocks back and forth (>> and << in vim, ^K> and ^K< in
Joe, etc...). Mark the beginning, mark the end, move block. No biggie. As
for hitting space 40 times or tab 10 I rather hold down the space bar once.
--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
ICQ: 5107343 | main connection to the switchboard of souls.
To email: Don't despair! | -- Lenny Nero, Strange Days
-------------------------------+---------------------------------------------
Steve Lamb
> A tab has a byte value of '9'. How it's is displayed is completely arbitary,
> subjective, and the job of your editor. The fact the file will look
> different between editors is a good thing. The idea all source files should
> not be able to be displayed any otherway then how the author first created
> them is:
This is because, as Python has shown, formatting does mean something.
That is why indention is important to the language and not just there for the
programmers as in other languages. It is a visual representation of the
meaning of code. Furthermore there are times, even in Python, where something
is better displayed visually even though it is not required by the language.
For example:
some_dict = {'Jane':{'Age':'21', 'Dept':'0001', 'Ext':'1234'},
'John':{'Age':'22', 'Dept':'0010', 'Ext':'5678'},
'Jeff':{'Age':'23', 'Dept':'0100', 'Ext':'9009'},
'Jody':{'Age':'24', 'Dept':'1000', 'Ext':'8765'},
'Jeny':{'Age':'25', 'Dept':'0110', 'Ext':'4321'}
}
Yeah, yeah, we'll most likely be reading from a database for things of
this nature and it is an overly simplistic example, however, it points out a
valid point. My intent, as the original author, is better read in the format
that I have presented. Tabs undermine this formatting.
What if I use 4 and you use 8?
some_dict = {'Jane':{'Age':'21', 'Dept':'0001', 'Ext':'1234'},
'John':{'Age':'22', 'Dept':'0010', 'Ext':'5678'},
'Jeff':{'Age':'23', 'Dept':'0100', 'Ext':'9009'},
'Jody':{'Age':'24', 'Dept':'1000', 'Ext':'8765'},
'Jeny':{'Age':'25', 'Dept':'0110', 'Ext':'4321'}
}
The other way around?
some_dict = {'Jane':{'Age':'21', 'Dept':'0001', 'Ext':'1234'},
'John':{'Age':'22', 'Dept':'0010', 'Ext':'5678'},
'Jeff':{'Age':'23', 'Dept':'0100', 'Ext':'9009'},
'Jody':{'Age':'24', 'Dept':'1000', 'Ext':'8765'},
'Jeny':{'Age':'25', 'Dept':'0110', 'Ext':'4321'}
}
Are you prepared to say that either of those is far more readable than the
first example?
And yes, we can say "Well what if the person uses crappy formatting."
Then they used crappy formatting and nothing will help that but reformatting.
However, the tools we use should not undermine our intent and meaning when we
use formatting to increase readability.
Lee Harr
If using tab can cause trouble when moving source files from one
editor to another (or one person's configuration of an editor to
another) why not just get rid of using tab for indentation
altogether?
</fanFlamesOfReligiousWar>
Steve Lamb
You'll not find tabs in any code that I touch. Literally. I've got my
editor configured to save spaces, not tabs.
Lee Harr
> editor configured to save spaces, not tabs.
>
Same here.
I am just wondering that if letting people actually use tabs
is causing trouble, why not get rid of that "feature".
Seems much less controversial than *cough* integer arithmetic *cough*
anyhow...
Robin Becker
<mis...@frontiernet.net> writes
>> You'll not find tabs in any code that I touch. Literally. I've got my
>> editor configured to save spaces, not tabs.
>>
>
>Same here.
>
>I am just wondering that if letting people actually use tabs
>is causing trouble, why not get rid of that "feature".
>
well I'm +1 on use of tabs. It's much better when the response time is
long eg across the Atlantic or a heavily loaded server.
--
Robin Becker
Courageous
>well I'm +1 on use of tabs. It's much better when the response time is
>long eg across the Atlantic or a heavily loaded server.
If you're noticing a difference with small things like text files,
I highly suggest you use a compressing transport protocol.
C//
Jeff Hinrichs
Actually, spaces are the problems not tabs. A tab is a tab, where is
indenting by spaces....hmm.
let's see, I like 4 spaces, he like 8 and she likes 6 and so on. That
causes more grief than tabs.
Where as tabs, 1 tab = 1st level block, 2 tabs = 2nd level block and so on.
Maybe if people didn't use such brain dead editors that actually replaced
tabs with spaces this would be a complete non-issue. You should be able to
configure your editor to display tabs in a width that is to your liking
WITHOUT mucking with the data. As it is, we are doomed to listen to this
argument go on ad nauseum.
jeff
"and that's all I have to say about that"
- Forest Gump
Dave Cinege
> my 0.02$US:
> Actually, spaces are the problems not tabs. A tab is a tab, where is
> indenting by spaces....hmm.
> let's see, I like 4 spaces, he like 8 and she likes 6 and so on. That
> causes more grief than tabs.
> Where as tabs, 1 tab = 1st level block, 2 tabs = 2nd level block and so on.
>
> Maybe if people didn't use such brain dead editors that actually replaced
> tabs with spaces this would be a complete non-issue. You should be able to
> configure your editor to display tabs in a width that is to your liking
> WITHOUT mucking with the data. As it is, we are doomed to listen to this
> argument go on ad nauseum.
Be comforted to know the LORD has told me, to tell you, you will be saved
for spreading the good word...
> @home.com
...though he says he can only do so much to keep your connection up.
--
The time is now 22:54 (Totalitarian) - http://www.ccops.org/
Jeff Hinrichs
> for spreading the good word...
>
> > @home.com
>
> ...though he says he can only do so much to keep your connection up.
got sent to hell<g>
Courageous
>let's see, I like 4 spaces, he like 8 and she likes 6 and so on. That
I'm sure glad you like 4, because if you were working on my team,
that's exactly the way one indents python. And well, if you don't
like the coding standard, I suppose you can always find another
project, eh? :)
C//
Fernando Pérez
> my 0.02$US:
> Actually, spaces are the problems not tabs. A tab is a tab, where
> is indenting by spaces....hmm.
> let's see, I like 4 spaces, he like 8 and she likes 6 and so on.
> That causes more grief than tabs.
> Where as tabs, 1 tab = 1st level block, 2 tabs = 2nd level block and
> so on.
>
> Maybe if people didn't use such brain dead editors that actually
> replaced
> tabs with spaces this would be a complete non-issue. You should be
> able to configure your editor to display tabs in a width that is to
> your liking
> WITHOUT mucking with the data. As it is, we are doomed to listen to
> this argument go on ad nauseum.
>
In theory, I agree with you. Reality, as always, is more complicated.
But not because of brain-dead editors. Even if you could rid the
world of those, and were left with only god-fearing, tab-respecting
editors, you'd still have a problem: *not all code is typed by hand*.
Pasting. There's the breaker for this issue. One of the beauties of
python is the interactive prompt, right? You type some code, if it
works you highlight, middle click and off you go. Well, try it and
see where your tabs go. Or the web, or newsgroups, or email... There
are *many* situations which don't preserve tabs as tabs, and code
flows through them. So forget about it.
Again, in an ideal world where not only editors but *every
conceivable piece of software that can display text* respected tabs
as tabs, your idea would work.
Welcome to reality.
f.
Peoter Veliki
With tabs, each person can set the indenting width to whatever value he/she
likes best. As one person pointed out, a tab is a variable. This
flexibility is tantamount to a "separation of style and content". This is
an argument *for* using tabs.
Neil Hodgson
> With tabs, each person can set the indenting width to whatever value
> he/she likes best. As one person pointed out, a tab is a variable. This
> flexibility is tantamount to a "separation of style and content". This is
> an argument *for* using tabs.
It could also be an argument for editors interpreting indentation spaces
differently to post-indentation spaces. If you have a file formatted with 4
space indentation and prefer 2 space indentation, then the editor can simply
interpret each indentation space as taking up half the width that it would
otherwise need.
Neil
Courageous
<peoter...@hotmail.com> wrote:
>Perhaps this is besides the point of the original posting, but......
>
>With tabs, each person can set the indenting width to whatever value he/she
>likes best. As one person pointed out, a tab is a variable. This
>flexibility is tantamount to a "separation of style and content". This is
>an argument *for* using tabs.
Until tabs and spaces are mixed, and then we have a living nightmare.
I see this in other programming languages all the time, where someone
comes along with a different tab notion than mine, edits the file, and
then commits it. This creates horribly formatted files where the
indentation levels of lines of code throughout the file.
But this is all academic, because the defacto and near dejure standard
for Python is 4 spaces per indentation level. Tabs are deprecated.
Insert tabs if you like. I predict you will annoy lots of other Python
programmers, when you begin to work with them.
C//
Robin Becker
<jkr...@san.rr.com> writes
get compression to work I have to wait for at least some characters to
fill a buffer. God knows what it would do to multi-character sequences
which are often detected by timing.
As often the seriously under experienced are shouting the loudest.
--
Robin Becker
Steve Lamb
> my 0.02$US:
> Actually, spaces are the problems not tabs. A tab is a tab, where is
> indenting by spaces....hmm.
No, a tab isn't a tab.
> You should be able to configure your editor to display tabs in a width that
> is to your liking WITHOUT mucking with the data.
As you just said, "You should be able to configure your editor to display
tabs..." Oh, so a tab isn't a tab. I like indention of 4 so my tab is 4
spaces. You like 8 so yours is 8 spaces. A tab is not a tab. A tab is a
collection of spaces, visually.
Now, if you had read my post you would have seen where your whole "a tab
is a tab" bubbub breaks down. Here it is AGAIN since you missed it the first
time.
some_dict = {'Jane':{'Age':'21', 'Dept':'0001', 'Ext':'1234'},
'John':{'Age':'22', 'Dept':'0010', 'Ext':'5678'},
'Jeff':{'Age':'23', 'Dept':'0100', 'Ext':'9009'},
'Jody':{'Age':'24', 'Dept':'1000', 'Ext':'8765'},
'Jeny':{'Age':'25', 'Dept':'0110', 'Ext':'4321'}
}
With spaces that always comes out the same. With tabs set to different
lengths you get different results. The only constant when it comes to
indention is a space. A space is a space. A tab is not constant and
therefore should NOT be used for indention. Ever.
Indention isn't about preference, it is about making the code readable.
And as the above example shows, readable code could be rendered unreadable by
tab "preferences".
Paul Boddie
>
> I see this in other programming languages all the time, where someone
> comes along with a different tab notion than mine, edits the file, and
> then commits it. This creates horribly formatted files where the
> indentation levels of lines of code throughout the file.
Perhaps you might want to put some kind of processing step into your
revision control procedures or tools. I think I raised this issue
before on comp.lang.python but some people think it's more interesting
to get religious about tabs vs. spaces instead.
Personally, I use tabs for my own code because I have a UNIX
background and the only decent editors available on the systems I used
treated tabs properly. Subsequently, I've had the need to use spaces
for indentation, and decent editors will let you configure this and
even try and make the navigational behaviour workable too - where
editors treat indentation spaces as a collection of characters that
have to be navigated past individually, then the editing experience
starts to get irritating.
As most people are aware, tabs were intended for indentation purposes
in human-readable documents, whereas spaces are just word separators.
As a side-effect of the implementation of spaces, they can also be
used for indentation and text justification, but that doesn't mean
that they should be used for such purposes. Indeed, using spaces in
such a way in word processing or desktop publishing is a habit which
will inevitably get you into trouble, but the unfortunate thing is
that most word processors won't guide the user into avoiding this kind
of mistake. It would be interesting to see word processors accept just
one space between words, for example, as a means of discouragement.
Sadly, we just have to live with spaces in their unintended role, but
I think that rather than wasting time inventing urban legends,
folklore and "reasons" why one is better than the other, we should be
talking about practical measures that projects can use to avoid
tab/space mixing and other text-based nightmares (DOS text vs. UNIX
text, for example).
Paul
Andreas Kostyrka
> But this is all academic, because the defacto and near dejure standard
> for Python is 4 spaces per indentation level. Tabs are deprecated.
since 1.3. Works like a charm. Just never forget to install python-mode.el ;)
Andreas
--
Andreas Kostyrka; Raiffeisenstr. 16/9; 2320 Zwölfaxing
Tel: +43/676/4091256; Fax: +43/1/7065299
Courageous
>Perhaps you might want to put some kind of processing step into your
>revision control procedures or tools. I think I raised this issue
>before on comp.lang.python but some people think it's more interesting
>to get religious about tabs vs. spaces instead.
I've considered that on many occasions; one such step might be to
simply REJECT a commit of a .py file with tabs in it.
C//
Peoter Veliki
> >likes best. As one person pointed out, a tab is a variable. This
> >flexibility is tantamount to a "separation of style and content". This is
> >an argument *for* using tabs.
>
> Until tabs and spaces are mixed, and then we have a living nightmare.
Erik de Castro Lopo
YOu people are ***NUTS***.
How hard is it to find an editor that treats tabs correctly and allows
the tab width to be set to something other than 8?
Get a grip people.
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo nos...@mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"Don't be fooled by NT/Exchange propaganda. M$ Exchange is
just plain broken and NT cannot handle the sustained load
of a high-volume remote mail server"
-- Eric S. Raymond in the Fetchmail FAQ
Steve Lamb
wrote:
> YOu people are ***NUTS***.
Yes, we're nuts because we've had to deal with people like you.
> How hard is it to find an editor that treats tabs correctly and allows
> the tab width to be set to something other than 8?
Quite easy, which is the problem. Or are you ignoring my rather basic but
not uncommon example of code which gets messed up when people are able to
modify indention levels. For me it is *NOT* a matter of preference and never
was. I can read indention levels of 2, 4, 6 and 8 (though I rarely encounter
6) in Turbo Pascal, C, Perl, Python and HTML. In fact in most I *prefer* two.
But when formatting matters for clarity of code I am damned glad I can see
what the original author intended and not what I preferred!
> Get a grip people.
We have a grip, tighten yours.
Peter Bismuti
> --
> http://mail.python.org/mailman/listinfo/python-list
>
Erik de Castro Lopo
How about a counter proposal?
Reject all .py files with spaces for indentation.
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo nos...@mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"... the industrial-capitalist mode of software production
was doomed to be outcompeted from the moment capitalism
began to create enough of a wealth surplus for many
programmers to live in a post-scarcity gift culture."
-- Eric S. Raymond
Erik de Castro Lopo
>
> On Sat, 01 Dec 2001 23:14:04 -0000, Lee Harr <mis...@frontiernet.net> wrote:
> ><fanFlamesOfReligiousWar>
> > If using tab can cause trouble when moving source files from one
> > editor to another (or one person's configuration of an editor to
> > another) why not just get rid of using tab for indentation
> > altogether?
> ></fanFlamesOfReligiousWar>
>
> You'll not find tabs in any code that I touch. Literally. I've got my
> editor configured to save spaces, not tabs.
You really ought to try using nothing but tabs for indentation and setting the
tab width in your editor to whatever you prefer.
This is so easy and works **SO** well.
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo nos...@mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"I would rather spend 10 hours reading someone else's source
code than 10 minutes listening to Musak waiting for technical
support which isn't."
- Dr. Greg Wettstein, Roger Maris Cancer Center
Erik de Castro Lopo
>
> So much for cooler heads prevailing....(deep sigh).
Maybe my post was not the best way to deal with this matter.
However, the people who like me prefer using tabs (and nothing but tabs) for
indentation need to speak up.
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo nos...@mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
Running MS-Windows on a Pentium is like having a brand new Porsche
but only being able to drive backwards with the handbrake on.
Chris Barker
> > I've considered that on many occasions; one such step might be to
> > simply REJECT a commit of a .py file with tabs in it.
>
> How about a counter proposal?
>
> Reject all .py files with spaces for indentation.
Either one would be fine with me...and better than allowing either
(especially mixed...Yikes!!!)
-Chris
--
Christopher Barker,
Ph.D.
ChrisH...@home.net --- --- ---
http://members.home.net/barkerlohmann ---@@ -----@@ -----@@
------@@@ ------@@@ ------@@@
Oil Spill Modeling ------ @ ------ @ ------ @
Water Resources Engineering ------- --------- --------
Coastal and Fluvial Hydrodynamics --------------------------------------
------------------------------------------------------------------------
Chris Barker
> You really ought to try using nothing but tabs for indentation and setting the
> tab width in your editor to whatever you prefer.
>
> This is so easy and works **SO** well.
until you post your code to a milaing list or newsgroup...sigh.
Peter Bismuti
>
> Maybe my post was not the best way to deal with this matter.
>
I was just trying to add a little humor to lighten the conversation
a bit.
> However, the people who like me prefer using tabs (and nothing but tabs)
for
> indentation need to speak up.
I'm on your side. After following this thread I am more convinced that tabs
are a better approach as it allows for a separation of style and content.
Each person can view their file with whatever indentation width they prefer
(style) without altering the contents of the file (content).
With just a little bit of effort we can all learn to live together in
harmony. If Python 'tabbers' vs. 'non-tabbers' can't work out their
differences and learn to live together, what hopes do the Israelis and Arabs
have for god's sake!
William Park
> Erik de Castro Lopo wrote:
> > How about a counter proposal?
> > Reject all .py files with spaces for indentation.
>
> Either one would be fine with me...and better than allowing either
> (especially mixed...Yikes!!!)
I don't care! Just set the standard, be done with it. Please, no more
on this issue...
--
William Park, Open Geometry Consulting, <openge...@yahoo.ca>.
8 CPU cluster, NAS, (Slackware) Linux, Python, LaTeX, Vim, Mutt, Tin
David Bolen
> You really ought to try using nothing but tabs for indentation and
> setting the tab width in your editor to whatever you prefer.
>
> This is so easy and works **SO** well.
Always curious about this in an "all tab" world - how do you align
continuation lines that aren't on a tab stop?
--
-- David
--
/-----------------------------------------------------------------------\
\ David Bolen \ E-mail: db...@fitlinxx.com /
| FitLinxx, Inc. \ Phone: (203) 708-5192 |
/ 860 Canal Street, Stamford, CT 06902 \ Fax: (203) 316-5150 \
\-----------------------------------------------------------------------/
Mark Hammond
> On Mon, Dec 03, 2001 at 01:42:26PM -0800, Chris Barker wrote:
>
>>Erik de Castro Lopo wrote:
>>
>>>How about a counter proposal?
>>>Reject all .py files with spaces for indentation.
>>>
>>Either one would be fine with me...and better than allowing either
>>(especially mixed...Yikes!!!)
>>
>
> I don't care! Just set the standard, be done with it. Please, no more
> on this issue...
The standard has already been set -
http://www.python.org/doc/essays/styleguide.html
Mark.
Jeff Shannon
David Bolen wrote:
> Erik de Castro Lopo <nos...@mega-nerd.com> writes:
>
> > You really ought to try using nothing but tabs for indentation and
> > setting the tab width in your editor to whatever you prefer.
> >
> > This is so easy and works **SO** well.
>
> Always curious about this in an "all tab" world - how do you align
> continuation lines that aren't on a tab stop?
And even if you *do* so, then how are they going to stay aligned when the
next person to look at it uses a different tab size?
Jeff Shannon
Technician/Programmer
Credit International
Quinn Dunkan
On Mon, 03 Dec 2001 09:21:48 -0000, Steve Lamb <gr...@despair.dmiyu.org> wrote:
> As you just said, "You should be able to configure your editor to display
>tabs..." Oh, so a tab isn't a tab. I like indention of 4 so my tab is 4
>spaces. You like 8 so yours is 8 spaces. A tab is not a tab. A tab is a
>collection of spaces, visually.
>
> Now, if you had read my post you would have seen where your whole "a tab
>is a tab" bubbub breaks down. Here it is AGAIN since you missed it the first
>time.
>
>some_dict = {'Jane':{'Age':'21', 'Dept':'0001', 'Ext':'1234'},
> 'John':{'Age':'22', 'Dept':'0010', 'Ext':'5678'},
> 'Jeff':{'Age':'23', 'Dept':'0100', 'Ext':'9009'},
> 'Jody':{'Age':'24', 'Dept':'1000', 'Ext':'8765'},
> 'Jeny':{'Age':'25', 'Dept':'0110', 'Ext':'4321'}
> }
>
> With spaces that always comes out the same. With tabs set to different
Not for me it doesn't, when I use proportional fonts.
>lengths you get different results. The only constant when it comes to
>indention is a space. A space is a space. A tab is not constant and
>therefore should NOT be used for indention. Ever.
A space is not constant either.
> Indention isn't about preference, it is about making the code readable.
>And as the above example shows, readable code could be rendered unreadable by
>tab "preferences".
In a proportional font, spaces are usually pretty narrow. Code that uses two
spaces to indent is hard to read. Four is sort of ok, but hard to edit. Code
that insists on trying to line stuff up with spaces is very hard to read.
Code that uses tabs to indent is always readable.
Indentation is not the issue, it's the cute formatting.
My solution is:
1 - Use tabs to indent.
2 - Lose the cute formatting. The above becomes:
some_dict = {
'Jane' : { ...
'John' : { ...
}
That should come out ok no matter what people do with their tabs or spaces.
As long as you stay away from lisp and haskell type indentation.
(and in haskell I use real tabs anyway, because the editor gets misled by the
literate birdtracks and puts in not-enough spaces)
Fredrik Lundh
> indentation need to speak up.
no, we don't. the language won't change just because a few
people on a usenet newsgroup don't have anything better to do
with their time.
(how about writing some fun code, folks?)
</F>
Steve Lamb
> I'm on your side. After following this thread I am more convinced that tabs
> are a better approach as it allows for a separation of style and content.
> Each person can view their file with whatever indentation width they prefer
> (style) without altering the contents of the file (content).
How many times to I have to point out that style and content cannot be
separated?
Steve Lamb
wrote:
> You really ought to try using nothing but tabs for indentation and setting
> the tab width in your editor to whatever you prefer.
> This is so easy and works **SO** well.
Until you answer it here is the only reply you will get because I am tired
of reiterating that it is NOT "style" and "preference".
some_dict = {'Jane':{'Age':'21', 'Dept':'0001', 'Ext':'1234'},
'John':{'Age':'22', 'Dept':'0010', 'Ext':'5678'},
'Jeff':{'Age':'23', 'Dept':'0100', 'Ext':'9009'},
'Jody':{'Age':'24', 'Dept':'1000', 'Ext':'8765'},
'Jeny':{'Age':'25', 'Dept':'0110', 'Ext':'4321'}
}
What if I use 4 and you use 8?
some_dict = {'Jane':{'Age':'21', 'Dept':'0001', 'Ext':'1234'},
'John':{'Age':'22', 'Dept':'0010', 'Ext':'5678'},
'Jeff':{'Age':'23', 'Dept':'0100', 'Ext':'9009'},
'Jody':{'Age':'24', 'Dept':'1000', 'Ext':'8765'},
'Jeny':{'Age':'25', 'Dept':'0110', 'Ext':'4321'}
}
The other way around?
some_dict = {'Jane':{'Age':'21', 'Dept':'0001', 'Ext':'1234'},
'John':{'Age':'22', 'Dept':'0010', 'Ext':'5678'},
'Jeff':{'Age':'23', 'Dept':'0100', 'Ext':'9009'},
'Jody':{'Age':'24', 'Dept':'1000', 'Ext':'8765'},
'Jeny':{'Age':'25', 'Dept':'0110', 'Ext':'4321'}
}
You get it yet? You finally understand that preference SCREWS UP THE
INTENT AND READABILITY OF THE ABOVE EXAMPLE WHICH IS NOT ALL THAT UNCOMMON?
Yeesh. 3 days now and you still haven't address that real and valid concern!
Steve Lamb
wrote:
> Not for me it doesn't, when I use proportional fonts.
Anyone who uses proportional fonts for programming gets what they deserve
because neither spaces nor tabs work.
Courageous
>How hard is it to find an editor that treats tabs correctly and allows
>the tab width to be set to something other than 8?
To Python, a tab *IS* 8 spaces. YOU get a grip.
C//
Courageous
>> Always curious about this in an "all tab" world - how do you align
>> continuation lines that aren't on a tab stop?
>
>And even if you *do* so, then how are they going to stay aligned when the
>next person to look at it uses a different tab size?
A: you can't, and they won't.
We have more experience than they do and just don't understand us.
I might have made the "leave my tabs the fuck alone" argument 4 or
5 years ago. Not any longer.
Perhaps they simply haven't worked on a shared CVS tree.
C//
Steven Majewski
On Mon, 3 Dec 2001, Steve Lamb wrote:
> On 3 Dec 2001 23:17:22 GMT, Quinn Dunkan <qu...@chunder.ugcs.caltech.edu>
> wrote:
> > Not for me it doesn't, when I use proportional fonts.
>
> Anyone who uses proportional fonts for programming gets what they deserve
Less eye strain ?
Fewer headaches ?
> because neither spaces nor tabs work.
-- sdm
Jeff Hinrichs
to "DISPLAY"
tabs as 4 characters in width. It does not replace tabs with spaces it
displays the white space equivalent to 4 spaces. Spaces are great for
separating words/glyph combinations but are not proper for formatting.
Hammers work for nails but not screws. Same for spaces v. tabs.
> But this is all academic, because the defacto and near dejure standard
> for Python is 4 spaces per indentation level. Tabs are deprecated.
>
> Insert tabs if you like. I predict you will annoy lots of other Python
> programmers, when you begin to work with them.
>
> C//
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
Jeff Hinrichs
> I think that rather than wasting time inventing urban legends,
> folklore and "reasons" why one is better than the other, we should be
> talking about practical measures that projects can use to avoid
> tab/space mixing and other text-based nightmares (DOS text vs. UNIX
> text, for example).
Got my vote. I was just in the mood tonight so I figured what they hey how
about some pointless fun.
-jeff
Greg Ewing
>
> some_dict = {'Jane':{'Age':'21', 'Dept':'0001', 'Ext':'1234'},
> 'John':{'Age':'22', 'Dept':'0010', 'Ext':'5678'},
> 'Jeff':{'Age':'23', 'Dept':'0100', 'Ext':'9009'},
> 'Jody':{'Age':'24', 'Dept':'1000', 'Ext':'8765'},
> 'Jeny':{'Age':'25', 'Dept':'0110', 'Ext':'4321'}
> }
>
> You get it yet? You finally understand that preference SCREWS UP THE
> INTENT AND READABILITY OF THE ABOVE EXAMPLE WHICH IS NOT ALL THAT UNCOMMON?
> Yeesh. 3 days now and you still haven't address that real and valid concern!
This concern *has* been addressed, by suggesting the
above be written as
some_dict = {
'Jane':{'Age':'21', 'Dept':'0001', 'Ext':'1234'},
'John':{'Age':'22', 'Dept':'0010', 'Ext':'5678'},
'Jeff':{'Age':'23', 'Dept':'0100', 'Ext':'9009'},
'Jody':{'Age':'24', 'Dept':'1000', 'Ext':'8765'},
'Jeny':{'Age':'25', 'Dept':'0110', 'Ext':'4321'}
}
Also, there seems to be some confusion in this discussion
about two quite different kinds of formatting: Python
block-indentation on the one hand, and cosmetic lining-up
on the other. People arguing in favour of tabs are talking
only about the former, not the latter.
If you need to do cosmetic lining-up, the best thing is
to use whatever your current convention is for block
indentation up to the syntactic level of the statement,
and then use spaces-only after that. It still won't work
if viewed with a proportional font, but it's the best
that can be done using plain ASCII.
--
Greg Ewing, Computer Science Dept, University of Canterbury,
Christchurch, New Zealand
To get my email address, please visit my web page:
http://www.cosc.canterbury.ac.nz/~greg
Peoter Veliki
example below, however many tabs the first line has in front of it, each of
the other lines below must also have the same number of tabs and the use
spaces to finishing lining everything up. If you do this it will line up on
any editor.
"Greg Ewing" <gr...@cosc.canterbury.ac.nz> wrote in message
news:3C0C55A8...@cosc.canterbury.ac.nz...
> --
> http://mail.python.org/mailman/listinfo/python-list
>
Philip Swartzleonard
>
>
> On Mon, 3 Dec 2001, Steve Lamb wrote:
>
>> On 3 Dec 2001 23:17:22 GMT, Quinn Dunkan
>> <qu...@chunder.ugcs.caltech.edu> wrote:
>> > Not for me it doesn't, when I use proportional fonts.
>>
>> Anyone who uses proportional fonts for programming gets what they
>> deserve
>
> Less eye strain ?
> Fewer headaches ?
Switch fonts when it matters? Any reasonable macroable editor should
hopefully be scriptable for this... Xnews and Eudora each have a button to
toggle proportional/nonproportional mode so you can use whatever is
appropriate, that kind of thing would be nice. (I just use shift-mouse1 in
ntemacs, and pick what i feel like at the time :)
--
Philip Sw "Starweaver" [rasx] :: <nothing>
Courageous
>I like the width of 4 spaces also, BUT I use tabs and configured my editor
>to "DISPLAY" tabs as 4 characters in width.
In my experience, the vast majority of people who do this
inevitably end up mixing tabs and spaces. The moment you do
this, you have defacto chosen an tabwidth for your viewing
audience whether they like it or not.
C//
Erik de Castro Lopo
Actually, what the previous poster suggested will prevent problems.
If spaces should creep in Python won't compile the code.
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo nos...@mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
Q: What do you call a christian who accidently read the bible
with his brain turned on?
A: An atheist
Erik de Castro Lopo
>
> David Bolen wrote:
>
> > Erik de Castro Lopo <nos...@mega-nerd.com> writes:
> >
> > > You really ought to try using nothing but tabs for indentation and
> > > setting the tab width in your editor to whatever you prefer.
> > >
> > > This is so easy and works **SO** well.
> >
> > Always curious about this in an "all tab" world - how do you align
> > continuation lines that aren't on a tab stop?
>
> And even if you *do* so, then how are they going to stay aligned when the
> next person to look at it uses a different tab size?
If all the indentation is all tabs it really doesn't matter. The **ONLY**
problem is with mixed tabs and spaces and that should be caught as soon as
possible.
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo nos...@mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"He who writes the code gets to choose his license, and nobody
else gets to complain" -- Linus Torvalds
Erik de Castro Lopo
>
> On Mon, 03 Dec 2001 20:46:10 GMT, Erik de Castro Lopo <nos...@mega-nerd.com>
> wrote:
> > You really ought to try using nothing but tabs for indentation and setting
> > the tab width in your editor to whatever you prefer.
>
> > This is so easy and works **SO** well.
>
> Until you answer it here is the only reply you will get because I am tired
> of reiterating that it is NOT "style" and "preference".
>
> some_dict = {'Jane':{'Age':'21', 'Dept':'0001', 'Ext':'1234'},
> 'John':{'Age':'22', 'Dept':'0010', 'Ext':'5678'},
> 'Jeff':{'Age':'23', 'Dept':'0100', 'Ext':'9009'},
> 'Jody':{'Age':'24', 'Dept':'1000', 'Ext':'8765'},
> 'Jeny':{'Age':'25', 'Dept':'0110', 'Ext':'4321'}
> }
Easy. Tabs everywhere:
some_dict = {
'Jane':{'Age':'21', 'Dept':'0001', 'Ext':'1234'},
'John':{'Age':'22', 'Dept':'0010', 'Ext':'5678'},
'Jeff':{'Age':'23', 'Dept':'0100', 'Ext':'9009'},
'Jody':{'Age':'24', 'Dept':'1000', 'Ext':'8765'},
'Jeny':{'Age':'25', 'Dept':'0110', 'Ext':'4321'}
}
Beautiful!!!!
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo nos...@mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"I think there is a world market for maybe five computers."
-- Thomas Watson, Chairman of IBM, 1943
Paul Boddie
> On Mon, 03 Dec 2001 19:34:25 GMT, Erik de Castro Lopo <nos...@mega-nerd.com>
> wrote:
> > How hard is it to find an editor that treats tabs correctly and allows
> > the tab width to be set to something other than 8?
>
> not uncommon example of code which gets messed up when people are able to
> modify indention levels.
If you have a file which uses only "hard tabs" for indentation, and
someone then modifies their indentation level in an editor which
supports "hard tabs", and that person then uses "hard tabs" to indent
code in that file, then there isn't a problem.
If, on the other hand, someone loads the file into such an editor and
starts slapping the space bar to indent code, then you do have a
problem. One might ask who caused that problem but, for the sake of
objectivity, it's much better to discuss what kind of procedures you
have around the development of your code to prevent this from
happening.
Even if it does sound extreme, rejecting files with "hard tabs" in it
does constitute a solution, and there are ways that people can still
choose their indentation style within this framework. If you can't
handle such issues, yet have the time or inclination to flame others
about what you perceive to be the cause of such issues, then I suggest
you redirect your energy towards investigating those issues and
possible solutions more closely, if only because "tabs vs. spaces"
isn't the only pitfall you're going to encounter when dealing with
source code in a multi-developer environment.
Paul
Paul Boddie
> On Sun, 2 Dec 2001 20:13:37 -0600, Jeff Hinrichs <j...@home.com> wrote:
> > my 0.02$US:
> > Actually, spaces are the problems not tabs. A tab is a tab, where is
> > indenting by spaces....hmm.
>
> No, a tab isn't a tab.
It's hard to know what you're getting at here. Is this the ultimate
form of denial? :-)
The Tab key (or whatever symbol is used on your keyboard to denote it)
is commonly used to move the cursor to a particular location, whether
it be the next field in a form, or whether it be to a particular
horizontal position in a human-readable textual document. On my
keyboard, the symbol used is an arrow pointing to a vertical line
which indicates a well-defined location.
In neither of the two examples given above does use of the Tab key
correspond to any number of spaces - one doesn't move 8 spaces to the
next field in a form, nor does one set a tabstop in a word processor
to 4cm under the illusion that 4cm now means any particular number of
spaces.
> > You should be able to configure your editor to display tabs in a width that
> > is to your liking WITHOUT mucking with the data.
>
> As you just said, "You should be able to configure your editor to display
> tabs..." Oh, so a tab isn't a tab. I like indention of 4 so my tab is 4
> spaces. You like 8 so yours is 8 spaces. A tab is not a tab. A tab is a
> collection of spaces, visually.
A tab causes movement to the next defined horizontal position on the
current line. Text editors often define these positions at intervals
which are a number of spaces apart in the current font, but that does
not mean that they are in any way equivalent to spaces. Moreover,
depending on where the cursor is when the Tab key is pressed, the
horizontal movement can vary depending on the distance between the
current cursor position and the next tabstop.
> Now, if you had read my post you would have seen where your whole "a tab
> is a tab" bubbub breaks down. Here it is AGAIN since you missed it the first
> time.
>
> some_dict = {'Jane':{'Age':'21', 'Dept':'0001', 'Ext':'1234'},
> 'John':{'Age':'22', 'Dept':'0010', 'Ext':'5678'},
> 'Jeff':{'Age':'23', 'Dept':'0100', 'Ext':'9009'},
> 'Jody':{'Age':'24', 'Dept':'1000', 'Ext':'8765'},
> 'Jeny':{'Age':'25', 'Dept':'0110', 'Ext':'4321'}
> }
>
> With spaces that always comes out the same. With tabs set to different
> lengths you get different results. The only constant when it comes to
> indention is a space. A space is a space. A tab is not constant and
> therefore should NOT be used for indention. Ever.
Indentation isn't at all important with respect to the correct
interpretation of the above statement (which is the real issue here),
but I've long suspected that you don't have a real argument to bring
to the table.
> Indention isn't about preference, it is about making the code readable.
> And as the above example shows, readable code could be rendered unreadable by
> tab "preferences".
You're wasting your time making code "art" just as I could be wasting
my time explaining to you what a tab is. In short, we're both wasting
our time.
Paul
Steve Lamb
wrote:
> This concern *has* been addressed, by suggesting the
> above be written as
Which ignored the point as I stated it was a simplified example.
> Also, there seems to be some confusion in this discussion
> about two quite different kinds of formatting: Python
> block-indentation on the one hand, and cosmetic lining-up
> on the other. People arguing in favour of tabs are talking
> only about the former, not the latter.
No, there is no confusion. The tab people are ignoring that there is
formatting other than indention alone.
> If you need to do cosmetic lining-up, the best thing is
> to use whatever your current convention is for block
> indentation up to the syntactic level of the statement,
> and then use spaces-only after that. It still won't work
> if viewed with a proportional font, but it's the best
> that can be done using plain ASCII.
Mixing tabs and spaces? You just suggested mixing tabs and spaces. Thank
you for finally seeing reason and maybe now you'll understand why tabs are NOT
to be used.
Steve Lamb
wrote:
> Anything you want to line up must be at the same indent level. In the
> example below, however many tabs the first line has in front of it, each of
> the other lines below must also have the same number of tabs and the use
> spaces to finishing lining everything up. If you do this it will line up on
> any editor.
Uhhhh, no. I have my tabs set to 4, you have yours set to 8. There are
three tabs and two spaces before each line. In my editor that is 15 spaces.
Yours it will be 24. I would love to see your proof that 15=24, even for
large values of 15.
Steve Lamb
wrote:
> Easy. Tabs everywhere:
> some_dict = {
> 'Jane':{'Age':'21', 'Dept':'0001', 'Ext':'1234'},
> 'John':{'Age':'22', 'Dept':'0010', 'Ext':'5678'},
> 'Jeff':{'Age':'23', 'Dept':'0100', 'Ext':'9009'},
> 'Jody':{'Age':'24', 'Dept':'1000', 'Ext':'8765'},
> 'Jeny':{'Age':'25', 'Dept':'0110', 'Ext':'4321'}
> }
> Beautiful!!!!
fail and is so common as to prevent tabs from being ever used in code.
Steve Lamb
> Steve Lamb <gr...@despair.dmiyu.org> wrote in message news:<slrna0mh0...@teleute.dmiyu.org>...
>> On Sun, 2 Dec 2001 20:13:37 -0600, Jeff Hinrichs <j...@home.com> wrote:
>> > my 0.02$US:
>> > Actually, spaces are the problems not tabs. A tab is a tab, where is
>> > indenting by spaces....hmm.
>>
>> No, a tab isn't a tab.
> It's hard to know what you're getting at here. Is this the ultimate
> form of denial? :-)
Only because you're being willfully ignorant.
> The Tab key (or whatever symbol is used on your keyboard to denote it)
> is commonly used to move the cursor to a particular location, whether
> it be the next field in a form, or whether it be to a particular
> horizontal position in a human-readable textual document.
Neither of which applies. We are talking about a tab character inside a
piece of code and you know it.
>> With spaces that always comes out the same. With tabs set to different
>> lengths you get different results. The only constant when it comes to
>> indention is a space. A space is a space. A tab is not constant and
>> therefore should NOT be used for indention. Ever.
> Indentation isn't at all important with respect to the correct
> interpretation of the above statement (which is the real issue here),
> but I've long suspected that you don't have a real argument to bring
> to the table.
That is beacuse you are applying what a tab represents in two different
and unrelated fields to this one. When you stop being willfully ignorant
you'll see my argument is quite valid.
> You're wasting your time making code "art" just as I could be wasting
> my time explaining to you what a tab is. In short, we're both wasting
> our time.
Only one of us is, and that is me. I am well aware of what a tab is in
word processing. However, this isn't microsoft.public.applications.word (or
whatever it is). Nor is this comp.sys.database.sql.forms. This is
comp.lang.python. Your definitions of tab addressed human readable documents
and form entry. Neither of which have any application here.
Code is, first and foremost, a machine parsed document which also needs to
be somewhat human readable. In that context tab takes on a whole different
meaning. Doubly so in Python since indention matters.
When you get on the same page as the rest of us my argument will make
sense. Until then might I suggest returning to to the word processing and
form entry newsgroups as maybe discussing a programming language is beyond
your limited experience. OR... are you going to admit that you were
purposely misrepresenting what you fully knew what a tab represented in this
context just to get a rise out of me?
Courageous
>If spaces should creep in Python won't compile the code.
Spaces almost *have* to creep in, for example, on continuation
lines. Furthermore, what you're saying isn't true. For example,
if the person who writes it himself uses a tabstop of 8 and then
allows spaces to creep in, things will tend to work out.
All of this, however, is academic. The defacto indentation
standard for Python is 4 spaces.
If you run into Python projects managed professionally, you're
likely to find that their dejure standards are 4 spaces as well,
and with these, you'll find that in order to not get their tech
leads really pissed at you, you'll be learning what a soft tab
stop is, and setting it to 4.
C//
Steve Lamb
> If you have a file which uses only "hard tabs" for indentation, and
> someone then modifies their indentation level in an editor which
> supports "hard tabs", and that person then uses "hard tabs" to indent
> code in that file, then there isn't a problem.
Yes, there is. Hard tabbers, like you, forget that not all indention,
even for the most stout hard tabber will always be tabs. If you haven't
figured that out yet, you haven't been coding long enough.
> If, on the other hand, someone loads the file into such an editor and
> starts slapping the space bar to indent code, then you do have a
> problem.
No, I don't. Because when the file is saved all indention is in spaces.
Never a tab shall be written out, period. In that manner there are no
problems.
Furthermore I am not flaming people who use hard tabs. I am upset at
people who are arguing for hard tabs who, for three days, blatently ignored a
simple example which blew their argument out of the water. I am further upset
by blundering nits who waltz into the discussion, throw out what a tab means
in two entirely unrelated contexts, and then things he's the flippin' mossiah!
Chris Spencer
In my development group, we had people who used spaces while coding
Python, and we had people using tabs. What we noticed was that in terms of
uniformity of look, the "spacers" inevitably always chose different amounts of
spaces for indentation (one used 2 spaces, another used 3). In terms of
maintainability it was a nightmare. And it looks damned ugly.
When we standardized on the "tabber" method, everything just magically
lined up in the editor. The spacers defined their tabs to be 2 or 3 spaces in
width so it was comfortable to look at (I choose 8 spaces of width), but all of
the code looked the SAME instead of the crazy mixture we had before.
Maybe if you only code for yourself you can have total uniformity of
coding style amongst all of your projects. When you're dealing with several
people on a development project, that "tabber" convention is absolutely "the
Right Thing(tm)".
Chris.
Steve Lamb
> How many times do people have to point out that you're wrong?
2000 people rallying to the wrong point does not magicaly transform it
into a right.
> When we standardized on the "tabber" method, everything just magically
>lined up in the editor. The spacers defined their tabs to be 2 or 3 spaces
>in width so it was comfortable to look at (I choose 8 spaces of width), but
>all of the code looked the SAME instead of the crazy mixture we had before.
Which would have happened if you standardized on a number of spaces for
indentation.
> Maybe if you only code for yourself you can have total uniformity of
> coding style amongst all of your projects. When you're dealing with several
> people on a development project, that "tabber" convention is absolutely "the
> Right Thing(tm)".
Except in the example, which is not uncommon. In fact a tabber in this
very thread promoted mixing tabs and spaces in response to it!
Tabs are the worst possible thing and no large number of people rallying
behind it will change it to a right. All it proves is that like any other
foolish notion you can fool quite a few people into believing it.
The difference is while all the tabbers are whining on the side of
"preference" I'm pointing out very real logistical problems which has nothing
to do with preference. Preference takes a back seat. When you stop ignoring
that you'll come to understand the problem.
Erik de Castro Lopo
>
> On Tue, 04 Dec 2001 08:25:23 GMT, Erik de Castro Lopo <nos...@mega-nerd.com>
> wrote:
> > Easy. Tabs everywhere:
>
> > some_dict = {
> > 'Jane':{'Age':'21', 'Dept':'0001', 'Ext':'1234'},
> > 'John':{'Age':'22', 'Dept':'0010', 'Ext':'5678'},
> > 'Jeff':{'Age':'23', 'Dept':'0100', 'Ext':'9009'},
> > 'Jody':{'Age':'24', 'Dept':'1000', 'Ext':'8765'},
> > 'Jeny':{'Age':'25', 'Dept':'0110', 'Ext':'4321'}
> > }
>
> > Beautiful!!!!
>
> Uh, no, rather nasty in fact. Face it, that's the one case where tabs
> fail and is so common as to prevent tabs from being ever used in code.
Please explian to us rational people why that is nasty.
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo nos...@mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
Perl : executable line noise
Python: executable pseudo-code
Chris Spencer
>On 4 Dec 2001 11:48:17 -0600, Chris Spencer <clsp...@one.net> wrote:
>> When we standardized on the "tabber" method, everything just magically
>>lined up in the editor. The spacers defined their tabs to be 2 or 3 spaces
>>in width so it was comfortable to look at (I choose 8 spaces of width), but
>>all of the code looked the SAME instead of the crazy mixture we had before.
>
> Which would have happened if you standardized on a number of spaces for
>indentation.
Some people don't WANT to look at 8 spaces for an indent. Or 2 or 3.
With the tab convention, you can set your tab width to be whatever you want, so
people who like looking at 8 space widths can do that, and people who like 2
space widths can do that too.
The point you seem to miss is that not everyone has the same ideas or
comfort levels with different indentation conventions. With tabbing, you don't
have to worry about it. Just set it to whatever you like.
>> Maybe if you only code for yourself you can have total uniformity of
>> coding style amongst all of your projects. When you're dealing with several
>> people on a development project, that "tabber" convention is absolutely "the
>> Right Thing(tm)".
>
> Except in the example, which is not uncommon. In fact a tabber in this
>very thread promoted mixing tabs and spaces in response to it!
I'm not him. And I don't agree with the example in question. I manage
quite nicely to format data structures without resorting to spaces.
> Tabs are the worst possible thing and no large number of people rallying
>behind it will change it to a right. All it proves is that like any other
>foolish notion you can fool quite a few people into believing it.
This is a straw man argument. Like "so, have you beaten your wife
lately?" I refuse to get into a competition involving name calling.
Tabs work for me and for my development group. They don't work for you.
Guess what, we both can do our own thing. The only difference between us is
that you want to force me to your way of thinking. I simply don't care what you
think. You can use spaces to your heart's content and I won't mind. I'm not
the one forcing others to abide by my way of thinking. Such totalitarian edicts
will only serve to drive people away from Python.
I think you've got way too much of your ego involved in this debate.
>
> The difference is while all the tabbers are whining on the side of
>"preference" I'm pointing out very real logistical problems which has nothing
>to do with preference. Preference takes a back seat. When you stop ignoring
>that you'll come to understand the problem.
>
I see, preference doesn't matter as long as the convention matches YOUR
preference. To hell with everyone else, right?
Just because you like to work a certain way does not mean that you have
become God and will decree that your *preference* is the only way to do things.
Step back from your ego.
Chris.
Steve Lamb
> Some people don't WANT to look at 8 spaces for an indent. Or 2 or 3.
And?
> With the tab convention, you can set your tab width to be whatever you want, so
> people who like looking at 8 space widths can do that, and people who like 2
> space widths can do that too.
Which breaks when the code is read elsewhere, C&P elsewhere, etc. Not
that you've addressed that at all.
> The point you seem to miss is that not everyone has the same ideas or
> comfort levels with different indentation conventions. With tabbing, you don't
> have to worry about it. Just set it to whatever you like.
And the point you've missed is that when people can set it to whatever
they like it destroys any consistancy and readability everywhere else but
their term anyway.
> Tabs work for me and for my development group. They don't work for you.
> Guess what, we both can do our own thing.
No, we cannot. For the first time we try to use anything from your end of
the spectrum it all goes to crap.
> I see, preference doesn't matter as long as the convention matches YOUR
> preference. To hell with everyone else, right?
No. In fact if the conventioned doesn't conform to my preference it is
convention that matters. That might just be why Python is the only language
that I program in where I set the indent level to 4 spaces instead of my
normal preference of *2*. IE, bucko, the convention doesn't match my
preference.
Point is that tabbers keep saying that one can separate style from content
where the spacers keep pointing RIGHTLY SO that there is no separation when it
comes certain code constructs. What's the tabber answer to that "Well, uh, I
never have a problem." Nice comeback.
> Just because you like to work a certain way does not mean that you have
> become God and will decree that your *preference* is the only way to do things.
> Step back from your ego.
It isn't my *preference*. Furthermore I am giving valid reasons why it
FAILS. I'm not stating "Well, it should be this way because I like it." No,
it is "It should be this way because in this case, this case and this case
which are not uncommon it fails." The former is a subjective argument and
baseless. The latter is an objective argument which stands up to reason.
Now, are you going to address those problems or continue to scream about
your *preferences* working in cases where they clearly do not?
Tim Peters
> Please explian to us rational people why that is nasty.
I've lost track, but I'm pretty sure it was either because the example used
tabs, or because it used spaces.
moving-the-argument-along-to-its-compelling-conclusion-ly y'rs - tim
Cliff Wells
> I've lost track, but I'm pretty sure it was either because the example
> used tabs, or because it used spaces.
After reading this entire thread, I think there are valid arguments on
both sides, so I'll be avoiding both tabs and spaces in all my code.
--
Cliff Wells
Software Engineer
Logiplex Corporation (www.logiplex.net)
(503) 978-6726 x308
(800) 735-0555 x308
Ben Wolfson
> After reading this entire thread, I think there are valid arguments on
> both sides, so I'll be avoiding both tabs and spaces in all my code.
I understand several successful Perl and C programs are written that way.
--
BTR
Why does this Wolfson person see fit to clutter up Usenet with such
absurd nonsense?
-- Bob Cunningham in <km4butor1ke8f5et2...@4ax.com>
David Bolen
> On Tue, 04 Dec 2001 19:47:59 -0600, Cliff Wells wrote:
>
> > After reading this entire thread, I think there are valid arguments on
> > both sides, so I'll be avoiding both tabs and spaces in all my code.
>
> I understand several successful Perl and C programs are written that way.
Some even consider it an art form.
--
-- David
--
/-----------------------------------------------------------------------\
\ David Bolen \ E-mail: db...@fitlinxx.com /
| FitLinxx, Inc. \ Phone: (203) 708-5192 |
/ 860 Canal Street, Stamford, CT 06902 \ Fax: (203) 316-5150 \
\-----------------------------------------------------------------------/
Greg Ewing
>
> Mixing tabs and spaces? You just suggested mixing tabs and spaces.
No, I didn't -- not for block indentation, which
is where it matters.
> Thank you for finally seeing reason and maybe now you'll
> understand why tabs are NOT to be used.
If it's all the same to you, I think I'll continue to
use tabs for indentation and spaces for cosmetics
on the Mac, which works perfectly well with the editors
I use there, even though I should apparently be
"understanding" that it won't. :-)
Gerhard Häring
> On Tuesday 04 December 2001 16:58, Tim Peters wrote:
>
> > I've lost track, but I'm pretty sure it was either because the example
> > used tabs, or because it used spaces.
>
> both sides, so I'll be avoiding both tabs and spaces in all my code.
<?xml version="1.0"?>
<!-- fancy doctype declaration here -->
<module name="mypkg.mymodule">
<class name="MyClass" inherits="OtherClass">
<method name="__init__">
<method-params>
<method-param name="self"/>
<method-param name="foo" default="None"/>
</method-params>
<method-body>
<global name="tabVsSpacesFlamewarHappening">
<while-loop>
<while-loop-condition>
<value="1"/>
</while-loop-condition>
<while-loop-body>
<pass/>
</while-loop-body>
</while-loop>
</method-body>
</class>
</python-module>
Better? Seperatation of representation and semantics? The obvious
disadvantage of an XML representation of sourc code would be that we
would need *really good* editors to make it not painful.
Gerhard
--
mail: gerhard <at> bigfoot <dot> de registered Linux user #64239
web: http://www.cs.fhm.edu/~ifw00065/ OpenPGP public key id 86AB43C0
public key fingerprint: DEC1 1D02 5743 1159 CD20 A4B6 7B22 6575 86AB 43C0
reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))
Max M
has never stopped me from speaking out before ...
I find that the only thing that really annoys me whit tabs instead of
spaces, is the mess I get when I email somebody a piece of code, and the
mail software automatically wraps it at 76 characters.
Then tabs both makes it harder to correct the code again, and it also makes
the linewrapping more "random".
regards Max M
Paul Boddie
> On 4 Dec 2001 02:39:19 -0800, Paul Boddie <pa...@boddie.net> wrote:
> > If you have a file which uses only "hard tabs" for indentation, and
> > someone then modifies their indentation level in an editor which
> > supports "hard tabs", and that person then uses "hard tabs" to indent
> > code in that file, then there isn't a problem.
>
> Yes, there is. Hard tabbers, like you, forget that not all indention,
> even for the most stout hard tabber will always be tabs. If you haven't
> figured that out yet, you haven't been coding long enough.
My use of the word "if" did have some bearing on the meaning of the
paragraph you quoted above, but I see that you find it much more
exciting or fun to bring the debate to the level of a semi-religious
argument.
> > If, on the other hand, someone loads the file into such an editor and
> > starts slapping the space bar to indent code, then you do have a
> > problem.
>
> No, I don't. Because when the file is saved all indention is in spaces.
> Never a tab shall be written out, period. In that manner there are no
> problems.
And my use of "such an editor" also has an influence on the meaning of
that paragraph, but I see that you aren't willing to consider
situations other than your own. Therefore any discussion on this
matter with you is fairly pointless.
> Furthermore I am not flaming people who use hard tabs. I am upset at
> people who are arguing for hard tabs who, for three days, blatently ignored a
> simple example which blew their argument out of the water. I am further upset
> by blundering nits who waltz into the discussion, throw out what a tab means
> in two entirely unrelated contexts, and then things he's the flippin' mossiah!
Your oh-so-powerful argument was based on "nice" formatting of some
code whose interpretation by the Python runtime was pretty much
independent of its indentation. I'm not claiming to know what a tab
means to all people, but it seems fairly obvious to me that you
consider the definitive tab reference to be whatever tools you use - I
was just pointing out that the definition of a tab has wider
significance, and I hardly think that word processing is "entirely
unrelated" to text editing.
Paul
Paul Boddie
> OR... are you going to admit that you were
> purposely misrepresenting what you fully knew what a tab represented in this
> context just to get a rise out of me?
Yes. I hope you enjoyed it as much as I did. :-)
Paul
P.S. Actually, I'm much more serious about the whole indentation thing
in other forums, but you wading into this debate as you did really
invited some irreverence.
Paul Boddie
> >If spaces should creep in Python won't compile the code.
>
> Spaces almost *have* to creep in, for example, on continuation
> lines. Furthermore, what you're saying isn't true. For example,
> if the person who writes it himself uses a tabstop of 8 and then
> allows spaces to creep in, things will tend to work out.
Can you give an example of how spaces must creep in on continuation
lines? Sorry, I know I should really have followed up by saying, "You
don't understand!!! You're so wrong!" But I'm interested in how other
people write their code - contrary to apparent popular belief.
> All of this, however, is academic. The defacto indentation
> standard for Python is 4 spaces.
>
> If you run into Python projects managed professionally, you're
> likely to find that their dejure standards are 4 spaces as well,
> and with these, you'll find that in order to not get their tech
> leads really pissed at you, you'll be learning what a soft tab
> stop is, and setting it to 4.
Many of us haven't been lucky enough to encounter commercial Python
projects, but if that's what you mean by "professional" then I'll take
your word for it. I am aware that there's a lot of hostility to tab
usage in various open source projects, but that's really a consequence
of the tools around on many platforms today. I suppose that most
people just go along with whatever has been decided, though, and
that's why the tab/space handling tools need a lot more blatant
publicity - a best practice section on python.org would be nice...
Paul
Robin Becker
Boddie <pa...@boddie.net> writes
>Steve Lamb <gr...@despair.dmiyu.org> wrote in message news:<slrna0prl7.kjs.grey@t
>eleute.dmiyu.org>...
>> OR... are you going to admit that you were
>> purposely misrepresenting what you fully knew what a tab represented in this
>> context just to get a rise out of me?
>
>Yes. I hope you enjoyed it as much as I did. :-)
>
>Paul
>
>P.S. Actually, I'm much more serious about the whole indentation thing
>in other forums, but you wading into this debate as you did really
>invited some irreverence.
The reason why these 'simple' threads get so much attention and heat is
that the majority of people can understand the issues. The board of
directors passes the £multi-million factory rebuild in ten minutes, but
spends an hour worrying about the workers' bike shed.
This and emac vs vi are among the most interesting issues :)
--
Robin Becker
Paul Winkler
>Were does it say so? I've been programming Python with mixed spaces/tabs
>since 1.3. Works like a charm. Just never forget to install python-mode.el ;)
Which means the editor is replacing each tab level with 4 spaces,
so there are no tabs in your code. Works for me too.
--PW
Courageous
>Can you give an example of how spaces must creep in on continuation
>lines?
##--snip; not in particular the column-positioning of the "or". If
## tabs are used here, it will be misaligned with other
## tabstop stettings for certain
if isinstance(f, future.Step) or \
isinstance(f, future.Status) or \
isinstance(f, future.Announce) or \
isinstance(f, possibility.Observe) or \
isinstance(f, future.Incarnate) or \
isinstance(f, future.Start) or \
isinstance(f, future.Timeout):
##--snip; in this case, the continuation line is lined up on the
## string boundary to create some congruity between the code
## and the message produced
log.Fatal("Unexpected RETURN intercepted from user code.\n"
"This is almost certainly due to an inappropriate explicit\n"
"or implicit use of return in an Task. HINT: Make sure\n"
"to use Fail(), End(), or Succeed() to terminate a Task,\n"
"The most suspicious task is probably this one:\n\n"+lastFuture.String())
##--snip; here, like the or, the actions are put into a column.
## simple actions, organized like this are both compact and
## readable.
if methodname==self.task.name: methodname="-"
else: methodname=methodname[0:20]+"()"
if self.task.status: stat=status.strings[self.task.status]
else: stat="UNKNOWN"
if self.absoluteT == simulator.ticks: when="now"
else: when="future"
> am aware that there's a lot of hostility to tab
>usage in various open source projects, but that's really a consequence
>of the tools around on many platforms today.
I don't think so. Even word will get fucked up if someone tweaks
the positioning of the tabs in the ruler. The reason this problem
doesn't make itself more evident is that the document carries its
tabstops with it.
You can do this in vim at the beginning of the document, by the way.
E.g.,
##------------------------------------------------------------------------------
## $Id: resource.py,v 1.1 2001/12/05 00:44:27 jkraska Exp $
## vim: ts=8
##------------------------------------------------------------------------------
C//
Courageous
>>Works like a charm. Just never forget to install python-mode.el ;)
>Which means the editor is replacing each tab level with 4 spaces,
>so there are no tabs in your code. Works for me too.
For vim users:
set softtabstop=4
set shiftwidth=4
set et
set showmatch
set matchtime=1
"ascii-183==·
"ascii-187==»
set lcs=tab:»\
set list
The lcs=tab: line should be typed like this:
set lcs=tab:<ctrl-V>187\
Note that the normal tabstop is left alone at 8. This gives the python
writer using vim the following:
Each time you press tab, it moves you to the closest tabstop of 4 by
inserting just enough spaces to get you there. When hard tabs are
present, they align on an 8 character boundary and appear with the
ascii character 187 (the "small double greater than character"). This
makes tabs show up like a sore thumb, which is important in Python.
You'll likewise find it helpful for MAKE.
Note that since you are getting spaces every time you type tab, when
using make and occasionally other systems you'll eventually need a
REAL tab. You get this by typing <ctrl-v>TAB.
It took me a while to figure out (with the helpful advice of someone
here or in the editors group) to use 8 character stops for real tabs.
But it really is the way to go, particularly if you are on a unix
system, where any variety of programs (lpr, cat, more, et al) will
treat your tabstops as 8 characters by default.
Note that Python treats your tabstops as 8 characters by default, so
this will always make DEDENT syntax errors obvious as well.
C//
Bjorn Pettersen
> >Can you give an example of how spaces must creep in on continuation
> >lines?
>
> ##--snip; not in particular the column-positioning of the "or". If
> ## tabs are used here, it will be misaligned with other
> ## tabstop stettings for certain
>
> if isinstance(f, future.Step) or \
> isinstance(f, future.Status) or \
> isinstance(f, future.Announce) or \
> isinstance(f, possibility.Observe) or \
> isinstance(f, future.Incarnate) or \
> isinstance(f, future.Start) or \
> isinstance(f, future.Timeout):
Ack, so much typing :-)
klasses = [future.Step, future.Status, ...]
if filter(lambda x: isinstance(f,x), klasses):
> ##--snip; in this case, the continuation line is lined up on the
> ## string boundary to create some congruity between the code
> ## and the message produced
>
> log.Fatal("Unexpected RETURN intercepted from user code.\n"
> "This is almost certainly due to an
> inappropriate explicit\n"
> "or implicit use of return in an Task. HINT:
> Make sure\n"
> "to use Fail(), End(), or Succeed() to
> terminate a Task,\n"
> "The most suspicious task is probably this
> one:\n\n"+lastFuture.String())
Ugly...
txt = """
Unexpected RETURN intercepted from user code.
This is almost certainly due to an inappropriate
explicit...
"""
log.Fatal(txt)
> ##--snip; here, like the or, the actions are put into a column.
> ## simple actions, organized like this are both compact and
> ## readable.
>
> if methodname==self.task.name: methodname="-"
> else:
> methodname=methodname[0:20]+"()"
>
> if self.task.status:
> stat=status.strings[self.task.status]
> else: stat="UNKNOWN"
>
> if self.absoluteT == simulator.ticks: when="now"
> else: when="future"
If anyone writes code like that on any of our projects they'll be shot
<wink>. When one of the if tests change it usually causes a cascading
re-indent of the second column.
We use tabs exlusively for all our projects, and in practice there is
never a problem getting things to line up (I guess as with the
"whitespace-for-indentation" issue you'll have to try it before you
believe it).
-- bjorn
Ken Seehof
fact there's probably enough material for a book or two: "A Concise History
of Tab Usage", or "Professional Tabulation and Indentation Strategies for
Python Programmers", or maybe "Tab Usage for Complete Idiots".
I am promoting some new legislation that is currently being considered in
Congress. The new law will require that all programming languages must
treat the tab character as a syntax error by June 2004. Some details have
not yet been resolved, such as whether or not to permanently remove tab from
the new ASCII standard (this would have the side effect of decrementing the
ordinal values of all characters after 9). It is estimated that this will
save the computer industry several billion dollars worth of programming time
every year. Most of the savings are expected to be due to decreased
newsgroup volume on tab related topics.
For example, it is estimated that the total time spent by everyone on this
newsgroup reading this message is approximately 182 hours and 27 minutes
that could have been spent programming, or $21,894.00. When you take into
consideration all programming languages that permit hard tabs, there are
thousands of useless messages just like this one every week!
Ken Seehof
kse...@neuralintegrator.com
www.neuralintegrator.com
Cliff Wells
I don't even know what to think of this, but since you obviously put some
time into writing it I felt compelled to reply.
Huaiyu Zhu
On Mon, 03 Dec 2001 20:51:34 GMT, Erik de Castro Lopo <nos...@mega-nerd.com>
wrote:
>
>However, the people who like me prefer using tabs (and nothing but tabs) for
>indentation need to speak up.
It appears that both sides have already spoken enough and the issue is quite
clear. So I have been wondering why it continues like a religious war.
It occurred to me that the reason might be that there are two different kinds
of editor behaviors concerning tab, and that users of one kind of editor do
not really understand what the other side is talking about. I'll call these
editor styles the tab-character editor and the tab-display editor.
When a tab key is hit, the tab-character editor enters the ascii tab
character in the file. It also displays the character in a way that is
often configurable. The character is persistent (saving to file, sending to
someone else) and meaningful to Python, while the display is only effective
in the particular editor session. The display usually takes the size of a
given number of spaces, but it really behaves like a single character to the
arrow keys, delete and backspace keys and to cut and paste.
In contrast, when a tab key is hit, the tab-display editor would translate
that into a sequence of other characters, usually a given number of spaces,
that produces the same display effect. This display effect is persistent on
file and effective for Python. The fact that they were entered using the
tab key is not recorded anywhere, probably not even in the current editing
session. For example, the arrow keys will not move over tab as a single
character, and the delete key need to be hit more than once to delete it.
Many editors can be configured to behave either way (some even do additional
magic with the tab key). But there might be crippled editors that only
allow one style. That might be what's behind the claims that "it is not a
matter of personal preference" and "you can not separate style from
content".
So I'd suggest the tab advocates to consider the other side's view. What if
their editors never allow this to be a _personal_ preference? What if any
display setting would leak to other programmers? I have limited experience
with MS native editors. So I'm not sure if this is the case. If it is
indeed the case, it can well explain why they do not see there being a
choice, let alone to consider which choice is better.
So we talk about the distinction between logical and visual formats, about
tab the character and tab the position. But if the editor never allowed
such distinctions, none of these make much sense, and the tab-as-indent
argument might just sound as rhetoric to them. To users of such editors,
"indent" always means visual indent; the Python block structure is only a
secondary effect.
The all-tab model we are talking about is like this (scheme A)
A's editor file exchange B's editor
visual <---------- tab <-----------------> tab -----------> visual
| |
python | | python
V V
indent indent
But many of the arguments against it lead me to believe that non-tabbers
think we are talking about something like this (scheme B)
A's editor file exchange B's editor
tab <----------> space <-----------------> space <----------> tab
| |
python | | python
V V
indent indent
while their preferred one is (scheme C)
A's editor file exchange B's editor
tab <----------> space <-----------------> space <----------> tab
| |
python | | python
V V
indent indent
If the only practical choice is between scheme B and scheme C, it is quite
understandable why C is preferred to B. Indeed, in that case, there is very
little advantage in using tab at all.
If indeed one side is debating between A and C while the other side is
debating between B and C, and they thought they are in the same debate, that
could explain why the debate continues.
So my question is this: Is it true that for some people there is never a
choice between all-tab and all-space, only a choice between mix-tab-space
and all-space?
If this so, whatever the merits of all-tab, the final result of the debate
might just be dictated by the simple fact "scheme A is not available as a
practical choice for some users because of the editors they use".
Huaiyu
PS. Space is better for visual formating, such as lining up multiline (), []
and {}, but these are not syntactical indentation concerning Python. I did
not use tab for the above diagrams as it is visual formating.
Bernhard Herzog
Not necessarily. For one, this is of course configurable, but even more
important because Adreas started with Python 1.3, it wasn't always the
default setting. When I started to use python-mode (around Python 1.4)
mixed tab/space indentation was default.
Bernhard
--
Intevation GmbH http://intevation.de/
Sketch http://sketch.sourceforge.net/
MapIt! http://mapit.de/
Greg Ewing
>
> So I'd suggest the tab advocates to consider the other side's view.
And vice versa as well. To give one concrete example,
BBEdit on the Mac is very definitely what Huaiyu
calls a "tab-character" editor, both in what happens
when you press the tab key, and in the way its
block-shifting commands work.
If Python were ever to mandate space-only indenting,
I would be very disappointed, since it would effectively
make it impossible to use BBEdit to write Python code.
I also recognise that mandating tab-only indentation
would cause equal distress to those with editors of
the other kind. So, as far as I can see, both styles
need to be allowed.
I understand that problems occur if you take a file
produced using one kind of editor and directly edit
it with an editor of the other kind. But this seems
to be unavoidable giving the existence of these two
mutually incompatible editing regimes, or communities,
or whatever you want to call them.
Mandating one style of indentation doesn't solve this
problem, it only shuts out half of the community.
And I don't think that would be a nice thing to do.
In summary, my positions on the various issues are:
* Space-only block indentation should be allowed.
* Tab-only block indentation should be allowed.
* Mixed indentation should probably be rejected always,
or at least by default, although I can live with having
to say -tt.
* Python shouldn't care about spacing used for purposes
other than block indentation, although pragmatically
it's best done with spaces only.
* People in both camps should get used to the idea of
using conversion tools to deal with each other's code
and stop hating each other, or George Bush may target
you next after Afghanistan. :-)
Greg Ewing
>
> > From: Courageous [mailto:jkr...@san.rr.com]
> >
> > if isinstance(f, future.Step) or \
> > isinstance(f, future.Status) or \
> > isinstance(f, future.Announce) or \
> > isinstance(f, possibility.Observe) or \
> > isinstance(f, future.Incarnate) or \
> > isinstance(f, future.Start) or \
> > isinstance(f, future.Timeout):
>
> Ack, so much typing :-)
How about
class ClassesOfInterest(future.Step, future.Status, future.Announce,
possibility.Observe, future.Incarnate, future.Start,
future.Timeout):
pass
if isinstance(f, ClassesOfInterest):
...
Courageous
>> if isinstance(f, future.Step) or \
>> isinstance(f, future.Status) or ...
>klasses = [future.Step, future.Status, ...]
>if filter(lambda x: isinstance(f,x), klasses):
You're really very annoying. I consider your answer a
dodge, in part because you completely avoided the subject
which was being addressed, and also in part because you
just completely changed the peformance characteristics of
what you replaced for the worst. Surely you're aware that
probabilistic arrangement of conditional tests will enhance
performance, right?
But irrelevant, in any case. You just changed the subject.
>Ugly...
>
> txt = """
> Unexpected RETURN intercepted from user code.
> This is almost certainly due to an inappropriate
> explicit...
> """
Uglier in a color hilighting editor, especially considering
that you just changed the content of the string that I wrote.
This particular answer of yours suggests to me that your
practical programming background is extremely shallow. What
you just proposed is that the content of each string VARY
based on the indentation level at which it is designed. Surely
thou jesteth.
> When one of the if tests change it usually causes a cascading
>re-indent of the second column.
Only if you have a sucky editor.
>We use tabs exlusively for all our projects, and in practice there is
>never a problem getting things to line up (I guess as with the
>"whitespace-for-indentation" issue you'll have to try it before you
>believe it).
I don't believe it because I've tried it. Extensively. Over a period
of most of a decade.
C//
Carel Fellinger
> It appears that both sides have already spoken enough and the issue is quite
> clear. So I have been wondering why it continues like a religious war.
Nice someone still tries to get this discussion to halt:)
> It occurred to me that the reason might be that there are two different kinds
> of editor behaviors concerning tab, and that users of one kind of editor do
> not really understand what the other side is talking about. I'll call these
> editor styles the tab-character editor and the tab-display editor.
And a nice try, but...
...in the tab-character editor argument
> in the particular editor session. The display usually takes the size of a
> given number of spaces, but it really behaves like a single character to the
> arrow keys, delete and backspace keys and to cut and paste.
alas, cut&past on an X display will not see those tabs, but only the
spaces used to represent them at the moment:(
...and in the tab-display editor argument
> session. For example, the arrow keys will not move over tab as a single
> character, and the delete key need to be hit more than once to delete it.
fortunately some editors are smart enough to recognize an indentation
and allow single delete's to delete one indentation level worth of
spaces. And using the cursor keys is frowned upon by those using word
or sentence jumping keys:)
...
> So I'd suggest the tab advocates to consider the other side's view. What if
> their editors never allow this to be a _personal_ preference? What if any
it's not only the editor, but actually the whole environment they work in.
...nice scheme's snipped
> So my question is this: Is it true that for some people there is never a
> choice between all-tab and all-space, only a choice between mix-tab-space
> and all-space?
yep, for all of us that use X's crippled cut&paste
> If this so, whatever the merits of all-tab, the final result of the debate
> might just be dictated by the simple fact "scheme A is not available as a
> practical choice for some users because of the editors they use".
So because of X's limited cut and paste capabilities the whole
discussion is over, and we finally agree that tabs are out:)
> PS. Space is better for visual formating, such as lining up multiline (), []
> and {}, but these are not syntactical indentation concerning Python. I did
> not use tab for the above diagrams as it is visual formating.
PS. I once worked on a system where all leading spaces and tabs were
replaced by a single byte denoting the total number of leading spaces
by the file system it self. Okee, make didn't work there, but apart
from that the system was a nice and refreshing experience back then.
--
groetjes, carel
William Park
> In summary, my positions on the various issues are:
> * Space-only block indentation should be allowed.
> * Tab-only block indentation should be allowed.
> * Mixed indentation should probably be rejected always,
> or at least by default, although I can live with having
> to say -tt.
> * Python shouldn't care about spacing used for purposes
> other than block indentation, although pragmatically
> it's best done with spaces only.
> * People in both camps should get used to the idea of
> using conversion tools to deal with each other's code
> and stop hating each other, or George Bush may target
> you next after Afghanistan. :-)
One solution that has been proposed long ago (and many time since) is
end-block keywords like shell.
--
William Park, Open Geometry Consulting, <openge...@yahoo.ca>.
8 CPU cluster, NAS, (Slackware) Linux, Python, LaTeX, Vim, Mutt, Tin