Why not enforce four space indentations in version 3.x?

[walterbyrd]

I believe Guido himself has said that all indentions should be four
spaces - no tabs.

Since backward compatibility is being thrown away anyway, why not
enforce the four space rule?

At least that way, when I get python code from somebody else, I would
know what I am looking at, without having to do a hex dump, or
something.

 

[Aahz]

I believe Guido himself has said that all indentions should be four
spaces - no tabs.

Since backward compatibility is being thrown away anyway, why not
enforce the four space rule?

Probably the main reason is that Guido also hates non-functional code
changes because it messes up version history. Not sure, though.

 

[Kurt Smith]

I believe Guido himself has said that all indentions should be four
spaces - no tabs.

Since backward compatibility is being thrown away anyway, why not
enforce the four space rule?

At least that way, when I get python code from somebody else, I would
know what I am looking at, without having to do a hex dump, or
something.

What you propose has already been (forcefully) rejected:

http://www.python.org/dev/peps/pep-0666/

 

[Chris Rebert]

I believe Guido himself has said that all indentions should be four
spaces - no tabs.

That's a (very good) recommendation at most.
http://www.python.org/dev/peps/pep-0666/

Cheers,
Chris

 

[gslindstrom]

I believe Guido himself has said that all indentions should be four
spaces - no tabs.

Since backward compatibility is being thrown away anyway, why not
enforce the four space rule?

There is a routine in the Scripts directory, reindent.py, that will
take your source file(s) and remove tabs, unify the indents to 4-
spaces, remove needless characters at the end of lines, etc. IIRC, it
was written by Tim Peters. We run all of our source files though
before checking them into svn.


--greg

 

[John Nagle]

I believe Guido himself has said that all indentions should be four
spaces - no tabs.

Since backward compatibility is being thrown away anyway, why not
enforce the four space rule?

At least that way, when I get python code from somebody else, I would
know what I am looking at, without having to do a hex dump, or
something.

Python 3 enforces the rule that you can't mix tabs and spaces
for indentation in the same file. That (finally) guarantees that
the indentation you see is what the Python parser sees. That's
enough to prevent non-visible indentation errors.

It also means that the Python parser no longer has to have
any concept of how many spaces equal a tab. So the problem
is now essentially solved.

John Nagle

 

[David Bolen]

Python 3 enforces the rule that you can't mix tabs and spaces
for indentation in the same file. That (finally) guarantees that
the indentation you see is what the Python parser sees. That's
enough to prevent non-visible indentation errors.

Are you sure? It seems to restrict them in the same block, but not in
the entire file. At least I was able to use both space and tab
indented blocks in the same file with Python 3.0 and 3.1. I suspect
precluding any mixture at all at the file level would be more
intrusive, for example, when trying to combine multiple code sources
in a single file.

Not that this really changes your final point, since the major risk
of a mismatch between the parser vs. visual display is within a single
block.

It also means that the Python parser no longer has to have
any concept of how many spaces equal a tab. So the problem
is now essentially solved.

"has to have" being a future possibility at this point, since I'm
fairly sure the 3.x parser does technically still have the concept of
a tab size of 8, though now it can be an internal implementation
detail.

-- David

 

[Jean-Michel Pichavant]

Python 3 enforces the rule that you can't mix tabs and spaces
for indentation in the same file. That (finally) guarantees that
the indentation you see is what the Python parser sees. That's
enough to prevent non-visible indentation errors.

It also means that the Python parser no longer has to have
any concept of how many spaces equal a tab. So the problem
is now essentially solved.

John Nagle

By the way why would you prevent us from using tabs for indenting ? If
I'm not wrong, from a semantic point of view, that's what tabs are for:
indenting. Spaces are meant to separate tokens, aren't they ?
I love my tabs, don't take them away from me !

JM

 

[skip]

JM> By the way why would you prevent us from using tabs for indenting ?
JM> If I'm not wrong, from a semantic point of view, that's what tabs
JM> are for: indenting. Spaces are meant to separate tokens, aren't they
JM> ? I love my tabs, don't take them away from me !

I don't think your tabs have been taken away, you just can't mix them with
spaces.

Skip

 

[Miles Kaufmann]

Are you sure? It seems to restrict them in the same block, but not in
the entire file. At least I was able to use both space and tab
indented blocks in the same file with Python 3.0 and 3.1.

It seems to me that, within an indented block, Python 3.1 requires
that you are consistent in your use of indentation characters *for
that indentation level*. For example, the following code seems to be
allowed:

def foo():
<TAB>if True:
<TAB><SP><SP>x = 1
<TAB>else:
<TAB><TAB>x = 2
<TAB>return x

But replacing any of the first tabs on each line with 8 spaces
(without replacing them all), which previously would have been
allowed, is now an error.

-Miles

 

[David Bolen]

It seems to me that, within an indented block, Python 3.1 requires
that you are consistent in your use of indentation characters *for
that indentation level*. For example, the following code seems to be
allowed:

Um, right - in other words, what I said

-- David

 

[Dennis Lee Bieber]

<TAB>if True:
<TAB><SP><SP>x = 1
<TAB>else:
<TAB><TAB>x = 2
<TAB>return x

But replacing any of the first tabs on each line with 8 spaces
(without replacing them all), which previously would have been
allowed, is now an error.

-Miles

--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[Miles Kaufmann]

Um, right - in other words, what I said

I wasn't trying to correct you, just being more explicit. After
reading your post, I still wasn't sure if the restriction on mixing
spaces and tabs applied to nested blocks--I was surprised that the
code sample I included was allowed.

-Miles

 

[Dennis Lee Bieber]

<blink><blink>

I could swear I'd canceled the response... BEFORE sending... (I'd
realized I couldn't really justify my first thoughts -- hence the lack
of any added content)


