Non-Indented python
Chris Liechti
cliechti at gmx.net
Wed Nov 21 20:02:15 EST 2001
"Delaney, Timothy" <tdelaney at avaya.com> wrote in
news:mailman.1006384828.32275.python-list at python.org:
>> From: Jeff Shannon [mailto:jeff at ccvcorp.com]
>> Dave Cinege wrote:
>>
>> > Rule of God:
>> > The punishment for non-tab based indentation is death.
>>
>> This is exactly backwards.
>>
>> Tabs are wrong, because different editors will treat them differently.
>>
>> Spaces are right, because a space is a space is a space, everywhere
>> you go.
>
> There are actually two things involved here.
>
> If you use tabs everywhere for indentation (i.e. tab *characters*, not
> tab *stops*) you are guaranteed that you can cut and paste from any
> other source code that uses tabs everywhere, even if it doesn't look
> right onscreen (because they used a different tab size).
>
> If you use spaces everywhere, you are at the mercy of other code that
> doesn't use the *same number* of spaces for indentation. For example,
> if you use four spaces for indentation, and you cut and paste code that
> uses two spaces per indentation, nothing will work. You will need to
> reformat one or the other before copying the code.
thats not so a big problem. you can mix diffrent indentation withs even
within a function. the point is that a block must keep its indentation and
that deeper blocks are indented a bit more.
e.g this is legal:
>>> def fu(arg):
... if arg:
... print "no value"
... else:
... print arg
it might not look nice, but its valid.
> And of course, any time you mix spaces and tabs for indentation you
> might as well forget it completely.
>
> The problem is simply that people use the tab key and character to mean
> different things. Originally the tab key was designed to do the same
> thing as on a typewriter - advance to the next tab stop (i.e. a certain
> number of spaces). Thus you end up with editors which distinguish
> between indentation and tab because a tab is too big for indentation.
>
> It would have been so much easier if it had originally been defined
> that the tab key always generated a tab *character*, and that the tab
> *character* had been defined as equivalent in size to four spaces (or 3
> perhaps). This rule of course would be broken by applications which can
> set their own tab stops, but that's up to the application. The
> important thing is that there should *always* be a direct mapping
> between the tab key and the tab character.
tabs are specified as 8 characters. only programmers that use tabs to
indent make them 4 or 3 characters...
tabs were defined to make a formated output. e.g. you can write zero to 7
characters plus a tab and you know where the cursor is. this is nice for
tables on ASCII/text only outputs. a tab with of 4 would make the original
idea of tabs complete useless.
a "tab *charcter*" that is just a shorthand for four spaces is completly
useless (unless for data compression, but there are better algos...)
the Java styleguide says that you should use 4 characters indentation and
that you can write a tab for 8 characters, so they made it correct, same as
python has it correct too.
>
> Tim Delaney
>
--
Chris <cliechti at gmx.net>
More information about the Python-list
mailing list