Re: Tabs versus Spaces in Source Code

[Oliver Wong]

"Jonathon McKitrick" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> Pascal Bourguignon wrote:
>> (defun ιοτα (&key (номер 10) (단계 1) (בכוכ 0))
>>   (loop :for i :from בכוכ :to номер :by 단계 :collect i))
>
> How do you even *enter* these characters?  My browser seems to trap all
> the special character combinations, and I *know* you don't mean
> selecting from a character palette.
>
> ࿿ hey, this is weird...
>
> î
>
> I've got something happening, but I can't tell what.
>
> Yes, I'm an ignorant Western world ASCII user.  :-)

What OS are you using? In Windows XP, you'd have to let the XP know that 
you're interested in input in languages other than English via "Control 
Panel -> Regional Settings -> Languages -> Text Services and Input 
Languages". There, you'd add input methods other than English. Each "input 
method" works in a sort of unique way, so you'll just have to learn them. 
For example, under English, you can use the "keyboard" input method which 
probably is what you're using now, or the "handwriting recognition" input 
method, or the "speech recognition" input method to insert english text. 
There are other input methods for the Asian languages (e.g. Chinese, 
Japanese, etc.)

- Oliver 

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code

[Mumia W.]

owever, it is less of a problem to convert tabs to spaces, because the
> frequency of spaces appearing in literal strings are far higher than
> literal tabs.
> 
> Another practical issue is error recovery. Suppose, one uses 4 spaces
> for a indentation. Now, it is not uncommon to see lines with odd number
> of space prefixes such as 7 or 10 out of common sloppiness. Such error
> would happen more often if spaces are used for indentation, and the
> essence is that tabs enforce a semantic association and is impossible
> to make a half-indentation.
> 

What I've learned is that, if I'm going to use tabs for indentation, I 
have to be consistent.

> Q: Well, i just like spaces because they are most compatible.
> 
> A: Sure, crass simplicity is always more compatible. Suppose a unixer
> will say, he doesn't like HTML because it is fret with problems and
> incompatibilities. He'd rather prefer plain text. And, indeed, a lot
> unixers seriously think that.
> 
> ---
> PS in the answer to the first question, i gave the following examples
> of IDE/Language that actually embed formatting info in the source code:
> Borland Delphi, Metrowerks's CodeWarrior, Microsoft Visual Studio,
> Wolfram Research's Mathematica
> 

Perl's POD and Java's javadoc do it too.

> actually, i know Mathematica does, but i'm not quite sure about the
> other examples. So, my question is, does any one knows a language or
> IDE that actually allows the coder to manually highlight parts of the
> code and this highlight stick with the file upon reopening, as if a
> word processor?
> 
>Xah
>[EMAIL PROTECTED]
>  ∑ http://xahlee.org/
> 
> Xah Lee wrote:
>> Tabs versus Spaces in Source Code
>> This post is archived at:
>> http://xahlee.org/UnixResource_dir/writ/tabs_vs_spaces.html
> 

I'm slowly moving into the "spaces" camp. After reading your earlier 
post on tabs vs. spaces and other people's responses, I began thinking 
about why I like tabs so much, and there is only one answer--backspace.

If I use tabs, when I backspace I go back to the previous tab position, 
which is what I want. With spaces, I have to hit the backspace key 
several times to get back. That's it--one feature is the only reason I 
like tabs, so I decided to investigate vim's features to see if vim 
would let me backspace to the previous tab position with one keystroke.

'Softtabstop' (sts) is the feature. I would have never thought to look 
for this feature without your post. Thanks again Xah.

Your posts are on topic, informative, engaging and necessary. Keep them 
coming Xah. :)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code

[Xah Lee]

the following are 2 FAQ following this thread. Thanks.

Addendum: 2006-05-15

Q: What you mean by embeding tab position info into the source code?
How's that gonna be done?

A: Tech geekers may not realize, but such embedding of meta info do
exist in many technologies by various means because of a need. For
example, Mac OS Classic's resource fork and Mac OS X's bundling system,
unix shell script's shebang (#!), emacs and Python's encoding
declaration “#-*- coding: utf-8 -*-”, Unicode's BOM, CVS's
change-log insertion, Mathematica's source code system the Notebook,
Microsoft Word's transparent meta data, as well as HTML and XML's
various declarations embedded in the file. Some of these systems are
good designs and some are hacks.

Somehow tech geekers have the sense that “source code” must be a
plain text file containing nothing else but the programing code. This
may be a defendable position, but as we can see in the above examples,
this idea is primitive and does not address the various needs. If the
tech geekers have thought out about these issues, computing languages
and its source code may have developed into more powerful and flexible
integrated systems as the above standardized examples. For instance,
many commercial development systems actually already have such
meta-data embodied with the source code. (e.g. Borland Delphi,
Metrowerks's CodeWarrior, Microsoft Visual Studio, Wolfram Research's
Mathematica.) Some of which, not only embody development-related info
such as debug points or linking files, but also allow programers to
high-light code for visual purposes like a word processor, or even
display them visually as type-set mathematics.

Q: Converting spaces to tabs is actually easy. I don't see how spacess
lose info.

A: Here is a illustration on how it is not possible to convert spaces
to tabs. Suppose you are writing in a language where the indentation is
part of the semantics, not just for appearance. Now, suppose you have
these two lines:

1234567890
  A
B

The first line has 2 space prefix and second line has 4 space prefix.
How, if you convert this to tabs, how do you know that's 1 and 2 tabs,
or 2 and 4 tabs? In essence, there is no way to tell how many tabs n
represents, where n is the smallest space prefix in the code, unless n
== 1.

The above demonstrates the information loss in using spaces for
indentation in a theoretical way. There are also practical problems. In
practice, many languages allow string literals like this myName="i love
you", and strings easily can have a run of spaces. One cannot simply
run a blind find-n-replace operation to replace all spaces to tabs. But
also, many unix languages contains a so-called construct of
“heredoc” as a mean to embed a literal block of text. For example,
here's a PHP construct of heredoc:

$novelText = <<http://xahlee.org/

Xah Lee wrote:
> Tabs versus Spaces in Source Code
> This post is archived at:
> http://xahlee.org/UnixResource_dir/writ/tabs_vs_spaces.html

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs are *MISUNDERSTOOD*, *EVIL* AND *STUPID*, end of discussion. (Re: Tabs versus Spaces in Source Code)

[Christophe Cavalaria]

Christopher Weimann wrote:

> On 05/19/2006-07:18AM, Duncan Booth wrote:
>> 
>> My experience of programming with either spaces or tabs has taught me
>> that tabs are evil not for themselves, but simply because no matter how
>> hard you try they always end up being mixed with spaces.
>> 
> 
> Swap the word 'tabs' for the word 'spaces' and you get...
> 
>   My experience of programming with either tabs or spaces has taught me
>   that spaces are evil not for themselves, but simply because no matter
>   how hard you try they always end up being mixed with tabs.
> 
> Which is just as vaild as the un-swapped paragraph. Both versions
> express a bias. The first is biased in favor of spaces. The second is
> biased in favor of tabs. Neither have any useful content. Mixing is bad
> but that fact doesn't favor spaces OR tabs.

The difference is that you cannot code without spaces but you can do it
without tabs.
-- 
http://mail.python.org/mailman/listinfo/python-list

The ONE TRUE WAY to use tabs (Re: Tabs versus Spaces in Source Code)

[Andy Sy]

achates wrote:

> Yeah - we've got to the repeating ourselves stage.

Actually a couple of the responses on this newsgroup
have settled the question for me.  I did learn something
new by engaging in this holy war.


Tabs need not be evil, but ONLY if they are used in one
particular way:

If you really must use tabs, use them *ONLY* for 'semantic'
indentation and use pure spaces when you need arbitrary
indentation (e.g. arbitrary spacing).

PHP Example
===

function xyz() {
->print  "This is a really really really long line that I'd ".
->   "like to extend to the one down below while preserving ".
->   "ease of readability by aligning the start of the string".
->   "lines.  I use tabs to reflect syntactical (e.g. semantic) ".
->   "indentation, but use spaces for arbitrary indentation.\n\n".;
->while (10) {
->->print "This code will align properly no matter what tabsize setting ".
->->  "the reader uses, and is the only real benefit of using tab ".
->->  "characters instead of pure spaces.\n\n";
}



I did some basic tests, and it looks like this style should also
work for Python code.


THIS IS THE *SINGLE* CORRECT WAY TO USE TABS IN CODE!  ANYTHING
ELSE WILL BE A PAIN FOR PEOPLE WITH TABSIZE SETTINGS DIFFERENT
FROM YOURS!!


> But that's the problem with this issue: it's really hard to get the
> space-indenters to actually think about it and to address what is being
> said. Every time it comes up, there's always a few people trying to
> explain why tabs give are a good idea, facing a whole raft of others
> spouting stuff like:

Most of the tab-indenters have the same attitude.  But I did get ALL
of my points against tabs addressed this time.  And thank you to those
people including you for the 'less -x' tip.



> But unfortunately the situation is worse than that: tab indentation
> needs to be actively defended.

A world where everyone uses pure spaces would be far far far better
than the current situation where tab users can't even decide what
the universal tabsize should be and whose code alignment breaks
on different tabsize settings.

However, a world where EVERYONE who uses tabs strictly practice the
ONE TRUE TAB WAY would be a *slightly* better place than one where
everyone used pure spaces.

And remember, the ONE TRUE TAB WAY does not come for free and involves
a certain amount of tedium and attention.  It will be impractical on
most simple text editors.  For most people, I frankly don't think the
minor benefits are worth it.



> Unlikely perhaps. I hope so. It's a cruel irony that Python's creator
> didn't appreciate the benefits that tab indentation would bring to his
> own language - the only major language in which indentation levels
> actually have semantic significance.

You might want to run those benefit/s/ by me again, because the SINGLE
benefit I can still see to using tabs is so that people who have
different indentation width preferences can view code according to
the way they want.  And remember, this benefit will ONLY occur
IF people stick to using the ONE TRUE TAB WAY outlined above.

Any other method of tabbing would just be worse than a pure-spaces
world.




--
It's called DOM+XHR and it's *NOT* a detergent!

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code

[Roedy Green]

On Mon, 15 May 2006 02:44:54 GMT, Eli Gottlieb <[EMAIL PROTECTED]>
wrote, quoted or indirectly quoted someone who said :

>Actually, spaces are better for indenting code. 

Agreed.  All it takes is one programmer to use a different tab
expansion convention to screw up a project.  Spaces are unambiguous.

Ideally though you should run code through a beautifier before checkin
to avoid false deltas with people manually formatting code slightly
differently.
-- 
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs are *MISUNDERSTOOD*, *EVIL* AND *STUPID*, end of discussion. (Re: Tabs versus Spaces in Source Code)

[Christopher Weimann]

On 05/19/2006-07:18AM, Duncan Booth wrote:
> 
> My experience of programming with either spaces or tabs has taught me 
> that tabs are evil not for themselves, but simply because no matter how 
> hard you try they always end up being mixed with spaces.
> 

Swap the word 'tabs' for the word 'spaces' and you get...

  My experience of programming with either tabs or spaces has taught me 
  that spaces are evil not for themselves, but simply because no matter how 
  hard you try they always end up being mixed with tabs.

Which is just as vaild as the un-swapped paragraph. Both versions
express a bias. The first is biased in favor of spaces. The second is
biased in favor of tabs. Neither have any useful content. Mixing is bad
but that fact doesn't favor spaces OR tabs.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs are *MISUNDERSTOOD*, *EVIL* AND *STUPID*, end of discussion. (Re: Tabs versus Spaces in Source Code)

[Peter Decker]

On 19 May 2006 07:18:03 GMT, Duncan Booth <[EMAIL PROTECTED]>
> Can you point at any significant body of publically visible Python code
> which uses tabs exclusively? All of the Python projects I've ever been
> involved with use spaces only as a convention (although as I pointed out in
> my previous post, some with more success than others).

Dabo.  http://dabodev.com

-- 

# p.d.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs are *MISUNDERSTOOD*, *EVIL* AND *STUPID*, end of discussion. (Re: Tabs versus Spaces in Source Code)

[PoD]

On Fri, 19 May 2006 10:04:15 +0200, Christophe wrote:

> PoD a écrit :
>> Maybe what Python should do (but never will given the obsession with using
>> spaces) is only allow one level of indentation increase per block so that
>> 
>> def foo():
>> return 'bar'
>> 
>> would return a syntax error
> 
> Which would make  mandatory for indentation. What about some 
> freedom of choice ?

Hey, if people are allowed to say that tabs should be banned, then I'm
allowed to say they should be mandatory ;)

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs are *MISUNDERSTOOD*, *EVIL* AND *STUPID*, end of discussion. (Re: Tabs versus Spaces in Source Code)

[Dave Hansen]

On 19 May 2006 07:18:03 GMT in comp.lang.python, Duncan Booth
<[EMAIL PROTECTED]> wrote:

[...]
>My experience of programming with either spaces or tabs has taught me 
>that tabs are evil not for themselves, but simply because no matter how 
>hard you try they always end up being mixed with spaces.

That's been my experience as well.  At least on projects with more
than one programmer.  And more than once with single-programmer
projects where the programmer changed or updated his editor in the
middle...

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs are *MISUNDERSTOOD*, *EVIL* AND *STUPID*, end of discussion. (Re: Tabs versus Spaces in Source Code)

