Why not enforce four space indentations in version 3.x?
walterbyrd
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
walterbyrd <walte...@iname.com> wrote:
>
>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.
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
"as long as we like the same operating system, things are cool." --piranha
Kurt Smith
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
--
http://blog.rebertia.com
Ben Finney
> I believe Guido himself has said that all indentions should be four
> spaces - no tabs.
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.
it soon afterward takes a more nuanced tone::
The most popular way of indenting Python is with spaces only. The
second-most popular way is with tabs only. Code indented with a
mixture of tabs and spaces should be converted to using spaces
exclusively. When invoking the Python command line interpreter with
the -t option, it issues warnings about code that illegally mixes
tabs and spaces. When using -tt these warnings become errors. These
options are highly recommended!
For new projects, spaces-only are strongly recommended over tabs.
Most editors have features that make this easy to do.
<URL:http://www.python.org/dev/peps/pep-0008/>
> Since backward compatibility is being thrown away anyway
That implies a level of abandon that was (AIUI) never the intent.
Rather, backward compatibility was critically examined for whether it
was justified in Python 3.
> why not enforce the four space rule?
Guido has used his time machine to answer your question a few years ago
<URL:http://www.artima.com/weblogs/viewpost.jsp?thread=101968>. (Be sure
to read the discussion in the comments on the article.)
> 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.
Any text editor that is good for programming (yes, I'm aware this is
perilously close to a “no true Scotsman” fallacy) will have an option
to visibly differentiate whitespace characters, for exactly the reason
you point out.
--
\ “Special cocktails for the ladies with nuts.” —bar, Tokyo |
`\ |
_o__) |
Ben Finney
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
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
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
sk...@pobox.com
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
> On Jul 14, 2009, at 5:06 PM, David Bolen wrote:
>> 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:
Um, right - in other words, what I said :-)
-- David
Miles Kaufmann
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
Inky 788
> walterbyrd <walterb...@iname.com> writes:
> > I believe Guido himself has said that all indentions should be four
> > spaces - no tabs.
>
> 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
> 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
> > 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.
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
>> 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)
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)
<tab>do_other_stuff(bar)
> 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.
>> 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. :)
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
> On Jul 10, 7:35 pm, Ben Finney <ben+pyt...@benfinney.id.au> wrote:
>
> > walterbyrd <walterb...@iname.com> writes:
> > > I believe Guido himself has said that all indentions should be four
> > > spaces - no tabs.
>
> > 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.
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.
Ben Finney
> On Jul 10, 7:35 pm, Ben Finney <ben+pyt...@benfinney.id.au> wrote:
> > 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!".
Not weird at all, especially when you realise that your interpretation
isn't there in the document.
The allowance for both types of indentation is a compromise made for
backward compatibility with code written before this convention was
quite so strong. All *new* code is strongly advised to follow the
convention, while the interpreter will still allow old code that doesn't
follow the convention.
> Very ... perlish, if you ask me.
Hah! Perl doesn't have the “don't do {foo}” part, so I don't see what
you're seeing.
--
\ “I like to skate on the other side of the ice.” —Steven Wright |
`\ |
_o__) |
Ben Finney
David Bolen
I suspect Tim was referring to the Python tokenizer. Internally,
barring the existence of one of a few Emacs/vi tab setting commands in
the file, Python always assigns the logical indentation level for a
tab to align with the next multiple-of-8 column. This is unrelated to
how someone might choose to display such a file.
So mixing tabs and spaces and using a visual display setting of
something other than 8 for the tab size (other than one consistent
with an instruction embedded in the file) can yield a discrepancy
between what is shown on the screen and how the same code is perceived
by the Python compiler. This in turn may cause errors or code to
execute at different indent levels than expected. Thus, in general,
such a mixture is a bad idea, and as per this thread, no longer
permitted in a single block in Python 3.x.
-- David