--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[Inky 788]

Yes. That's a “should” and not a “must”, even though PEP 8 says it
with a simple imperative::

    Use 4 spaces per indentation level.

That actually sounds pretty weird. "Don't do {foo}. Really, I mean
*really* don't do {foo}. Oh, also, the interpreter allows you to do
{foo}. But don't do it! I mean it!".

Very ... perlish, if you ask me.

I realize that a small portion of the community likes the tabs.
They're sold on the tabs. They like the tabs. But tabs are an archaic
holdover from an era when typewriters had physical tabstops on them.
Actually, after *that* they're a holdover from a program called `make`
whose designers unfortunately decided to use tab "characters" to
prefix commands. The tab is vestigial. Your text editor can treat 4
consecutive spaces as a unit if you wish. Let tabs go away. Stop using
them. If your editor keeps irrationally inserting them, make it stop.

 

[Tim Chase]

I realize that a small portion of the community likes the tabs.

They're sold on the tabs. They like the tabs. But tabs are an archaic
holdover from an era when typewriters had physical tabstops on them.

However, they are a single logical level of indentation -- I come
down fairly solidly on the "tabs" side of the "tabs vs. spaces"
argument. I can set my editor (vim in this case) to show tabs as
as many spaces as I want. I usually have this set to 4, but
sometimes 1 or 2. In Vim, using tabs I can just switch up my
tab-stop setting (":set ts=2") and the presentation of my code
reindents the way I expect. If I wanted to switch from
4-real-spaces to 2-real-spaces, I'd have to concoct a perlish
regexp to handle the munging.

The same "separation of content and presentation" that is all the
rage with N-tier programmers and web developers, my content is
"logical levels of indentation indicated by a tab character in
the source-code" and my presentation is "N spaces as presented by
my editor".

Yes, the dictatorial "a tab always equals 8 spaces" is a
vestigial holdover for which I hold no love.

I'll code on other people's projects with spaces if that's the
project convention (as Vim lets me switch around fairly easily).
But as for my own code, it's tabs all the way.

-tkc

 

[Inky 788]

However, they are a single logical level of indentation -- I come
down fairly solidly on the "tabs" side of the "tabs vs. spaces"
argument.

My bet is that the problem is this: some people like to format their
code in ways that don't work well when you're using tabs. For example,
they might want to call a function like this (note spaces):

some_func(foo=1,
bar=2,
baz=3)

instead of:

some_func(
foo=1,
bar=2,
baz=3)

The first one requires 10 spaces in front of bar and baz. If you're
using tabs, that means one or two tabs plus some space characters. So,
people who do that would probably never use tabs. The 2nd example is
fine for tabs or spaces. I'm sure there are a bunch of similar
examples for things besides function calls. Don't you ever find cases
where you'd like to add in an extra space or two to make things line
up nicely?

 I can set my editor (vim in this case) to show tabs as
as many spaces as I want.  I usually have this set to 4, but
sometimes 1 or 2.

Just curious: why would you want to do that? In my experience, once my
eyes got used to 4-space indents, everything else looks either too
little or too much.

 

[Tim Chase]

However, they are a single logical level of indentation -- I come

My bet is that the problem is this: some people like to format their
code in ways that don't work well when you're using tabs. For example,
they might want to call a function like this (note spaces):

some_func(foo=1,
bar=2,
baz=3)

instead of:

some_func(
foo=1,
bar=2,
baz=3)

For continued indenting statements such as this, I tend to use
the coding convention used at my first job out of college
(Computer Sciences Corp...for better or worse) which just indents
two levels:

def some_func(foo=1,
<tab><tab>bar=2,
<tab><tab>baz=3):
<tab>do_something(foo)

examples for things besides function calls. Don't you ever find cases
where you'd like to add in an extra space or two to make things line
up nicely?

I have occasionally (okay, "very rarely") use the "mixed
tab+space" method of indentation for continued lines if I want
them lined up nicely:

<tab><tab>if (foo == bar and
<tab><tab> baz > frob and
<tab><tab> fred != barney):
<tab><tab><tab>do_something()
<tab><tab><tab>do_more()

This scheme insures that the visual alignment for the
continued-line matches up, even if the tab-stop is changed. The
positioning of the indented block (the do_* bit) floats
inconveniently with relation to the continued text, with pessimal
cases being indistinguishable from the continued lines (which is
why I generally opt not to use this unless it has great benefits
in code clarity). By regularly indenting continued lines for
containing blocks (if, while, etc) by two tabs, the continuation
stands out from the contained code regardless of my tab stops.

Just curious: why would you want to do that? In my experience, once my
eyes got used to 4-space indents, everything else looks either too
little or too much.

It totally depends on the project -- I like the condensed nature
of 2sp/tab for code sharing on mailing lists (and tend to copy
out of vim with tabs expanded to 2 spaces for pasting into
emails) and for my own visual preference. If it's code that I'd
expect anybody else to view, I tend to use 4sp/tab to keep my
lines below 80 chars per line with the tabs taken into consideration.

I guess I change up my indent enough that sometimes 2 seems just
right or too small, and sometimes 4 seems just right or too large.

-tkc

 

[Carl Banks]

That actually sounds pretty weird. "Don't do {foo}. Really, I mean
*really* don't do {foo}. Oh, also, the interpreter allows you to do
{foo}. But don't do it! I mean it!".

Very ... perlish, if you ask me.

Not Perlish at all.

(Perl would never want you not to use something.)


Carl Banks

 

[Nobody]

Yes, the dictatorial "a tab always equals 8 spaces"

Saying "always" is incorrect; it is more accurate to say that tab stops
are every 8 columns unless proven otherwise, with the burden of proof
falling on whoever wants to use something different.