[Sybren Stuvel]

Duncan Booth enlightened us with:
> Can you point at any significant body of publically visible Python
> code which uses tabs exclusively?

Everything Python at http://www.stuvel.eu/software

> Also, in the open source universe you are quite likely to pull in
> bits of code from other projects, and you don't want to either have
> to reformat it or to switch your editor settings for some files.

If I grab a module, I just leave the module as is. If I grab a code
snippet, I always reformat it to my own style. That's very easy using
VIM's "retab" command.

> Do you know of any open-source projects which actually try to enforce a 
> 'tab only' convention for Python?

My software is, although I'm still the only one working on them ;-)

Sybren
-- 
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself? 
 Frank Zappa
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs are *MISUNDERSTOOD*, *EVIL* AND *STUPID*, end of discussion. (Re: Tabs versus Spaces in Source Code)

[Christophe]

PoD a écrit :
> Maybe what Python should do (but never will given the obsession with using
> spaces) is only allow one level of indentation increase per block so that
> 
> def foo():
> return 'bar'
> 
> would return a syntax error

Which would make  mandatory for indentation. What about some 
freedom of choice ?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs are *MISUNDERSTOOD*, *EVIL* AND *STUPID*, end of discussion. (Re: Tabs versus Spaces in Source Code)

[Duncan Booth]

PoD wrote:
> I think it is universally accepted that mixed tabs and spaces is indeed
> **EVIL**
> 
> I should have said any code using tabs exclusively.
> 
Can you point at any significant body of publically visible Python code 
which uses tabs exclusively? All of the Python projects I've ever been 
involved with use spaces only as a convention (although as I pointed out in 
my previous post, some with more success than others).

The problem with conventions such as 'tabs only' or 'space only' is that 
they only work if everyone sticks to the conventions, and it helps if the 
same conventions are in place everywhere (otherwise people forget when they 
switch from one project to another). Also, in the open source universe you 
are quite likely to pull in bits of code from other projects, and you don't 
want to either have to reformat it or to switch your editor settings for 
some files.

My experience of programming with either spaces or tabs has taught me 
that tabs are evil not for themselves, but simply because no matter how 
hard you try they always end up being mixed with spaces.

Do you know of any open-source projects which actually try to enforce a 
'tab only' convention for Python? I'd really like to see a similar scan 
over some 'tab only' code as I did over Plone to see whether they actually 
manage to remain 'pure'.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs are *MISUNDERSTOOD*, *EVIL* AND *STUPID*, end of discussion. (Re: Tabs versus Spaces in Source Code)

[PoD]

On Thu, 18 May 2006 10:33:58 +0200, Christophe wrote:

> PoD a écrit :
>> On Wed, 17 May 2006 21:37:14 +0800, Andy Sy wrote:
>> 
>> 
>>>If tabs are easily misunderstood, then they are a MISfeature
>>>and they need to be removed.
>>>
From the Zen of Python:
>>>
>>>"Explicit is better than implicit..."
>>>"In the face of ambiguity, refuse the temptation to guess..."
>>>"Special cases aren't special enough to break the rules..."
>> 
>> 
>> Exactly.
>> How many levels of indentation does 12 spaces indicate?
>> It could be 1,2,3,4,6 or 12.  If you say it's 3 then you are _implying_
>> that each level is represented by 4 spaces.
> 
> Actually, who said you had to always use the same number of spaces to 
> indent ? 12 = 6 + 6 = 4 + 4 + 4 but also 12 = 2 + 10 = 1 + 1 + 3 + 3 + 4 :D

Thus supporting my assertion that space indenting is implicit not
explicit. Spaces are evil.

> 
>> How many levels of indentation is 3 tabs?  3 levels in any code that
>> you will find in the wild.
> 
> No, it could be 3 levels or 3 tabs per level or 2 tabs for the first
> level and 1 tab for the second ...

Could be but wouldn't be.

Maybe what Python should do (but never will given the obsession with using
spaces) is only allow one level of indentation increase per block so that

def foo():
return 'bar'

would return a syntax error

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs are *MISUNDERSTOOD*, *EVIL* AND *STUPID*, end of discussion. (Re: Tabs versus Spaces in Source Code)

[PoD]

On Thu, 18 May 2006 08:30:03 +, Duncan Booth wrote:

> PoD wrote:
>> How many levels of indentation does 12 spaces indicate?
>> It could be 1,2,3,4,6 or 12.  If you say it's 3 then you are
>> _implying_ that each level is represented by 4 spaces.
> 
> By reading the code I can see how many levels of indentation it
> represents. 
> 
>> How many levels of indentation is 3 tabs?  3 levels in any code that
>> you will find in the wild.
> 
> No. That is precisely the problem: there is code in the wild which
> contains mixed space and tab indentation, and any time that happens 3
> tabs could mean any number of indentations. 

I think it is universally accepted that mixed tabs and spaces is indeed
**EVIL**

I should have said any code using tabs exclusively.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code

[Oliver Bandel]

Jonathon McKitrick wrote:

> Pascal Bourguignon wrote:
> 
>>(defun ιοτα (&key (номер 10) (단계 1) (בכוכ 0))
>>  (loop :for i :from בכוכ :to номер :by 단계 :collect i))
> 
> 
> How do you even *enter* these characters?  My browser seems to trap all
> the special character combinations, and I *know* you don't mean
> selecting from a character palette.

Didn't you heard of that big keyboards?

12 meter x 2 meter wide I think you need a long
stick (maybe if you play golf, that can help).

The you have all UTF-8 characters there, that's fine,
but typing needs some time.
But it's good, because when ready with typing your email,
it's not necessary to go to sports after work. So your boss
can insist that you longer stay at work.


Ciao,
Oliver

;-)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code

[Pascal Bourguignon]

"Jonathon McKitrick" <[EMAIL PROTECTED]> writes:

> Pascal Bourguignon wrote:
>> (defun ιοτα (&key (номер 10) (단계 1) (בכוכ 0))
>>   (loop :for i :from בכוכ :to номер :by 단계 :collect i))
>
> How do you even *enter* these characters?  My browser seems to trap all
> the special character combinations, and I *know* you don't mean
> selecting from a character palette.

Why?  Of course!  
Aren't you either an emacs or a Mac user?

On a Mac, you just select the input keyboad from the Input menu (the
little flag on the right of the menubar, you may activate it from the
International System Preference panel).

On emacs, it's as simple: M-x set-input-method RET

I've bound C-F9, C-F10, C-F11, and C-F12 to various input methods:

