Why doesn't Python require exactly four spaces per indentation level?

Question

Whitespace is signification in Python in that code blocks are defined by their indentation.

Furthermore, Guido van Rossum recommends using four spaces per indentation level (see PEP 8: Style Guide for Python Code).

What was the reasoning behind not requiring exactly four spaces per indentation level as well? Are there any technical reasons?

It seems like all the arguments that can be made for making whitespace define code blocks can also be used to argument for setting an exact whitespace length for one indentation level (say four spaces).

Answer 1

There are no technical reasons. It would not be too hard to modify the Python interpreter to require exactly four spaces per indentation level.

Here is one use case for other indentation levels: when typing into the interactive interpreter, it's very handy to use one-space indentations. It saves on typing, it's easier to count the number of spaces correctly, and readability is not a major concern (since the code isn't even saved in a file).

Answer 2

Another case that I just encountered on the [email protected] mailing list - A blind programmer who is working in Python uses a reader program - apparently the reader program isn't terribly fond of multiple spaces, so it's easier on him to use a single space.

There's really no good or technical reason to require exactly 4 spaces, and I think the best argument against requirement is that programmers hate to be restricted, especially by stupid and somewhat arbitrary rules. Sure we all agree that 4 spaces is best and most of us have editors automagically set our indentation, but on the occasions you don't want to use 4 spaces - one off script code, etc. - you have now alienated a programmer who feels the crushing hand of an arbitrary (style) requirement.

The importance of whitespace isn't a problem for most people for a few reasons. First, I can't think of a single (good) programmer who would argue that proper code formatting is a bad thing. Second, logic requires us to separate our code into blocks. Many languages use {} delimiters. In assembly it's usually labels. Python's choice of whitespace is actually fairly natural, at least for the English language. When you read a book, or a newspaper, or a blog post, when someone makes a quote it's usually indented. Paragraphs are separated by a blank line or two. Chapters are usually separated by blank space at the end of a page and blank space at the beginning of the next. So whitespace is a good thing, but forcing programmers to adhere to your particular standard will get programmers to go do something else with their time.

Answer 3

While there are implications made by requiring consistent indentation within a single block, there are no implications made by having indentation levels between blocks be either the same or different. In other words, what would be the point?

Comparing it to the whitespace requirement isn't really valid because whitespace is a part of the syntax of Python: it defines scope. So long as scope can be unambiguously defined, why do we care how many spaces are used to define it? What benefit would be offered by forcing everyone to use some (completely arbitrary) fixed number of spaces?

What if your word processor forced you to indent paragraphs exactly four spaces? It would be annoying, and it would serve no purpose. It shouldn't serve a purpose to have a fixed number of spaces of indentation.

Think about it this way: Python doesn't have a 'whitespace' requirement so much as it has a requirement that you find a way to define scope without braces. What fell out of that was whitespace, and saying it has a 'whitespace requirement' is easier and more obvious than saying it has a 'scope definition sans braces' requirement, so for purposes of succinct communication, we just say it has a 'whitespace requirement' ;-)

Answer 4

Python is all about rapid prototyping. A lot of the good designs only work because most Python programmers have good practices. That's why we don't depend on accessors and mutators as much as Java, and we can access array indices with negative numbers.

In my opinion, limiting the whitespaces to 4 and disallowing tabs doesn't make Python more readable on a large-scale. For a long time, there has been very few issues, because of the good practices we advocate.

I truly believe it.

Python comes with convenience.

Answer 5

Using 1 space (or tab) saves space while code-golfing :-p

Answer 6

reindent.py changes any python file to use 4-space indents and no hard tab characters. Having this handy utility around obviates the need to force others to program Python in the 4-space style.

PS. Perl, Java, C programmers spend many brain cycles fussing with semicolon syntax errors. Every brain cycle wasted on syntax fluff is a cycle not spend solving real programming problems. One of Python's advantages for rapid development is that it minimizes syntax rules that end up wasting brain cycles. Therefore fewer syntax requirements are better than more.

Answer 7

Joel's Best Software Writing antology starts with Ken Arnold's interesting and provocative essay "Style is Substance", from Ken's post you can also read here. It's a well-argued essay with the thesis, and I quote, that "the only way to get from where we are to a place where we stop worrying about style is to enforce it as part of the language".

It's the only essay I've ever read that proposes that languages' compilers should lock down every aspect of style (your idea about locking down amount of indentation, for example, would be part of that -- not just in Python, either... Ken's main past contributions are Jini, curses, javaspaces, rogue, and parts of Corba, nothing Python-related). It makes really good points, and in the online version's comments you can see some counterpoints (alas, not necessarily equally well argued).

I do find it ironic that one responder talks about "Fortran and its strong formatting rules"; that sounds like somebody who never used Fortran, or used it with very shallow and marginal understanding of it. How many languages do you know where you can write, for example,

total count = 1 000 000

...? In Fortran, you can! The spaces are irrelevant, and ignored by the compiler, inside both identifiers and number literals, so you don't have to use underscores or camelcase to make multiword identifiers usable (just use spaces between words!) and it's easy to make large numbers readable too. Some languages did adopt this kind of rules, but most forbid spaces within identifiers and numbers.

Of course style flexibility always comes with risks of errors, e.g., in Fortran's case,

DO 10 I = 1. 5

assigns to variable DO10I the number 1.5, while the almost-undistinguishable

DO 10 I = 1, 5

loops five times on the block from here to line 10 (I believe a real-world occurrence of a bug like this one -- dot instead of comma drastically changing the code's meaning -- once damaged a space mission, but don't recall the exact details).

So, please don't take Fortran as an example either for or against "locking down", because in many stylistic aspects it's so incredibly loose instead!

Some examples of lockdown include modern languages that take e.g. case conventions and make them enforced parts of the language (uppercase initials for classes, etc) -- I believe Ruby at least warns about this and some other languages actually give compiler errors if you (e.g.) name a class with a lowercase initial or a non-class with an uppercase one. I think the resulting enforced uniformity is a good thing, and I don't see why it should be different where the enforced aspect of style is spacing rather than casing, etc. IOW, Arnold has mostly convinced me about this;-).

Answer 8

Python is already different than other languages in the way whitespace and line breaks are so significant. It's a unique part of the language and is very clean to work with of course, but I think to add this restriction would reduce flexibility.

Also, I like two spaces.... I'd be forced to write my programs with two spaces and then run them through a space doubler script as a compile step.

Answer 9

See PEP 666 - Reject Foolish Indentation

Answer 10

Beyond the reasons given above there's another really good reason why you'd want the interpreter to support minimal indentation: Saving space. Due to the limitations of freezing Python bytecode it isn't always practical to ship something with just .pyc files instead of the actual code. This means that if you're writing code to run on a a platform with very limited space (say, an OpenWRT router) it makes a lot of sense to keep the number of spaces to a minimum to save disk space.

This is why I wrote pyminifier

Answer 11

To avoid the problems that occur with make's requirement to have tab characters in-front of each action.

For example It is a pain if you have tab equals four spaces and you're flicking back and forth from a .c file and a Makefile