(global-set-key [C-f9]  (lambda()(interactive)(set-input-method 
'chinese-py-b5)))
(global-set-key [C-f10] (lambda()(interactive)(set-input-method 
'cyrillic-yawerty)))
(global-set-key [C-f11] (lambda()(interactive)(set-input-method 'greek)))
(global-set-key [C-f12] (lambda()(interactive)(set-input-method 'hebrew)))

C-\ is bound to toggle-input-method which allows to revert back to the
usual input method. 

For the alphabetic scripts, there's no difficulty, it's like with
roman scripts: each key is a character.  For ideographic scripts, the
input methods are more sophisticated.

Then, you have to learn some of these strange languages. I learned
several (but I forgot everything but: לודג גד דג ינד, здраствуйте, я
люблю тибе, 我 聽龍, 我 不 中国人).  For the Korean, I copy-and-pasted
it from some web translation service.  But keying them in is the
easiest part.

-- 
__Pascal Bourguignon__ http://www.informatimago.com/
Cats meow out of angst
"Thumbs! If only we had thumbs!
We could break so much!"
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code ('semantic' vs. arbitrary indentation)

[Edward Elliott]

Christophe wrote:

> No, it's really easy : a simple precoomit hook which will refuse any .py
> file with the \t char in it and it's done ;)

$ echo \t
t

Why would you wan_ _o remove all _ee charac_ers?  Isn'_ _ha_ a li__le
awkward?

-- 
Edward Elliott
UC Berkeley School of Law (Boalt Hall)
complangpython at eddeye dot net
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code

[Pascal Bourguignon]

Edmond Dantes <[EMAIL PROTECTED]> writes:
> It all depends on your editor of choice. Emacs editing of Lisp (and a few
> other languages, such as Python) makes the issue more or less moot. I
> personally would recommend choosing one editor to use with all your
> projects, and Emacs is wonderful in that it has been ported to just about
> every platform imaginable. 
>
> The real issue is, of course, that ASCII is showing its age and we should
> probably supplant it with something better. But I know that will never fly,
> given the torrents of code, configuration files, and everything else in
> ASCII. Even Unicode couldn't put a dent in it, despite the obvious growing
> global development efforts. Not sure how many compilers would be able to
> handle Unicode source anyway. I suspect the large majority of them would
> would choke big time.

All right unicode support is not 100% perfect already, but my main
compilers support it perfectly well, only 1/5 don't support it, and
1/5 support it partially:

--(unicode-script.lisp)-

(defun clisp (file)
  (ext:run-program "/usr/local/bin/clisp"
:arguments (list "-ansi" "-norc"  "-on-error" "exit"
 "-E" "utf-8"
 "-i" file "-x" "(ext:quit)")
:input nil :output :terminal :wait t))

(defun gcl (file)
  (ext:run-program "/usr/local/bin/gcl"
:arguments (list "-batch"
 "-load" file "-eval" "(lisp:quit)")
:input nil :output :terminal :wait t))

(defun ecl (file)
  (ext:run-program "/usr/local/bin/ecl"
:arguments (list "-norc"
 "-load" file "-eval" "(si:quit)")
:input nil :output :terminal :wait t))

(defun sbcl (file)
  (ext:run-program "/usr/local/bin/sbcl"
:arguments (list "--userinit" "/dev/null"
 "--load" file "--eval" "(sb-ext:quit)")
:input nil :output :terminal :wait t))

(defun cmucl (file)
  (ext:run-program "/usr/local/bin/cmucl"
:arguments (list "-noinit"
 "-load" file "-eval"  "(extensions:quit)")
:input nil :output :terminal :wait t))


(dolist (implementation '(clisp gcl ecl  sbcl cmucl))
  (sleep 3)
  (terpri) (print implementation) (terpri)
  (funcall implementation "unicode-source.lisp"))

--(unicode-source.lisp)-
;; -*- coding: utf-8 -*-

(eval-when (:compile-toplevel :load-toplevel :execute)
  (format t "~2%~A ~A~2%"
  (lisp-implementation-type)
  (lisp-implementation-version))
  (finish-output))


(defun ιοτα (&key (номер 10) (단계 1) (בכוכ 0))
  (loop :for i :from בכוכ :to номер :by 단계 :collect i))


(defun test ()
  (format t "~%Calling ~S --> ~A~%"
  '(ιοτα :номер 10 :단계 2  :בכוכ 2)
  (ιοτα :номер 10 :단계 2  :בכוכ 2)))

(test)



(load"unicode-script.lisp")
;; Loading file unicode-script.lisp ...

CLISP 
  i i i i i i i   ooooo   o   o
  I I I I I I I  8 8   8   8 8 o  88
  I  \ `+' /  I  8 8   8 888
   \  `-+-'  /   8 8   8  o   8
`-__|__-'8 8   8   8  8
|8 o   8   8 o 8  8
  --+--   o8oo  ooo8ooo   o   8

Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2000
Copyright (c) Sam Steingold, Bruno Haible 2001-2006

;; Loading file unicode-source.lisp ...

CLISP 2.38 (2006-01-24) (built 3347193361) (memory 3347193794)


Calling (ΙΟΤΑ :НОМЕР 10 :단계 2 :בכוכ 2) --> (2 4 6 8 10)
;; Loaded file unicode-source.lisp
Bye.


GCL 


GNU Common Lisp (GCL) GCL 2.6.7


Calling (ιοτα :номер 10 :단계 2 :בכוכ 2) --> (2 4 6 8
 10)


ECL 
;;; Loading "unicode-source.lisp"


ECL 0.9g


Calling (ιοτα :номер 10 :단계 2 :בכוכ 2) --> (2 4 6 8 10)


SBCL 
This is SBCL 0.9.12, an implementation of ANSI Common Lisp.
More information about SBCL is available at .

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.


SBCL 0.9.12


Calling (|ιοτα| :|номер| 10 :|ˋ¨ʳ„| 2 :|בכוכ| 2) --> (2 4 6 8 10)


CMUCL 
; Loading #P"/local/users/pjb/src/lisp/encours/unicode-source.lisp".


CMU Common Lisp 19c (19C)


Reader error at 214 on #:
Undefined read-macro character #\Î
   [Condition of type READER-ERROR]

Restarts:
  0: [CONTINUE] Return NIL from load of "unicode-source.lisp".
  1: [ABORT   ] Skip remaining initializations.

Debug  (type H for help)

(LISP::%READER-ERROR
 #
 "Undefined read-m

Re: Tabs are *MISUNDERSTOOD*, *EVIL* AND *STUPID*, end of discussion. (Re: Tabs versus Spaces in Source Code)

[achates]

Duncan Booth wrote:

> No. That is precisely the problem: there is code in the wild which
> contains mixed space and tab indentation...



> I wouldn't have a problem with tabs if Python rejected mixed indentation by
> default, because then none of the code above would execute.

I think it's great that at least we're all agreed that mixed
indentation is a bad idea in any code, and particularly in Python.

How would people feel about having the -t (or even -tt) behaviour
become the default in future Python releases? A legacy option would
obviously need to be provided for the old default behaviour.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code

[Alain Picard]

"Bill Pursell" <[EMAIL PROTECTED]> writes:

> In my experience, the people who complain about the use
> of tabs for indentation are the people who don't know
> how to use their editor, and those people tend to use 
> emacs.

HA HA HA HA HA HA HA HA HA HA HA HA 

Tee, hee heee snif!

Phew.  Better now.

That was funny!  Thanks!  :-)

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code ('semantic' vs. arbitrary indentation)

[achates]

Edward Elliott wrote:

> What really should happen is that every time an editor reads in source code,
> the code is reformatted for display according to the user's settings.  The
> editor becomes a parser, breaking the code down into tokens and emitting it
> in a personally preferred format.

I completely agree, and I guess that is what I was groping towards in
my remarks about using modern editing tools.

At the same time I would be resist any move towards making source files
less huiman-readable. There will still be times when those tools aren't
available (e.g. for people working on embedded s/w or legacy systems),
and that's when having ASCII source with tabbed indentation would be so
useful. But it looks, sadly, like we're fighting a rearguard action on
that one.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs are *MISUNDERSTOOD*, *EVIL* AND *STUPID*, end of discussion. (Re: Tabs versus Spaces in Source Code)

[Christophe]

PoD a écrit :
> On Wed, 17 May 2006 21:37:14 +0800, Andy Sy wrote:
> 
> 
>>If tabs are easily misunderstood, then they are a MISfeature
>>and they need to be removed.
>>
>>>From the Zen of Python:
>>
>>"Explicit is better than implicit..."
>>"In the face of ambiguity, refuse the temptation to guess..."
>>"Special cases aren't special enough to break the rules..."
> 
> 
> Exactly.
> How many levels of indentation does 12 spaces indicate?
> It could be 1,2,3,4,6 or 12.  If you say it's 3 then you are _implying_
> that each level is represented by 4 spaces.

Actually, who said you had to always use the same number of spaces to 
indent ? 12 = 6 + 6 = 4 + 4 + 4 but also 12 = 2 + 10 = 1 + 1 + 3 + 3 + 4 :D

> How many levels of indentation is 3 tabs?  3 levels in any code that you
> will find in the wild.

No, it could be 3 levels or 3 tabs per level or 2 tabs for the first 
level and 1 tab for the second ...
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs are *MISUNDERSTOOD*, *EVIL* AND *STUPID*, end of discussion. (Re: Tabs versus Spaces in Source Code)

[Duncan Booth]

PoD wrote:
> How many levels of indentation does 12 spaces indicate?
> It could be 1,2,3,4,6 or 12.  If you say it's 3 then you are
> _implying_ that each level is represented by 4 spaces.

By reading the code I can see how many levels of indentation it
represents. 

> How many levels of indentation is 3 tabs?  3 levels in any code that
> you will find in the wild.

No. That is precisely the problem: there is code in the wild which
contains mixed space and tab indentation, and any time that happens 3
tabs could mean any number of indentations. 

Now, I just know someone is going to challenge me over my assertion that
there really could be code with mixed spaces and tabs out there, so here
are a few examples found by grepping a Plone Products folder. All the 
projects below use spaces almost everywhere for indentation, but it looks
like a few tabs slipped through.

http://svn.plone.org/view/archetypes/Archetypes/trunk/BaseUnit.py?rev=5111&view=auto
 

contains tabs at the start of two lines. Fortunately these are
continuation lines so it doesn't really matter how you display them. I
think they are intended to be displayed with tab-size=8.

http://svn.plone.org/view/archetypes/Archetypes/trunk/Storage/__init__.py?rev=4970&view=auto

One tab used for indentation. The block is only one line long so the code
doesn't break whatever tabsize you use, but visually it would appear the 
intended tabsize is 0.

http://svn.plone.org/view/plone/CMFPlone/trunk/skins/plone_scripts/computeRelatedItems.py?rev=9836&view=auto

A tab is used for two levels of indentation. Anything other than tabsize=8 
would cause a syntax error.

http://svn.plone.org/view/plone/CMFPlone/trunk/skins/plone_scripts/computeRoleMap.py?rev=9836&view=auto

Lots of tabs, most but not all on continuation lines. The two which aren't 
are on single line blocks with a single tab representing two indents.

CMFPlone\tests\testInterfaces.py
CMFPlone\tests\testTranslationServiceTool.py
ExternalEditor (various files)
kupu (spellcheck.py)

and finally, at the end of my Plone Products directory I found this beauty 
where I've replaced the tab characters with  to make them visible:

svn://svn.zope.org/repos/main/Zelenium/trunk/scripts/tinyWebServer.py

if __name__ == '__main__':
port = PORT
if len(sys.argv) > 1:
port = int(sys.argv[1])

server_address = ('', port)
httpd = BaseHTTPServer.HTTPServer(server_address, HTTPHandler)

print "serving at port", port
print "To run the entire JsUnit test suite, open"
print "  
http://localhost:8000/jsunit/testRunner.html?testPage=http://localhost:8000/tests/JsUnitSuite.html&autoRun=true";
print "To run the acceptance test suite, open"
print "  http://localhost:8000/TestRunner.html";

while not HTTPHandler.quitRequestReceived :
httpd.handle_request()


This is a genuine example of code in the wild which will look like 
syntactically valid Python at either tab-size=4 or tab-size=8, but 
if you view it at tab-size=4 you will see different block indentation 
than the Python interpreter uses at tab-size=8.

At tab-size=4 it reads:

if __name__ == '__main__':
port = PORT
if len(sys.argv) > 1:
port = int(sys.argv[1])

server_address = ('', port)
httpd = BaseHTTPServer.HTTPServer(server_address, HTTPHandler)

print "serving at port", port
print "To run the entire JsUnit test suite, open"
print "  
http://localhost:8000/jsunit/testRunner.html?testPage=http://localhost:8000/tests/JsUnitSuite.html&autoRun=true";
print "To run the acceptance test suite, open"
print "  http://localhost:8000/TestRunner.html";

while not HTTPHandler.quitRequestReceived :
httpd.handle_request()  

but at tab-size=8 it reads:

if __name__ == '__main__':
port = PORT
if len(sys.argv) > 1:
port = int(sys.argv[1])

server_address = ('', port)
httpd = BaseHTTPServer.HTTPServer(server_address, HTTPHandler)

print "serving at port", port
print "To run the entire JsUnit test suite, open"
print "  
http://localhost:8000/jsunit/testRunner.html?testPage=http://localhost:8000/tests/JsUnitSuite.html&autoRun=true";
print "To run the acceptance test suite, open"
print "  http://localhost:8000/TestRunner.html";

while not HTTPHandler.quitRequestReceived :
httpd.handle_request()  

I wouldn't have a problem with tabs if Python rejected mixed indentation by 
default, because then none of the code above would execute. But it doesn't.
 :(

Anyone got a subversion checkin hook to reject mixed indentation? I think that 
big
repositories like Zope and Plone could benefit from it.

I just ran the same grep on the Python source tree. Not a tab in sight. :)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code ('semantic' vs. arbitrary indentation)

[Christophe]

Carl J. Van Arsdall a écrit :
> glomde wrote:
> 
>>> 
>>
>>
>> But If you work in a team it is kind of hard to make sure that
>> everybody use tabs and not spaces. And it is not very easy to spot
>> either.   
> 
> The converse can also be said, "it's difficult to make sure everyone 
> uses spaces and not tabs".
> 
> I think we've just about beat this discussion to death... nice work 
> everyone!
> 

No, it's really easy : a simple precoomit hook which will refuse any .py 
file with the \t char in it and it's done ;)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs are *MISUNDERSTOOD*, *EVIL* AND *STUPID*, end of discussion. (Re: Tabs versus Spaces in Source Code)

[PoD]

On Wed, 17 May 2006 21:37:14 +0800, Andy Sy wrote:

> If tabs are easily misunderstood, then they are a MISfeature
> and they need to be removed.
> 
>>From the Zen of Python:
> 
> "Explicit is better than implicit..."
> "In the face of ambiguity, refuse the temptation to guess..."
> "Special cases aren't special enough to break the rules..."

Exactly.
How many levels of indentation does 12 spaces indicate?
It could be 1,2,3,4,6 or 12.  If you say it's 3 then you are _implying_
that each level is represented by 4 spaces.

How many levels of indentation is 3 tabs?  3 levels in any code that you
will find in the wild.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code

[ashesh]

If I work on your project, I follow the coding and style standards you
specify.


Likewise if you  work on my project you follow the established
standards.


Fortunately for you, I am fairly liberal on such matters.


I like to see 4 spaces for indentation.  If you use tabs, that's what I

will see, and you're very likely to have your code reformatted by the
automated build process, when the standard copyright header is pasted
and missing javadoc tags are generated as warnings.


I like the open brace to start on the line of the control keyword.  I
can deal with the open brace being on the next line, at the same level
of indentation as the control keyword.  I don't quite understand the
motivation behind the GNU style, where the brace itself is treated as a

half-indent, but I can live with it on *your* project.


Any whitespace or other style that isn't happy to be reformatted
automatically is an error anyway.


I'd be very laissez-faire about it except for the fact that code
repositories are much easier to manage if everything is formatted
before
it goes in, or as a compromise, as a step at release tags. 


Ashesh..

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code

[Jorge Godoy]

achates wrote:

> Jorge Godoy wrote
> 
>>Emacs guess what's used in the file and allows me to use tabs all the
>>time, doing the correct thing...
> 
> That sounds like useful behaviour.
> 
> Maybe this is an area where modern editors might be able to save us
> from ourselves. I'll admit I'm suspicious of relying on editor
> functionality - I'm happier if I know I can also use the old-school
> methods just in case.. Sometimes adding intelligence to an interface
> can be a usability disaster if it makes wrong assumptions about what
> you want. But if people are hell-bent on converting tabs to spaces,
> maybe it's the best way to accommodate them.

If you don't want the functionality, simply disable it.  This is why
configuration files and options exist...

-- 
Jorge Godoy  <[EMAIL PROTECTED]>

"Quidquid latine dictum sit, altum sonatur."
- Qualquer coisa dita em latim soa profundo.
- Anything said in Latin sounds smart.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code ('semantic' vs. arbitrary indentation)

[Edward Elliott]

We've finally hit the meta-discussion point.  Instead of talking about tabs
and spaces, we're talking about talking about tabs and spaces.  Which
frankly is a much more interesting conversation anyway.

achates wrote:

> Does it matter? Perhaps not if we can use tools which enable us to
> bridge the divide, like indent auto-detection in emacs and vim. I'm
> prepared to do that in cases where I have to work with an existing
> group of coders uasing spaces.

If you ask me, which of course you didn't, indentation is just one small
part of the larger issue of code formatting.  Unfortunately it's the only
one that allows some semblance of flexibility.  Formatting like brace/paren
placement and inter-operator spacing greatly affect readability but are
hard-coded into the source.  And none of this matters a wit to the
semantics of the code.

What really should happen is that every time an editor reads in source code,
the code is reformatted for display according to the user's settings.  The
editor becomes a parser, breaking the code down into tokens and emitting it
in a personally preferred format.  Comments are left untouched apart from
initial indentation.  On output back to a file, the code can be either
written as-is (the next guy's editor will reformat it anyway) or put in
some standard form (for the poor shlubs who code with cat/notepad).

All this becomes completely transparent to the user, who sees every file he
edits in exactly the format he's accustomed to.  It's similar to the
various pushes for syntactic code storage formats like abstract syntax
trees or  xml, but works with the existing infrastructure built
around processing plain text files.  Meanwhile LISP has been storing code
in paren-based ASTs since the 50s.

vim and emacs can already do this today.  It might not be perfect, but if
people spent half as much time perfecting this as arguing about tabs vs
spaces, we'd all be a lot better off (yes I'm guilty too).


> It's a cruel irony that Python's creator
> didn't appreciate the benefits that tab indentation would bring to his
> own language - the only major language in which indentation levels
> actually have semantic significance.

Fate is a cruel mistress.  Or maybe just a heartless bitch.  Either way,
watch your back.

-- 
Edward Elliott
UC Berkeley School of Law (Boalt Hall)
complangpython at eddeye dot net
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code ('semantic' vs. arbitrary indentation)

[Dave Hansen]

On 17 May 2006 16:13:54 -0700 in comp.lang.python, "achates"
<[EMAIL PROTECTED]> wrote:

>Carl J. Van Arsdall wrote:
>
>> The converse can also be said, "it's difficult to make sure everyone
>> uses spaces and not tabs".
>>
>> I think we've just about beat this discussion to death... nice work
>> everyone!
>
>Yeah - we've got to the repeating ourselves stage.
>
>But that's the problem with this issue: it's really hard to get the
>space-indenters to actually think about it and to address what is being
>said. Every time it comes up, there's always a few people trying to

Look in the mirror.  There is non so blind...

>explain why tabs give are a good idea, facing a whole raft of others

The problem is that TABs are a _bad_ idea.

>spouting stuff like:
>'mixing spaces and tabs is bad so use spaces only'

Mixing TABs and spaces is bad because it means using TABs.  ;-)

>'tabs are x spaces and I like to use y spaces'

I've not seen that argument.  One of us needs to read closer.

Although I have seen the converse used to defend TABs: x spaces is x
spaces, and I like y spaces,  

>'tabs are bad end of story'

Works for me!  ;-)

>and these non-arguments are repeated over and over within the same
>thread. At times it's like talking to a child - and not a bright one at
>that.

These "non-arguments" are your own straw men.  Either that, or you
need to work on reading comprehension.

>
>Does it matter? Perhaps not if we can use tools which enable us to
>bridge the divide, like indent auto-detection in emacs and vim. I'm
>prepared to do that in cases where I have to work with an existing
>group of coders uasing spaces.

It matters because not every programmer is willing to put in the time
effort required to learn how to use a sophisticated editor like emacs
or vim well.  Or at all.   

It matters because in industry you get programmers with a wide range
of skills, and you can't fire everyone who can't tell when there are
spaces in front of a tab character.  Often these people have unique
and hard-to-find domain knowledge.

>
>But unfortunately the situation is worse than that: tab indentation
>needs to be actively defended. Most of the coding 'style guides' you'll

No, it needs to be stamped out.  ;-)

>find (including Python's) advocate spaces only. There are plenty of

Hallelujah!

>people who would like tabs removed from the language as an acceptable
>indentation method - look at the responses to Guido's April Fools blog
>entry last year.

I would love to see the TAB character treated as a syntax error.  I
have no illusions that's going to happen, though.

FWIW, I would be equally (well, almost, anyway) happy if Python said
that the _only_ place a TAB character could appear was at the
beginning of a line, and that the number of TAB characters _always_
indicated the indentation level (e.g., spaces do _not_ change
indentation level, and all the lines in a multi-line statement had to
be at the same indentation level).  This would eliminate most of my
objections to TABs.  I have no illusions this will happen either.

>
>Unlikely perhaps. I hope so. It's a cruel irony that Python's creator
>didn't appreciate the benefits that tab indentation would bring to his
>own language - the only major language in which indentation levels
>actually have semantic significance.

The problem with TAB characters is that they look just like the
equivalent number of space characters.  This is, of course, their
major feature as well.  The problem, especially with Python, is that
mistakes in the placement of TAB characters within a source file can
silently change the _meaning_ of the code.

TAB proponents seem to list one overriding advantage of using TAB
characters for indentation: "I can use my preferred indent level, and
everyone else can use theirs."  I find this argument _very_ weak. I've
seen misuse of TABs break code.  I've never seen an enforced
indentation level break a programmer.

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code

[Terry Hancock]

Edmond Dantes wrote:

>The real issue is, of course, that ASCII is showing its age and we should
>probably supplant it with something better. But I know that will never fly,
>given the torrents of code, configuration files, and everything else in
>ASCII. Even Unicode couldn't put a dent in it, despite the obvious growing
>global development efforts. Not sure how many compilers would be able to
>handle Unicode source anyway. I suspect the large majority of them would
>would choke big time.
>  
>
I think that was the old conventional wisdom, but it's not so obvious
anymore. UTF-8 is a pretty cool standard.  gVim handles it just
fine, Python source allows UTF-8 within string literals, even if it
doesn't like it in identifiers, and IIRC, Unicode is the official standard
for Java files.  It continues not to be used so much, but a lot of the
capacity is there.

Also, the 'config files in ASCII' thing is simply not a problem -- ASCII
*is* a full-subset of UTF-8, so an ASCII config file is already a UTF-8
config file.

Personally, I don't think ASCII is nearly as entrenched as you suggest.
I wouldn't be surprised if Unicode/UTF-8 has fully supplanted it inside
of 10 years.

Cheers,
Terry

-- 
Terry Hancock ([EMAIL PROTECTED])
Anansi Spaceworks http://www.AnansiSpaceworks.com


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs are EVIL *and* STUPID, end of discussion. (Re: Tabs versus Spaces in Source Code)

[Edward Elliott]

Terry Hancock wrote:

> Now, of course, the data I provide is nasty, mean, poorly-formatted
> data, abhorable by space-zealots and tab-libertines alike (;-)), but the
> point is, unless you have set up your editor to syntax color spaces
> and tabs differently, you won't see the difference in the original
> editor.

Sure, mixed tabs and spaces were not part of my use case.

-- 
Edward Elliott
UC Berkeley School of Law (Boalt Hall)
complangpython at eddeye dot net
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs are EVIL *and* STUPID, end of discussion. (Re: Tabs versus Spaces in Source Code)

[Edward Elliott]

William Studenmund wrote:

> The problem is that tabs take you to the next tab stop, they don't
> expand to a fixed number of spaces.

Got it.  You're talking about using tabs other than for initial line
indentation on a source file.  Yes, then tab expansion is not perfect.

-- 
Edward Elliott
UC Berkeley School of Law (Boalt Hall)
complangpython at eddeye dot net
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs are EVIL *and* STUPID, end of discussion. (Re: Tabs versus Spaces in Source Code)

[Terry Hancock]

Edward Elliott wrote:

>Dave Hansen wrote:
>  
>
>I fail to see why less 'will work' but cat 'doesn't always work'.  
>
The distinction is not in the choice of program, but in the
way it is being used...

>The net
>effect of both is the same.  Unless you're in some weird place that pipes
>aren't allowed, these should be equivalent:
>
>cat file |sed 's/\t//g' |less
>less -x4 file
>  
>

Nope.  To demonstrate, I will use "T" to represent tab characters
and "S" to represent spaces (I think this will be
a lot easier to read):

In a properly formatting program, with tabstops at intervals of 4:

A=
"""
SSTSTdefSspam(self,Sfoo):
STTbarS=S1/foo
TTSTreturnSbar
"""

and
B =
"""
TTdefSspam(self,Sfoo):
barS=S1/foo
TTTreturnSbar
"""

should render exactly the same (i.e. like the following):

A=B=
"""
def spam(self, foo):
bar = 1/foo
return bar
"""

However, if we have tabstop set to 8 (the usual default),
then they will render differently:

A=
"""
def spam(self, foo):
bar = 1/foo
return bar
"""

B=
"""
def spam(self, foo):
bar = 1/foo
return bar
"""

(both are syntax errors, of course).

Presumeably, the "x" option to less will correctly handle
tabs (I didn't know about that -- thanks, BTW), but your
sed substitution doesn't "jump to the next tabstop" when
it hits a tab, it always adds a fixed number of spaces. So
it mangles the code too:

A=
"""
   def spam(self, foo):
 bar = 1/foo
 return bar
"""

B=
"""
def spam(self, foo):
bar = 1/foo
return bar
"""

>Now if you're talking about the conversion altering the data's semantics,
>that's a separate issue that has nothing to do with unix utilities and
>everything to do with the file formatting.  In that case, I'll simply refer
>you to the rest of this thread for discussion.
>  
>
Now, of course, the data I provide is nasty, mean, poorly-formatted
data, abhorable by space-zealots and tab-libertines alike (;-)), but the
point is, unless you have set up your editor to syntax color spaces
and tabs differently, you won't see the difference in the original
editor.

Cheers,
Terry

-- 
Terry Hancock ([EMAIL PROTECTED])
Anansi Spaceworks http://www.AnansiSpaceworks.com


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code ('semantic' vs. arbitrary indentation)

[achates]

Carl J. Van Arsdall wrote:

> The converse can also be said, "it's difficult to make sure everyone
> uses spaces and not tabs".
>
> I think we've just about beat this discussion to death... nice work
> everyone!

Yeah - we've got to the repeating ourselves stage.

But that's the problem with this issue: it's really hard to get the
space-indenters to actually think about it and to address what is being
said. Every time it comes up, there's always a few people trying to
explain why tabs give are a good idea, facing a whole raft of others
spouting stuff like:
'mixing spaces and tabs is bad so use spaces only'
'tabs are x spaces and I like to use y spaces'
'tabs are bad end of story'
and these non-arguments are repeated over and over within the same
thread. At times it's like talking to a child - and not a bright one at
that.

Does it matter? Perhaps not if we can use tools which enable us to
bridge the divide, like indent auto-detection in emacs and vim. I'm
prepared to do that in cases where I have to work with an existing
group of coders uasing spaces.

But unfortunately the situation is worse than that: tab indentation
needs to be actively defended. Most of the coding 'style guides' you'll
find (including Python's) advocate spaces only. There are plenty of
people who would like tabs removed from the language as an acceptable
indentation method - look at the responses to Guido's April Fools blog
entry last year.

Unlikely perhaps. I hope so. It's a cruel irony that Python's creator
didn't appreciate the benefits that tab indentation would bring to his
own language - the only major language in which indentation levels
actually have semantic significance.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs are EVIL *and* STUPID, end of discussion. (Re: Tabs versus Spaces in Source Code)

[William Studenmund]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On May 17, 2006, at 8:46 PM, Edward Elliott wrote:

> Dave Hansen wrote:
>
>> On Wed, 17 May 2006 17:28:26 GMT in comp.lang.python, Edward Elliott
>>> Just for the sake of completeness:
>>>
>>> cat file |sed 's/\t//g'
>>
>> That doesn't always work.  If you don't see why, you don't understand
>> my objection to TAB characters in text files.
>>
>>> less -x4 file
>>
>> That will work.  As long as the creator of file used four-space TABs,
>> anyway...
>
> I fail to see why less 'will work' but cat 'doesn't always work'.   
> The net
> effect of both is the same.  Unless you're in some weird place that  
> pipes
> aren't allowed, these should be equivalent:

I don't think that cat is the problem, it's sed.

The problem is that tabs take you to the next tab stop, they don't  
expand to a fixed number of spaces.

Consider the strings "\t\t", "\t \t", and "\t  \t". With everything  
except one- or two-space tab settings (less -x1 or less -x2), the  
spaces haven't moved us past a tab stop, so the \t after them takes  
us to the same tab stop in all cases.

Take care,

Bill
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFEa62XDJT2Egh26K0RAhFUAJ0WWgTRS570DsHAUl0oij47qNoIfgCgiVyV
9vZQUBAOspWLfuom2Scy4MY=
=wmWa
-END PGP SIGNATURE-
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code

[Edmond Dantes]

Oliver Bandel wrote:

> [EMAIL PROTECTED] opalinski from opalpaweb wrote:
...
> Yes, as I started programming I also preferred tabs.
> And with growing experience on how to handle this in true life
> (different editors/systems/languages...) I saw, that
> converting the "so fine tabs" was annoying.
> 
> The only thing that always worked were spaces.
> Tab: nice idea but makes programming an annoyance.
> 
> Ciao,
> Oliver

It all depends on your editor of choice. Emacs editing of Lisp (and a few
other languages, such as Python) makes the issue more or less moot. I
personally would recommend choosing one editor to use with all your
projects, and Emacs is wonderful in that it has been ported to just about
every platform imaginable. 

The real issue is, of course, that ASCII is showing its age and we should
probably supplant it with something better. But I know that will never fly,
given the torrents of code, configuration files, and everything else in
ASCII. Even Unicode couldn't put a dent in it, despite the obvious growing
global development efforts. Not sure how many compilers would be able to
handle Unicode source anyway. I suspect the large majority of them would
would choke big time.

Oh well...

-- 
-- Edmond Dantes, CMC
And Now for something Completely Different:
  http://gift-basket.prosperitysprinkler.com
  http://sewing-machine.womencraft.com
  http://coveralls.whiteboystuff.com
  http://eyewear.blackboystuff.com
  http://dinette.funiturenow.com
  http://wheels.whiteboystuff.com
  http://patio.funiturenow.com


 Posted Via Usenet.com Premium Usenet Newsgroup Services
--
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
--
http://www.usenet.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code ('semantic' vs. arbitrary indentation)

[Carl J. Van Arsdall]

glomde wrote:
>> 
>
> But If you work in a team it is kind of hard to make sure that
> everybody use tabs and not spaces. And it is not very easy to spot
> either. 
>   
The converse can also be said, "it's difficult to make sure everyone 
uses spaces and not tabs".

I think we've just about beat this discussion to death... nice work 
everyone!

-- 

Carl J. Van Arsdall
[EMAIL PROTECTED]
Build and Release
MontaVista Software

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code ('semantic' vs. arbitrary indentation)

[glomde]

> But generally, I don't do layout like that. I'd do:
>
>--->cursor.execute(
>--->--->--->'select id, item, amount, field4, 
>--->--->--->'from table1 where amount>100'
>--->)
>
>Which keeps looking fine, no matter what tab size, and without mixing
>tabs and spaces.
>
Which only works fine only if you are the one only editing the file.
But If you work in a team it is kind of hard to make sure that
everybody use tabs and not spaces. And it is not very easy to spot
either. The same is valid if somebody use your code or you
want to import somebody elses code.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs are EVIL *and* STUPID, end of discussion. (Re: Tabs versus Spaces in Source Code)

[Edward Elliott]

Dave Hansen wrote:

> On Wed, 17 May 2006 17:28:26 GMT in comp.lang.python, Edward Elliott
>>Just for the sake of completeness:
>>
>>cat file |sed 's/\t//g'
> 
> That doesn't always work.  If you don't see why, you don't understand
> my objection to TAB characters in text files.
>
>>less -x4 file
> 
> That will work.  As long as the creator of file used four-space TABs,
> anyway...

I fail to see why less 'will work' but cat 'doesn't always work'.  The net
effect of both is the same.  Unless you're in some weird place that pipes
aren't allowed, these should be equivalent:

cat file |sed 's/\t//g' |less
less -x4 file

Now if you're talking about the conversion altering the data's semantics,
that's a separate issue that has nothing to do with unix utilities and
everything to do with the file formatting.  In that case, I'll simply refer
you to the rest of this thread for discussion.

-- 
Edward Elliott
UC Berkeley School of Law (Boalt Hall)
complangpython at eddeye dot net
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code ('semantic' vs. arbitrary indentation)

[Sybren Stuvel]

Dave Hansen enlightened us with:
> Assume the code was written by someone using 4-space tabs.  To them,
> the code is:
>
>def sqlcall():
>--->cursor.execute('select id, item, amount, field4, 
>--->--->--->--->...'from table1 where amount>100')
>
> (where ---> represents an 4-space tab and . represents a space)

That would be stupid indeed. It would indeed fix the tabstops at every
4 characters to keep the layout.

But generally, I don't do layout like that. I'd do:

--->cursor.execute(
--->--->--->'select id, item, amount, field4, 
--->--->--->'from table1 where amount>100'
--->)

Which keeps looking fine, no matter what tab size, and without mixing
tabs and spaces.

Just because people can use tabs to make things suck,
doesn't mean the tabs are evil.

Sybren
-- 
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself? 
 Frank Zappa
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code ('semantic' vs. arbitrary indentation)

[achates]

Dave Hansen wrote:
>However, to twist an observation I've read about C++, while it's
>clearly possible to use TABs in a sensible manner like this, it seems
>that no one does.

I think it's evident from this thread that quite a few people do that,
judging by the fact that my previous post explaining this was doubly
redundant by the time I got round to sending it.

Also we should remember that in Python, alignment only applies to
continuation lines and comments. Logical lines (the vast majority of
lines in a source file) can't be arbitraily aligned.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code ('semantic' vs. arbitrary indentation)

[achates]

Andy Sy wrote:

>def sqlcall():
>  cursor.execute('select id, item, amount, field4, field5, field6'+
>   'from table1 where amount>100')

Lines two and three (a continuation line) are both at a syntactic
indentation level of 1. Therefore they should both start with a tab.
(Though actually indentation is ignored for continuation lines so you
only need to preserve the indentation if you want alignment.)

Then you can add spaces to align the function arguments.

def sqlcall():
cursor.execute('select id, item, amount, field4, field5, field6'+
<---spaces>'from table1 where amount>100')

I prefer not to bother with alignment like this, but if you do want to
align things, you use spaces. Indenting is done with tabs; alignment
with spaces.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code ('semantic' vs. arbitrary indentation)

[Carl J. Van Arsdall]

Dave Hansen wrote:
> On Wed, 17 May 2006 12:02:46 -0700 in comp.lang.python, "Carl J. Van
> Arsdall" <[EMAIL PROTECTED]> wrote:
>
>   
>> Andy Sy wrote:
>> 
>>> Carl J. Van Arsdall wrote:
>>>
>>>   
>>>   
> Next major objection then, how can one practically use 'tabs as
> semantic indentation' without screwing up formatting of code like
> the below??
>
>
>   def sqlcall():
>   cursor.execute('select id, item, amount, field4, field5, field6'+
>  'from table1 where amount>100')
>
>   
>   
>   
 Why couldn't you tab your third line over as close as possible to the 
 start of the quote then use a couple spaces?  Then the tabs would work 
 just fine and you could still have your pretty line.
 
 
>>> This will break if someone tries to view my code using different
>>> tab settings from the one I'm using
>>>   
>>>   
>> Uh, no it won't.  It should be read in as "one tab and two spaces" 
>> regardless of the tabstop setting.
>> 
>
> Think about it a little harder.  What does that "one tab" mean?
>
> Assume the code was written by someone using 4-space tabs.  To them,
> the code is:
>
>def sqlcall():
>--->cursor.execute('select id, item, amount, field4, 
>--->--->--->--->...'from table1 where amount>100')
>
> (where ---> represents an 4-space tab and . represents a space)
>
> Which looks fine.  But if I then load the code into my editor with
> 3-space tabs, it looks like:
>
>def sqlcall():
>-->cursor.execute('select id, item, amount, field4, 
>-->-->-->-->...'from table1 where amount>100')
>
> Then my colleage loads it into his editor with 8-space tabs, and it
> looks like (assuming I didn't change it to make it look reasonable):
>
>def sqlcall():
>--->cursor.execute('select id, item, amount, field4, 
>--->--->--->--->...'from table1 where amount>100')
>
>   
Ah, good point.  I was referring to it "breaking code".  It may look 
different (which I know invalidates my original point), but it certainly 
doesn't break code. 
I don't really use multiline strings in my code, but I find when working 
with other people I prefer the tab method.  For nothing else other than 
"my indent is 2 whereas my coworker's is 4" and the use of tabs allows 
us to throw things around much more easily without either of us having 
to compromise on personal preference.

.c

-- 

Carl J. Van Arsdall
[EMAIL PROTECTED]
Build and Release
MontaVista Software

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs are EVIL *and* STUPID, end of discussion. (Re: Tabs versus Spaces in Source Code)

[achates]

Dave Hansen wrote:

>That will work.  As long as the creator of file used four-space TABs,
>anyway...

That sentence has no meaning. There is no such thing as a four-space
tab.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code ('semantic' vs. arbitrary indentation)

[Dave Hansen]

On Wed, 17 May 2006 12:02:46 -0700 in comp.lang.python, "Carl J. Van
Arsdall" <[EMAIL PROTECTED]> wrote:

>Andy Sy wrote:
>> Carl J. Van Arsdall wrote:
>>
>>   
 Next major objection then, how can one practically use 'tabs as
 semantic indentation' without screwing up formatting of code like
 the below??


   def sqlcall():
   cursor.execute('select id, item, amount, field4, field5, field6'+
  'from table1 where amount>100')

   
   
>>> Why couldn't you tab your third line over as close as possible to the 
>>> start of the quote then use a couple spaces?  Then the tabs would work 
>>> just fine and you could still have your pretty line.
>>> 
>>
>>
>> This will break if someone tries to view my code using different
>> tab settings from the one I'm using
>>   
>Uh, no it won't.  It should be read in as "one tab and two spaces" 
>regardless of the tabstop setting.

Think about it a little harder.  What does that "one tab" mean?

Assume the code was written by someone using 4-space tabs.  To them,
the code is:

   def sqlcall():
   --->cursor.execute('select id, item, amount, field4, 
   --->--->--->--->...'from table1 where amount>100')

(where ---> represents an 4-space tab and . represents a space)

Which looks fine.  But if I then load the code into my editor with
3-space tabs, it looks like:

   def sqlcall():
   -->cursor.execute('select id, item, amount, field4, 
   -->-->-->-->...'from table1 where amount>100')

Then my colleage loads it into his editor with 8-space tabs, and it
looks like (assuming I didn't change it to make it look reasonable):

   def sqlcall():
   --->cursor.execute('select id, item, amount, field4, 
   --->--->--->--->...'from table1 where amount>100')

In each case the second line has four TABs and three spaces.  But only
with the original TAB settings does it line up properly.

The only solution (as posted elsewhere) is to somehow enforce tabs for
indentation and spaces for spacing:

   def sqlcall():
   --->cursor.execute('select id, item, amount, field4, 
   --->...'from table1 where amount>100')

However, to twist an observation I've read about C++, while it's
clearly possible to use TABs in a sensible manner like this, it seems
that no one does.  Or at least, it doesn't last much beyond the
original author of the code...

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code ('semantic' vs. arbitrary indentation)

[Carl J. Van Arsdall]

Andy Sy wrote:
> Carl J. Van Arsdall wrote:
>
>   
>>> Next major objection then, how can one practically use 'tabs as
>>> semantic indentation' without screwing up formatting of code like
>>> the below??
>>>
>>>
>>>   def sqlcall():
>>>   cursor.execute('select id, item, amount, field4, field5, field6'+
>>>  'from table1 where amount>100')
>>>
>>>   
>>>   
>> Why couldn't you tab your third line over as close as possible to the 
>> start of the quote then use a couple spaces?  Then the tabs would work 
>> just fine and you could still have your pretty line.
>> 
>
>
> This will break if someone tries to view my code using different
> tab settings from the one I'm using
>   
Uh, no it won't.  It should be read in as "one tab and two spaces" 
regardless of the tabstop setting.

.c


-- 

Carl J. Van Arsdall
[EMAIL PROTECTED]
Build and Release
MontaVista Software

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs are EVIL *and* STUPID, end of discussion. (Re: Tabs versus Spaces in Source Code)

[Dave Hansen]

On Wed, 17 May 2006 17:28:26 GMT in comp.lang.python, Edward Elliott
<[EMAIL PROTECTED]> wrote:

>Sybren Stuvel wrote:
>
>> Andy Sy enlightened us with:
>>> Like I said, you'll *NEVER* get that fancy shmancy 'semantic
>>> indentation' idea to work properly in the most basic utilities which
>>> have the 8-space tabs assumption hardcoded in them.
>> 
>> Fair enough. How much code is viewed with less and cat, and how much
>> is viewed using smart viewers/editors? I think the majority is viewed
>> using the latter.
>
>Just for the sake of completeness:
>
>cat file |sed 's/\t//g'

That doesn't always work.  If you don't see why, you don't understand
my objection to TAB characters in text files.

>less -x4 file

That will work.  As long as the creator of file used four-space TABs,
anyway...

Regards,
-=Dave

-- 
Change is inevitable, progress is not.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code ('semantic' vs. arbitrary indentation)

[Andy Sy]

Carl J. Van Arsdall wrote:

>> Next major objection then, how can one practically use 'tabs as
>> semantic indentation' without screwing up formatting of code like
>> the below??
>>
>>
>>   def sqlcall():
>>   cursor.execute('select id, item, amount, field4, field5, field6'+
>>  'from table1 where amount>100')
>>
>>   
> Why couldn't you tab your third line over as close as possible to the 
> start of the quote then use a couple spaces?  Then the tabs would work 
> just fine and you could still have your pretty line.


This will break if someone tries to view my code using different
tab settings from the one I'm using.



-- 
It's called DOM+XHR and it's *NOT* a detergent!

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code (semantic vs. arbitrary indentation)

[Andy Sy]

Ed Singleton wrote:

> On 5/15/06, Brian Quinlan <[EMAIL PROTECTED]> wrote:
>> The problem with tabs is that people use tabs for alignment e.g.
>>
>> def foo():
>>->query = """SELECT *
>>->  ->  ->   FROM sometable
>>->  ->  ->   WHERE condition"""
>>
>> Now I change my editor to use 8-space tabs and the code is all messed
>> up. Of course, a very disciplined group of people could be trained to
>> never use tabs except to align with the current block level but, in
>> practice, that doesn't work. Therefore tabs are bad.
> 
> def foo():
>->query = """SELECT *
>-> ...FROM sometable
>-> ...WHERE condition"""
> 
> That would solve it.  Tabs for indentation, spaces for spacing.
> 
> Ed

Ok, this is a somewhat workable solution.

Cons:

1) You have to be more conscientious regarding how many tabs
   you use at the beginning of a line.  If your text editor
   does not display tabs explicitly (SciTE can), it can be
   a *REAL* hassle.

2) Because you have to use all pure spaces after the proper
   # of tabs, you will often end up having to type a lot
   of them compared to if your tab key generated pure spaces.


Pro:

1) Happily, you do get your 'semantic indentation' so people can
   dynamically change the indentation-size they want to view your
   code with.



You do need everyone to understand 1 thing: NEVER use tab characters
(and consequently the tab key) for anything EXCEPT semantic indentation.


Big question though: is the above guaranteed to work nicely in all
situations in python?


Also, in free-format languages like C, Java, C#, the temptation to mix
semantic and arbitrary indentation might be just too great for sloppy
programmers.



If anyone wants to use tabs, I think the above is the ONLY right way
to use them and it also happily eliminates any arguments over how
many spaces you should use for your tab setting.


If ALL tab users followed this convention, I will happily consider
myself agnostic... ;-)



Now, on to the next holy war... date formats


ANY OTHER FORMAT BESIDES ISO MMDD (but it's ok to put dashes
in between or use word MMM instead of numerical MM) IS *EVIL* AND
*MISGUIDED*!


-- 
It's called DOM+XHR and it's *NOT* a detergent!

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code ('semantic' vs. arbitrary indentation)

[Carl J. Van Arsdall]

Andy Sy wrote:
> achates wrote:
>
>   
>> Andy Sy:
>> 
>>> Code with anything other than 8-space tabs will *NEVER* display
>>> properly using everyday unix utilities such as less and cat.
>>>   
>> less -x does what you want.
>>
>> 
>
>
> Ok, that tip certainly counts for something.  This is
> definitely going to make viewing tabbed code suck much
> less (although you still have to guess the tab setting
> using trial and error).
>
>
> Next major objection then, how can one practically use 'tabs as
> semantic indentation' without screwing up formatting of code like
> the below??
>
>
>   def sqlcall():
>   cursor.execute('select id, item, amount, field4, field5, field6'+
>  'from table1 where amount>100')
>
>   
Why couldn't you tab your third line over as close as possible to the 
start of the quote then use a couple spaces?  Then the tabs would work 
just fine and you could still have your pretty line.

.c

-- 

Carl J. Van Arsdall
[EMAIL PROTECTED]
Build and Release
MontaVista Software

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code ('semantic' vs. arbitrary indentation)

[Andy Sy]

achates wrote:

> Andy Sy:
>> Code with anything other than 8-space tabs will *NEVER* display
>> properly using everyday unix utilities such as less and cat.
> 
> less -x does what you want.
> 


Ok, that tip certainly counts for something.  This is
definitely going to make viewing tabbed code suck much
less (although you still have to guess the tab setting
using trial and error).


Next major objection then, how can one practically use 'tabs as
semantic indentation' without screwing up formatting of code like
the below??


  def sqlcall():
  cursor.execute('select id, item, amount, field4, field5, field6'+
 'from table1 where amount>100')


... if you change the tabsize then the 3rd line will no longer
properly align with the start of the quote in the 2nd line.
The 3rd line makes use of _arbitrary_, not semantic indentation.


Because you cannot count on indentation to be semantics-driven on every
single line, you _will_ end up mixing semantic and arbitrary indentation
and thus the whole notion of being able to use tabs as 'semantic
indentation' is *still untenable*.

There is JUST NO PRACTICAL USE FOR TABS.




-- 
It's called DOM+XHR and it's *NOT* a detergent!

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code

[63q2o4i02]

I use Edit Plus for all my text-editing needs.  With a simple
shift-alt-i it faintly displays all spaces as little dots and all tabs
as '>>' (but using the single ascii character instead).  I use tabs to
indent blocks, then if stuff within a block needs to be aligned (such
as if statements or dictionaries), I used spaces.  So this is mixing
tabs and spaces, but the indentation level is always tabs.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs are EVIL *and* STUPID, end of discussion. (Re: Tabs versus Spaces in Source Code)

[Edward Elliott]

Sybren Stuvel wrote:

> Andy Sy enlightened us with:
>> Like I said, you'll *NEVER* get that fancy shmancy 'semantic
>> indentation' idea to work properly in the most basic utilities which
>> have the 8-space tabs assumption hardcoded in them.
> 
> Fair enough. How much code is viewed with less and cat, and how much
> is viewed using smart viewers/editors? I think the majority is viewed
> using the latter.

Just for the sake of completeness:

cat file |sed 's/\t//g'
less -x4 file

vim ~/bin.cat
#!/bin/sh
cat "$@" |sed 's/\t//g'
:wq
alias less='less -x4'

-- 
Edward Elliott
UC Berkeley School of Law (Boalt Hall)
complangpython at eddeye dot net
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code

[Edward Elliott]

achates wrote:

> Jorge Godoy wrote
> 
>>Emacs guess what's used in the file and allows me to use tabs all the
>>time, doing the correct thing...
> 
> That sounds like useful behaviour.

vim can do it to.

http://www.vim.org/scripts/script.php?script_id=1171

-- 
Edward Elliott
UC Berkeley School of Law (Boalt Hall)
complangpython at eddeye dot net
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs are EVIL *and* STUPID, end of discussion. (Re: Tabs versus Spaces in Source Code)

[achates]

Andy Sy:
>Code with anything other than 8-space tabs will *NEVER* display
>properly using everyday unix utilities such as less and cat.

less -x does what you want.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs are EVIL *and* STUPID, end of discussion. (Re: Tabs versus Spaces in Source Code)

[Carl J. Van Arsdall]

Sybren Stuvel wrote:
> Andy Sy enlightened us with:
>   
>> Like I said, you'll *NEVER* get that fancy shmancy 'semantic
>> indentation' idea to work properly in the most basic utilities which
>> have the 8-space tabs assumption hardcoded in them.
>> 
>
> Fair enough. How much code is viewed with less and cat, and how much
> is viewed using smart viewers/editors? I think the majority is viewed
> using the latter.
>   
Really though, he's got a good point.  I'm typically viewing code in 
vi.  I don't know why so many people have so many issues with tabs, they 
really aren't that difficult to work with and I think make life a little 
easier when working on code with multiple people.  You can setup your 
environment to make tabs look like you want your code to look, your team 
members can do tabs their way, and in the end the indentation levels all 
work out fine.

People want to fight tooth and nail over this debate.  But its really 
not worth it.  Get an editor that doesn't completely suck and you won't 
have problems.

.c

-- 

Carl J. Van Arsdall
[EMAIL PROTECTED]
Build and Release
MontaVista Software

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs are EVIL *and* STUPID, end of discussion. (Re: Tabs versus Spaces in Source Code)

[Sybren Stuvel]

Andy Sy enlightened us with:
> Like I said, you'll *NEVER* get that fancy shmancy 'semantic
> indentation' idea to work properly in the most basic utilities which
> have the 8-space tabs assumption hardcoded in them.

Fair enough. How much code is viewed with less and cat, and how much
is viewed using smart viewers/editors? I think the majority is viewed
using the latter.

Sybren
-- 
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself? 
 Frank Zappa
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs are EVIL *and* STUPID, end of discussion. (Re: Tabs versus Spaces in Source Code)

[Andy Sy]

Sybren Stuvel wrote:

>> then WHAT THE HECK do you need to use tab characters in the source
>> code for anyway (besides saving a measly few bytes) ??!?
>
> To separate layout (how much indentation is used) from semantics (how
> many intentation levels).

Like I said, you'll *NEVER* get that fancy shmancy 'semantic indentation'
idea to work properly in the most basic utilities which have the 8-space tabs
assumption hardcoded in them.

Code with anything other than 8-space tabs will *NEVER* display
properly using everyday unix utilities such as less and cat.  But then,
8-space tabs are just too wide to be practical, thus the simple
conclusion I have reached: JUST STOP USING THEM.

Heck, all those who actually believe that make's requirement of an
invisible tab as a 'semantic' marker was a good idea raise their
hands...!  


>> Tab characters are EVIL *AND* STUPID.
>
> And someone who needs to resort to all-caps words (which many consider
> shouting) needs to relax and use proper arguments.

I know when I'll be able to relax... when I no longer need to waste time
dealing with those stupid tabs in source code!!!

;-)




-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs are *EVIL* AND *STUPID*, NOT 'misunderstood' (Re: Tabs versus Spaces in Source Code)

[Andy Sy]

achates wrote:
> Andy Sy
> 
>> I guess this *REALLY* is how a misguided tab user exercises his 'logic':
>> Syntax replication (e.g. so-called 'argument construction') is enough,
>> semantics don't matter.
> 
> That's quite amusing.. you've unwittingly stumbled on a pretty concise
> statement of Hilbert's first postulate of formal logic, proved by Godel
> in 1930..
> 
>> ROTFLMAO!
> 
> Indeed.

Too bad that only applies to /statements phrased in formal
logic/, not to everyday statements expressed in a human language.

Only someone who has run out of sensible arguments or a disingenuous
sophist would try to extend this so-called postulate the way Peter
and you did.

Really... if you *actually* believed that Peter's argument had merit
and he was not merely being facetious, I guess I rest my case
regarding tab users and their 'logical prowess'.


LMAO again.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs are *MISUNDERSTOOD*, *EVIL* AND *STUPID*, end of discussion. (Re: Tabs versus Spaces in Source Code)

[achates]

Andy Sy

>I guess this *REALLY* is how a misguided tab user exercises his 'logic':
>Syntax replication (e.g. so-called 'argument construction') is enough,
>semantics don't matter.

That's quite amusing.. you've unwittingly stumbled on a pretty concise
statement of Hilbert's first postulate of formal logic, proved by Godel
in 1930..

>ROTFLMAO!

Indeed.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs are *MISUNDERSTOOD*, *EVIL* AND *STUPID*, end of discussion. (Re: Tabs versus Spaces in Source Code)

[Peter Decker]

On 5/17/06, Andy Sy <[EMAIL PROTECTED]> wrote:

> > Uh, I should know better than to try to educate, but FYI: using the
> > same argument construction and having it reach an invalid conclusion
> > suffices to show that the original construction is invalid, and thus
> > the original conclusion is suspect.
>
>
> I guess this *REALLY* is how a misguided tab user exercises his 'logic':
> Syntax replication (e.g. so-called 'argument construction') is enough,
> semantics don't matter.
>
> ROTFLMAO!

My instincts were correct: it is foolhardy to attempt to educate closed minds.



-- 

# p.d.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs are *MISUNDERSTOOD*, *EVIL* AND *STUPID*, end of discussion. (Re: Tabs versus Spaces in Source Code)

[Andy Sy]

Peter Decker wrote:

> On 5/17/06, Andy Sy <[EMAIL PROTECTED]> wrote:
>> Peter Decker wrote:
>>> On 5/17/06, Andy Sy <[EMAIL PROTECTED]> wrote:
>>>
 If tabs are easily misunderstood, then they are a MISfeature
 and they need to be removed.
>>> I don't seem to understand your point in acting as a dictator.
>>> Therefore, you are a MISfeature and need to be removed.
>> Is the above an example of how a tab-user exercises 'logic'...?
> 
> Uh, I should know better than to try to educate, but FYI: using the
> same argument construction and having it reach an invalid conclusion
> suffices to show that the original construction is invalid, and thus
> the original conclusion is suspect.


I guess this *REALLY* is how a misguided tab user exercises his 'logic':
Syntax replication (e.g. so-called 'argument construction') is enough,
semantics don't matter.

ROTFLMAO!


-- 
It's called DOM+XHR and it's *NOT* a detergent!

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code

[Peter Decker]

On 17 May 2006 07:14:33 -0700, Bill Pursell <[EMAIL PROTECTED]> wrote:

> I think you unfairly snipped context on me.  I was directly responding
> to the assertion that vi is unable to handle tabs well.

I was *agreeing* with you. Sorry if that wasn't clear.

-- 

# p.d.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs are *MISUNDERSTOOD*, *EVIL* AND *STUPID*, end of discussion. (Re: Tabs versus Spaces in Source Code)

[Peter Decker]

On 5/17/06, Andy Sy <[EMAIL PROTECTED]> wrote:
> Peter Decker wrote:
> > On 5/17/06, Andy Sy <[EMAIL PROTECTED]> wrote:
> >
> >> If tabs are easily misunderstood, then they are a MISfeature
> >> and they need to be removed.
> >
> > I don't seem to understand your point in acting as a dictator.
> > Therefore, you are a MISfeature and need to be removed.
>
> Is the above an example of how a tab-user exercises 'logic'...?

Uh, I should know better than to try to educate, but FYI: using the
same argument construction and having it reach an invalid conclusion
suffices to show that the original construction is invalid, and thus
the original conclusion is suspect.

-- 

# p.d.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs are EVIL *and* STUPID, end of discussion. (Re: Tabs versus Spaces in Source Code)

[Sybren Stuvel]

Andy Sy enlightened us with:
> Now... if you say you SHOULDN'T mix tabs and spaces (indeed this is
> generally regarded as a BAD idea esp. in Python code)

I indeed say so.

> then WHAT THE HECK do you need to use tab characters in the source
> code for anyway (besides saving a measly few bytes) ??!?

To separate layout (how much indentation is used) from semantics (how
many intentation levels).

> Tab characters are EVIL *AND* STUPID.

And someone who needs to resort to all-caps words (which many consider
shouting) needs to relax and use proper arguments.

Sybren
-- 
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself? 
 Frank Zappa
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code

[Andy Sy]

Peter Decker wrote:

> Spaces look like crap, too, when using proportional fonts.

... and people who would even think that using proportional
fonts for viewing/editing source code is anywhere remotely
near being a good idea ...

That's an even more advanced version of the i-think-tabs-are-good
disease... LOL!

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code

[Bill Pursell]

Peter Decker wrote:
> On 17 May 2006 06:51:19 -0700, Bill Pursell <[EMAIL PROTECTED]> wrote:
>
> > In my experience, the people who complain about the use
> > of tabs for indentation are the people who don't know
> > how to use their editor, and those people tend to use
> > emacs.
>
> In my experience, whenever there is a 'religious' issue like this, one
> side tends to be quick to pronounce the other as 'evil', and insist
> that everyone do things their way, while the other tends to feel
> comfortable with people having their own preferences. If I ever find
> myself on the side of the former, I always wonder if I'm missing
> something obvious.

I think you unfairly snipped context on me.  I was directly responding
to the assertion that vi is unable to handle tabs well.

As far as tabs vs. spaces, I don't think the spacers are evil, and in
fact I am one for pragmatic reasons.  I would much prefer to use
tabs for indentation, especially since in the last few weeks I've
decided to upgrade from 4 to 8, and now all of my spaced code
requires much more effort than ":ts=8" to fix.   But in today's world,
it's easier to go with the flow and use spaces.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code

[Roy Smith]

Peter Decker <[EMAIL PROTECTED]> wrote:
>In my experience, whenever there is a 'religious' issue like this, one
>side tends to be quick to pronounce the other as 'evil', and insist
>that everyone do things their way,

I don't think people who use tabs are evil.  They may be ignorant and
misguided, but they can still have the potential to be saved though
education and persuasion :-)

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs are *MISUNDERSTOOD*, *EVIL* AND *STUPID*, end of discussion. (Re: Tabs versus Spaces in Source Code)

[Andy Sy]

Peter Decker wrote:
> On 5/17/06, Andy Sy <[EMAIL PROTECTED]> wrote:
>
>> If tabs are easily misunderstood, then they are a MISfeature
>> and they need to be removed.
>
> I don't seem to understand your point in acting as a dictator.
> Therefore, you are a MISfeature and need to be removed.

Is the above an example of how a tab-user exercises 'logic'...?


Besides, I'm not the only dictator here... there are also the:

4-space tabs dictators...
8-space tabs dictators...
etc...




-- 
It's called DOM+XHR and it's *NOT* a detergent!

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code

[Peter Decker]

On 17 May 2006 06:51:19 -0700, Bill Pursell <[EMAIL PROTECTED]> wrote:

> In my experience, the people who complain about the use
> of tabs for indentation are the people who don't know
> how to use their editor, and those people tend to use
> emacs.

In my experience, whenever there is a 'religious' issue like this, one
side tends to be quick to pronounce the other as 'evil', and insist
that everyone do things their way, while the other tends to feel
comfortable with people having their own preferences. If I ever find
myself on the side of the former, I always wonder if I'm missing
something obvious.

-- 

# p.d.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code

[achates]

Jorge Godoy wrote

>Emacs guess what's used in the file and allows me to use tabs all the time,
>doing the correct thing...

That sounds like useful behaviour.

Maybe this is an area where modern editors might be able to save us
from ourselves. I'll admit I'm suspicious of relying on editor
functionality - I'm happier if I know I can also use the old-school
methods just in case.. Sometimes adding intelligence to an interface
can be a usability disaster if it makes wrong assumptions about what
you want. But if people are hell-bent on converting tabs to spaces,
maybe it's the best way to accommodate them.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code

[Bill Pursell]

Xah Lee wrote:
> Tabs versus Spaces in Source Code
>
> Xah Lee, 2006-05-13
>
> In coding a computer program, there's often the choices of tabs or
> spaces for code indentation.

> (2) Due to the first reason, they have created and
> propagated a massive none-understanding and mis-use, to the degree that
> many tools (e.g. vi) does not deal with tabs well

:set ts=

Yeah, that's really tough.  vi does just fine handling tabs.  vim does
an even better job, with mode-lines, = and :retab.

In my experience, the people who complain about the use
of tabs for indentation are the people who don't know
how to use their editor, and those people tend to use 
emacs.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code

[Jorge Godoy]

achates wrote:

>>Hitting the spacebar like a madman? If you have a sensible editor then at
>>the start of a line you press tab once
> 
> True! but normally if I'm editing someone else's code then I'm only
> making small changes and so can't be bothered to temporarily cripple my
> editor. If I'm merging my code with someone else's space-indented code
> then piping through sed 's/TAB/SPACES' does the trick.

Emacs guess what's used in the file and allows me to use tabs all the time,
doing the correct thing...  Personally, I like using spaces, but I don't
have problems with files using tabs... 

-- 
Jorge Godoy  <[EMAIL PROTECTED]>

"Quidquid latine dictum sit, altum sonatur."
- Qualquer coisa dita em latim soa profundo.
- Anything said in Latin sounds smart.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs are *MISUNDERSTOOD*, *EVIL* AND *STUPID*, end of discussion. (Re: Tabs versus Spaces in Source Code)

[Peter Decker]

On 5/17/06, Andy Sy <[EMAIL PROTECTED]> wrote:

> If tabs are easily misunderstood, then they are a MISfeature
> and they need to be removed.

I don't seem to understand your point in acting as a dictator.
Therefore, you are a MISfeature and need to be removed.

-- 

# p.d.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs are EVIL *and* STUPID, end of discussion. (Re: Tabs versus Spaces in Source Code)

[Andy Sy]

achates wrote:

>> Andy Sy wrote:
>> Don't be evil - always configure your editor to
>> convert tabs to true spaces.
>
> Yet another space-indenter demonstrates that problem actually lies with
> people who think that tab == some spaces.

Wrong.  I am completely aware that an editor configured to
convert tabs to true spaces will not always replace a tab
into the same number of space characters.

If you understood what I meant you'd realize that it meant:  "Use the
tab key if you have to (4,8,3,2... whatever...), but /always/ have your
editor convert them to true spaces, so they can display properly -
*without need for tweaks* - on any display medium and on anyone's
program.

The fact that a tab character doesn't necessarily equal a constant
spaces is what makes things EVEN MORE CONFUSING.  Cheez... some
people just love complexity for its own sake...



What earthly benefit is there anyway to mixing tabs and spaces??!?

Now... if you say you SHOULDN'T mix tabs and spaces (indeed this is
generally regarded as a BAD idea esp. in Python code), then WHAT THE
HECK do you need to use tab characters in the source code for anyway
(besides saving a measly few bytes) ??!?


Tab characters are EVIL *AND* STUPID.


> Sorry to hear that. You should try using an editor that's easier for
> you.

I am *most certainly* NOT giving SciTE up... I've spent years and years
looking for the perfect editor, and I've found it with SciTE.  Scite and
all its cool features are NOT the problem.  One single thing is:

  Tab characters in source code popping up like so many unsightly zits.



-- 
It's called DOM+XHR and it's *NOT* a detergent!


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs are *MISUNDERSTOOD*, *EVIL* AND *STUPID*, end of discussion. (Re: Tabs versus Spaces in Source Code)

[Andy Sy]

If tabs are easily misunderstood, then they are a MISfeature
and they need to be removed.

>From the Zen of Python:

"Explicit is better than implicit..."
"In the face of ambiguity, refuse the temptation to guess..."
"Special cases aren't special enough to break the rules..."



--
It's called DOM+XHR and it's *NOT* a detergent!

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code

[Sybren Stuvel]

achates enlightened us with:
> True! but normally if I'm editing someone else's code then I'm only
> making small changes and so can't be bothered to temporarily cripple my
> editor. If I'm merging my code with someone else's space-indented code
> then piping through sed 's/TAB/SPACES' does the trick.

I just type 'retab' in my editor, and everything is fine. I use VIM,
which is great for tab/space management.

Sybren
-- 
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself? 
 Frank Zappa
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code

[achates]

>Hitting the spacebar like a madman? If you have a sensible editor then at
>the start of a line you press tab once

True! but normally if I'm editing someone else's code then I'm only
making small changes and so can't be bothered to temporarily cripple my
editor. If I'm merging my code with someone else's space-indented code
then piping through sed 's/TAB/SPACES' does the trick.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs are *MISUNDERSTOOD*, end of discussion. (Re: Tabs versus Spaces in Source Code)

[David Isaac]

> Andy Sy wrote:
> >Don't be evil - always configure your editor to
> >convert tabs to true spaces.



"achates" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Yet another space-indenter demonstrates that problem actually lies with
> people who think that tab == some spaces.


Exactly.

Cheers,
Alan Isaac


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code

[Duncan Booth]

achates wrote:

> It's horrible but at least it would insulate me from the greater
> hideousness of having to hit the spacebar like a madman at the start of
> every line of code. I can even see how to get it to work in vi at
> least.

Hitting the spacebar like a madman? If you have a sensible editor then at 
the start of a line you press tab once for each additional level of 
indentation and backspace once for each fewer level and neither if the 
indentation is guessed correctly by the editor.

in another post you suggested to someone else:

> Sorry to hear that. You should try using an editor that's easier for
> you.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code

[Nick Craig-Wood]

Ant <[EMAIL PROTECTED]> wrote:
>  I think Duncan has hit the nail on the head here really. I totally
>  agree that conceptually using tabs for indentation is better than using
>  spaces.

As a programmer tabs appeal to our sense of neatness in python code.
One tab for each level of indent - very nice.

Back in the last century when I wrote nothing but assembler in a
series of primitive text editors I would have agreed with you.  Tabs
rule!  label TAB opcode TAB arguments TAB ; comment.

> Pragmatically though, you can't tell in an editor where spaces
>  are used and where tabs are used.

Now-a-days when I am writing Python, I just use emacs which indents
perfectly.  I press tab and emacs inserts the correct of indentation.
Most of the time I don't have to press tab at all - emacs knows how
much indentation I need.

I don't actually care whether emacs inserts spaces or tabs (spaces
actually), it works, looks nice and follows PEP 8.  It's a lot less
keystrokes than writing assember too ;-)

If you are writing python using "cat" or "ed" then tabs might matter
again, but for any modern editor with a python mode it really doesn't
matter!

>  The following quote sums things up nicely I think:
> 
>  "In theory there is no difference between theory and practice, but in
>  practice there is."

;-)

-- 
Nick Craig-Wood <[EMAIL PROTECTED]> -- http://www.craig-wood.com/nick
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code

[Ant]

> Not that it's relevant, but I've never actually encountered anyone who
> mixed tabs and spaces.. I've lived a sheltered life I guess.

It's not individuals using a mixture, but when working in a development
team of some kind. Consider person A who writes a file using spaces for
indent. Person B then edits that file, adding a few lines of code,
indenting using tabs. It could soon get messy!

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code

[Ant]

> Ant wrote:
> > spaces. Pragmatically though, you can't tell in an editor where spaces
> > are used and where tabs are used.

> Um, I don't follow this.  If you can't tell the editor where
> tabs/spaces are used, who does?

Re-read my post. Note the key word 'in'.

> > Perhaps if editors colored the background of tab characters differently
> > from spaces this wouldn't be a problem,

> Some editors do.

Some isn't nearly good enough to solve the problem.

> python -tt

Not the default behaviour, and so not good enough for tabs to be a good
indent character.

> > In reality, neither of these are likely
> > to be implemented any time soon!
>
> um

OK. Widely implemented and default behaviour.

Your points are fine if you are working by yourself (hell you could use
Perl and it wouldn't matter ;-) ), but in for example an open source
project where work is distributed over developers working in vastly
different environments, tabs currently aren't a workable option.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs are *EVIL*, end of discussion. (Re: Tabs versus Spaces in Source Code)

[achates]

Andy Sy wrote:

>Don't be evil - always configure your editor to
>convert tabs to true spaces.

Yet another space-indenter demonstrates that problem actually lies with
people who think that tab == some spaces.

>And I, for the life of me, have never remembered
>getting any source code to display properly by
>fiddling with my text editor's (the very popular
>SciTE) tab settings.

Sorry to hear that. You should try using an editor that's easier for
you.

By the way, complaining about a thread's existence is pretty dumb. If
you don't like it, don't post to it. Or are you unable to operate your
news reader either?

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code

[achates]

Iain King wrote:

>python -tt

Indeed. I reckon the consensus here (to the extent that there is any!)
is that it would be better if this was Python's default behaviour.

The argument (not advanced by Iain but by others in this thread) that:
novices will mix tabs and spaces => we should all use spaces only
is clearly false by symmetry.

An alternative solution to this issue would be to write an editor
plugin which converted between space-indented and tab-indented Python
source files on opening *and back again* on writing or closing. Then we
would have:

Case 1: you send me a space-indented file.
My editor opens the file, finds that it is space-indented,
calculates the indentation level of each line and converts it to the
corresponding number of tabs, and then writes that to a temporary file
which it then displays for editing. On writing, it converts indentation
back to spaces and writes to the original file.

Case 2: I send you a tab-indented file.
As Case 1 with s/tab/space/; s/My/Your/

Case 3: You send me a file with mixed tab/space indentation
Everything borks, as it should.

It's horrible but at least it would insulate me from the greater
hideousness of having to hit the spacebar like a madman at the start of
every line of code. I can even see how to get it to work in vi at
least.

Just trying to be constructive!

Not that it's relevant, but I've never actually encountered anyone who
mixed tabs and spaces.. I've lived a sheltered life I guess.

-- 
http://mail.python.org/mailman/listinfo/python-list

Tabs are *EVIL*, end of discussion. (Re: Tabs versus Spaces in Source Code)

[Andy Sy]

Please... just stop this senseless defense of
a Rube-Goldberg feature.

There will NEVER be a universal agreement on
whether tabs should be 2, 3, 4 or 8 spaces in
width, and this causes endless tweaking of editor
settings (a *humongous* waste of time) to handle
source code made by other programmers with different
settings.

And I, for the life of me, have never remembered
getting any source code to display properly by
fiddling with my text editor's (the very popular
SciTE) tab settings.

4, 8, 3, 2, it doesn't matter.  *Nothing* has ever
made someone's tab-infested source code display
completely cleanly.  Nearly a third of my coding
time seems to have been spent (read:wasted) trying
to reformat some unenlightened tab user's source code
to read comprehensibly.



1. Tabs as 8 spaces just take up too much horizontal area

2. But you can't use any other value because if you do,
   you will screw up display using cat/less/more !!

DOES ANYONE NEED ANY REASON MORE COMPLICATED THAN THE ABOVE TO
JUST *NOT* USE TABS??!???!??!!!??

Don't be evil - always configure your editor to
convert tabs to true spaces.



-- 
It's called DOM+XHR and it's *NOT* a detergent!

-- 
http://mail.python.org/mailman/listinfo/python-list

Tabs are evil, end of discussion. (Re: Tabs versus Spaces in Source Code)

[Andy Sy]

Harry George wrote:

> This has been discussed repeatedly, and the answer is "If you only
> work alone, never use anyone else's code and no one ever uses your
> codes, then do as you please.  Otherwise use tab-is-4-spaces."
> 
> When you do Agile Programming with people using emacs, vim, nedit,
> xedit, wordpad, eclipse, and who knows what else, the 4-spaces rule is
> necessary for survival.
> 
> The reason is simple: People get confused, and accidentally get the
> wrong tab indents when they move among editors or among settings on
> the same editor.  In most languages this is an irritation, requiring
> some cleanup.  In Python it is a disaster requiring re-inventing the
> coded algorithms.

1. Tabs as 8 spaces just take up way too much horizontal
   space, so you can't use 8-space tabs...

2. BUT... you can't use any other value (not even 4)... !!

   WHY??

   Because if you do, you will screw up display using /something
   as basic as cat, less, more (and many other unix utilities
   where the historical assumption that tabs are 8 spaces
   is hardcoded)!


DOES ANYONE NEED ANY REASON MORE COMPLICATED THAN THE ABOVE TO
JUST *NOT* USE TABS??


Yet ANOTHER proof that tabs are evil:

3. If tabs weren't around, we wouldn't have all these
   time-wasting threads on tabs vs. spaces, or on how many
   spaces a tab should represent.


Tabs were an unnecessary Rube Goldberg invention misguidedly
carried over from the typewriter era.  They are the appendix
of text editors.  Just because they're there doesn't necessarily
mean they serve any (even remotely) useful purpose.


-- 
It's called DOM+XHR and it's *NOT* a detergent!

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code

[Iain King]

Ant wrote:
> I think Duncan has hit the nail on the head here really. I totally
> agree that conceptually using tabs for indentation is better than using
> spaces. Pragmatically though, you can't tell in an editor where spaces
> are used and where tabs are used.
>

Um, I don't follow this.  If you can't tell the editor where
tabs/spaces are used, who does?

> Perhaps if editors colored the background of tab characters differently
> from spaces this wouldn't be a problem,

Some editors do.

> or if Python was more
> restrictive and did not actually allow a mix of tabs and spaces for
> indentation there would be no problem - the compiler could throw out an
> exception for mixed characters.

python -tt

> In reality, neither of these are likely
> to be implemented any time soon!

um

Iain

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code

[Ant]

I think Duncan has hit the nail on the head here really. I totally
agree that conceptually using tabs for indentation is better than using
spaces. Pragmatically though, you can't tell in an editor where spaces
are used and where tabs are used.

Perhaps if editors colored the background of tab characters differently
from spaces this wouldn't be a problem, or if Python was more
restrictive and did not actually allow a mix of tabs and spaces for
indentation there would be no problem - the compiler could throw out an
exception for mixed characters. In reality, neither of these are likely
to be implemented any time soon!

The following quote sums things up nicely I think:

"In theory there is no difference between theory and practice, but in
practice there is."

(No idea where I got that from BTW - someone's tag-line probably)

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code

[Sybren Stuvel]

Duncan Booth enlightened us with:
> It is strange. You use many of the same words as me, but they don't make 
> any sense.

You forgot to add "to me" to the end of that sentence. Personally,
Achates' words made perfect sense to me.

> The point is about separating the presentation of the source file
> from the semantic content. When displaying the file you can choose
> to expand tabs to any suitable positions. These may be evenly spaced
> every n characters, or may vary across the page.

True.

> However the important thing is that a tab does not map to a single
> indentation level in Python: it can map to any number of indents,

True, but doesn't the same hold for spaces? An indent level can be
made from any number of spaces. You could use two spaces to indent a
class' contents, four for functions, and two again for loops.

> and unless I know the convention you are using to display the tabs I
> cannot know how many indents are equivalent to a tabstop.

That is only true if you mix spaces and tabs. If you use only tabs OR
only spaces to indent, everything is perfectly clear.

>> Seriously people, this is about separating the content of a source
>> file from how it is displayed. It's about letting people work
>> together while also allowing them to have control over their own
>> environments, something which is and always has been central to the
>> hacker ethos.
>
> Precisely. Using spaces everywhere allows this

No it doesn't! I have tabstops every four characters, which is a
pleasant indent level for me. Other people have trouble reading the
code that way, and want two or eight character wide indents. When
using tabs, everybody can place the tabstops for themselves, and as
long as tabstop N is more to the left than tabstop N+1, everything is
fine. By using spaces, the writer of the code determines the size of
the indentation, not the viewer. Since code is generally read more
than it is written, the viewer is quite important.

Sybren
-- 
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself? 
 Frank Zappa
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code

[Sybren Stuvel]

Duncan Booth enlightened us with:
> In particular a common convention is to have indentations at 4
> spaces and tabs expanding to 8 spaces.

Aaaw that is SO ugly! Sure, it displays correctly on systems that have
tab stops every 8 spaces given a monospaced font, but that is about
all that is positive about that.

Sybren
-- 
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself? 
 Frank Zappa
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code

[Duncan Booth]

achates wrote:

> Duncan Booth wrote:
> 
>>However the important thing is that a tab does
>>not map to a single indentation level in Python: it can map to any
>>number of indents, and unless I know the convention you are using to
>>display the tabs I cannot know how many indents are equivalent to a
>>tabstop. 
> 
> Sorry but this is just wrong. Python works out the indentation level
> for a source file dynamically: see
> http://docs.python.org/ref/indentation.html. The particular algorithm
> it uses is designed to accommodate people who mix tabs and spaces
> (which is unfortunate, and should probably be changed). Nevertheless,
> using tabs only, one tab does indeed map to exactly one indentation
> level. One tabstop == one indent, on your editor and on mine.

Please be careful how much you trim. I also wrote:

> Using spaces everywhere allows this, using tabs everywhere 
> allows this, mixing spaces and tabs is a bad thing.

Yes, if you use tabs only tabs map to exactly one indentation level, but
as soon as there is a mix it breaks horrible. The problem arises because
in most situations there is no visual distinction between tabs and
spaces so it isn't obvious when there is an accidental mix until things
break. 

Fortunately Python is reasonably robust, and in most cases you will get
a syntax error instead of a silent change to the meaning of the code. 

> You do not need to know my display convention to run my code.

The Python interpreter does not know your display convention either: it
assumes that tabs expand to 8 character boundaries. So long as you have
pure tabs this doesn't matter, but if there is any mixing it means that
any editor set to expand tabs to a different width will no longer
display the indentation as the interpreter sees it.

The problem is that although you are a tab purist (as I am a space purist), 
too many people out there are neither. If you set an editor to only insert 
spaces then it is unlikely to accidentally insert tabs, but if the editor 
is set up to do indentation with tabs then a naive user is still likely to 
use the space bar occasionally and then wonders why Python is complaining 
about an error when they can see (with their 4 space indents) that 
everything is indented correctly.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code

[Aaron Gray]

I was once a religous tabber until working on multiple source code sources, 
now I am a religious spacer :)

My 2bits worth,

Aaron


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code

[achates]

Duncan Booth wrote:

>However the important thing is that a tab does
>not map to a single indentation level in Python: it can map to any number
>of indents, and unless I know the convention you are using to display the
>tabs I cannot know how many indents are equivalent to a tabstop.

Sorry but this is just wrong. Python works out the indentation level
for a source file dynamically: see
http://docs.python.org/ref/indentation.html. The particular algorithm
it uses is designed to accommodate people who mix tabs and spaces
(which is unfortunate, and should probably be changed). Nevertheless,
using tabs only, one tab does indeed map to exactly one indentation
level. One tabstop == one indent, on your editor and on mine. You do
not need to know my display convention to run my code.

All I can suggest is that you try it out: create a short source file
indented with tabs only, and play around with your editor's tabstop
setting (and make sure it is writing tab characters, not spaces, to the
source file). I promise you the Python interpreter will neither know
nor care what your editor display settings were when you last wrote the
file.

I realise that a lot of code out there uses spaces only. That's
unfortunate, but it doesn't mean we should stop explaining to people
why tab-indenting is a better standard. This is about freedom:
indenting with spaces lets you control over how other people view your
code; indenting with tabs give them that control.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code

[Kaz Kylheku]

achates wrote:
> Kaz Kylheku wrote:
>
> > If you want to do nice typesetting of code, you have to add markup
> > which has to be stripped away if you actually want to run the code.
>
> Typesetting code is not a helpful activity outside of the publishing
> industry.

Be that as it may, code writing involves an element of typesetting. If
you are aligning characters, you are typesetting, however crudely.

> You might like the results of your typsetting; I happen not
> to. You probably wouldn't like mine. Does that mean we shouldn't work
> together? Only if you insist on forcing me to conform to your way of
> displaying code.

Someone who insists that everyone should separate line indentation into
tabs which achieve the block level, and spaces that achieve additional
alignment, so that code could be displayed in more than one way based
on the tab size without loss of alignment, is probably a "space cadet",
who has a bizarre agenda unrelated to developing the product.

There is close to zero value in maintaining such a scheme, and
consequently, it's hard to justify with a business case.

Yes, in the real world, you have to conform to someone's way of
formatting and displaying code. That's how it is.

You have to learn to read, write and even like more than one style.

> You are correct in pointing out that tabs don't allow for 'alignment'
> of the sort you mention:

That alignment has a name: hanging indentation.

All forms of aligning the first character of a line to some requirement
inherited from the previous line are called indentation.

Granted, a portion of that indentation is derived from the nesting
level of some logically enclosing programming language construct, and
part of it may be derived from the position of a character of some
parallel constituent within the construct.

> (lisp
>(nested list
> with symbols
> and things))
> But then neither does Python. I happen to think that's a feature.

Python has logical line continuation which gives rise to the need for
hanging indents to line up with parallel constituents in a folded
expression.

Python also allows for the possibility of statements separated by
semicolons on one line, which may need to be lined up in columns.

   var = 42; foo = 53
   x   =  2; y   = 10

> (And of course you can do what you like inside a comment. That's
> because tabs are for indentation, and indentation is meanigless in that
> context.

A comment can contain example code, which contains indentation.

What, I can't change the tab size to display that how I want? Waaah!!!
(;_;)

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code

[Duncan Booth]

achates wrote:

>>In particular a common convention is to have indentations at 4
>>spaces and tabs expanding to 8 spaces.
> 
> Like all space-indenters, you seem to be hung up on the idea of a tab
> 'expanding' to n spaces. It only does that if you make your editor
> delete the tab character and replace it with spaces! Really, that is
> the only sense in which your statement makes any sense. If you want
> your indentation to have the width of four, eight, or nineteen spaces,
> set your tabstops accordingly.

It is strange. You use many of the same words as me, but they don't make 
any sense.

The point is about separating the presentation of the source file from the 
semantic content. When displaying the file you can choose to expand tabs to 
any suitable positions. These may be evenly spaced every n characters, or 
may vary across the page. However the important thing is that a tab does 
not map to a single indentation level in Python: it can map to any number 
of indents, and unless I know the convention you are using to display the 
tabs I cannot know how many indents are equivalent to a tabstop.

> Seriously people, this is about separating the content of a source file
> from how it is displayed. It's about letting people work together while
> also allowing them to have control over their own environments,
> something which is and always has been central to the hacker ethos.

Precisely. Using spaces everywhere allows this, using tabs everywhere 
allows this, mixing spaces and tabs is a bad thing. You have to agree a 
convention for the project and conform to it. My experience is that 'spaces 
only' is more common, but your experience may differ.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code

[achates]

Duncan Booth wrote:

>Because it doesn't mean 'one level of indentation', it means 'move to next
>tabstop' and a tabstop isn't necessarily the same as a level of
>indentation.

'move to next tabstop' is how your editor interprets a tab character.
'one level of indentation' is how the language parser interprets it.
The two are entirely consistent, in that they are both isomorphic
mappings of the same source file.

>In particular a common convention is to have indentations at 4
>spaces and tabs expanding to 8 spaces.

Like all space-indenters, you seem to be hung up on the idea of a tab
'expanding' to n spaces. It only does that if you make your editor
delete the tab character and replace it with spaces! Really, that is
the only sense in which your statement makes any sense. If you want
your indentation to have the width of four, eight, or nineteen spaces,
set your tabstops accordingly.

Seriously people, this is about separating the content of a source file
from how it is displayed. It's about letting people work together while
also allowing them to have control over their own environments,
something which is and always has been central to the hacker ethos.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code

[Duncan Booth]

achates wrote:

> You haven't explained why you think there's a problem with having a
> character which, in an unambiguous and non-implementation-specific way,
> means 'one level of indentation'. In Python, of all languages, it makes
> sense to have such a character because 'one level of indentation' is a
> syntactical token processed by the interpreter.
> 
Because it doesn't mean 'one level of indentation', it means 'move to next 
tabstop' and a tabstop isn't necessarily the same as a level of 
indentation. In particular a common convention is to have indentations at 4 
spaces and tabs expanding to 8 spaces.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs versus Spaces in Source Code

[achates]

Kaz Kylheku wrote:

> If you want to do nice typesetting of code, you have to add markup
> which has to be stripped away if you actually want to run the code.

Typesetting code is not a helpful activity outside of the publishing
industry. You might like the results of your typsetting; I happen not
to. You probably wouldn't like mine. Does that mean we shouldn't work
together? Only if you insist on forcing me to conform to your way of
displaying code.

You are correct in pointing out that tabs don't allow for 'alignment'
of the sort you mention:
(lisp
   (nested list
with symbols
and things))
But then neither does Python. I happen to think that's a feature.

(And of course you can do what you like inside a comment. That's
because tabs are for indentation, and indentation is meanigless in that
context. Spaces are exactly what you should use then. I may or may not
like your layout, but it won't break anything when we merge our code.)

-- 
http://mail.python.org/mailman/listinfo/python-list