Summary
The Python Style Guide (PEP 8) lists a number of guidelines for the use of whitespace. Since there are still a lot of folks ignoring these rules, here's a proposal for enforcing them.
Advertisement
Python currently gives you a lot of freedom on how to format your code. For example, instead of this:
def fool(one, four):
year = 2005
while year < 10000000:
year *= 10
return year + four*100 + one
This is a clear violation of TOOWTDI and enables poorly written code.
Therefore, I propose that as soon as practical, Python should enforce the following rules for horizontal whitespace:
All code indented with four spaces. This will also get rid of the tabs problem!
No redundant parentheses allowed (e.g. no "return(1)" where "return 1" would do).
No whitespace immediately following a left parentheses or immediately before a right parenthesis.
No whitespace before a left parenthesis that starts an argument list, or before a left square bracket that starts an index expression (e.g. "x[y]").
No whitespace before a comma or semicolon.
Exactly one space required after a comma or semicolon (except when at the end of a line).
No semicolon at the end of a line (it's redundant).
More than one consecutive space within an expression is never allowed.
Asignment and comparison operators must be surrounded by spaces.
The amount of whitespace on both sides of a binary operator should be the same.
If variable amounts of whitespace are used within an expression, this should correspond to the relative priorities of the operators used. For example: "1*2 + 3*4" is okay but "1*2 + 3 * 4" is not. However, "1*2+3*4" is still encouraged.
No space allowed before a colon.
In a dictionary display, exactly one space required after a colon. In a slice, none.
The short form of a block ("if x: y") is abandoned; you must use the newline-plus-indentation form.
A limited form of vertical whitespace fascism may also be introduced, although this may encounter more resistance, so it may be put off until Python 3.0:
At least one blank line should separate function or method definitions.
At least two blank lines should separate classes.
In order to give users sufficient time to adapt their coding style, the new syntax will be optional in Python 2.5, and required in Python 2.6. In Python 2.5, you can enable the strict whitespace checking for a particular module with a future statement:
Some excellent ideas here, although there is nothing much new under the sun. So far as I remember the Sinclair ZX80 did much the same back in 1980 --- they also had all the reserved words printed on the keyboard and you had to enter them using the appropriate key, no cheating by typing them in as individual characters and certainly no using the spacebar outside a string.
I think the vertical facism needs a bit of expansion:
A comment which precedes the code it is commenting must be preceded by a blank line (or start of file) and must not be followed by a blank line. A comment which follows code must be followed by a blank line and not preceded by one.
First: This whitepsace enforcement means a lot more interpreter errors. Handling more errors, that are perhaps hard to spot, means writing less code. Specially writing correct code with the first go might get harder ( I find this greatly increases productivity ). A language as a user interface can make learning and editing pleasant. As a user interface designer I would base each and every such decision on knowledge I derive from careful user observation. Maybe there is a reason most popular languages today try not to sport such fine grained whitespace control. Perhaps it's coincidence.
Second: Some of the rules do not apeal to me because of specific reasons, listed below
> No whitespace immediately following a left parentheses > or immediately before a right parenthesis. So the form foo( a, b ) is discouraged and replaced by foo(a, b)? I find foo( a, b ) easier to read, and use it exclusively. Sorta a bummer, but I can imagine I can live with it.
> The amount of whitespace on both sides of a binary > operator should be the same. I generally agree with this one, except that I find
> The short form of a block ("if x: y") is > abandoned; you must use the newline-plus-indentation > form. This I think is an outright bad idea. Sure there are situations where it invites you to write badly readable code. BUT...(ok, rather simplistic example, but you can follow a scale-up of this in your mind I hope)
class nr_node: def add(a, b): return a + b def sub(a, b): return a - b
> At least one blank line should separate function or > method definitions. Mostly agree, but for some tasks you write massive amounts of method/function definitions (parser generators for instance) with minimalistic bodies, it kinda would hurt to blow up line count by 50% and having to scroll just because of that.
> At least two blank lines should separate classes. Same reason as before, minimalistic classes, lots of them, hurts.
Proportional width fonts to be deprecated in Python editors. All text should be in columns 7 to 72 only. Columns 73 to 80 to be reserved for line numbers. A compilation switch to use or ignore case sensitivity.. The use of underscore characters to be made optional. Bracket types (e.g. (), {}, []) to be freely interchangeable.
Cool. Can we add macros to Python too? Then we could do really creative things like
#define { #define }
(that's defining a left-space to { and a right-space to }). This way, Python code won't be so ambiguous and "quirky" for new programmers coming from other popular languages.
Python was never very compatible with WhiteSpace (http://compsoc.dur.ac.uk/whitespace/index.php) programming in the first place, so this change shouldn't cause too much consternation on that front.
This is basically a proprosal to change the fundamental language syntax. Although I'm all for coding standards, this is way too draconian. Once implemented, virtually all the existing code snippets in existence will stop working. I would support adding command line switch(es) to enable strict checking. Of the listed items, the only one that even seems reasonable as a default is indentation enforcement (which should have been in the original language). The other changes would make grepping through code easier, but why don't we just build a syntax-directed grep instead? Although I follow those *guidelines* more often than not, formatting someecode (e.g. equations) for readability requires some flexibility in white space. I could rant on with many specific examples, but I suspect others will contribute amply along those lines.
P.S. Someone please tell me this is an April fools joke
> Someone please tell me this is an April fools joke
I think Guido did tell you that with the original blog, you just weren't listening.
This sort of illustrates that it's particularly cruel to do an April Fool's gag in a forum, because the victims are immortalized in the act of their self-impalement.
The SF link now works (I've fixed it in-line in the article). Apologies for posting a broken link before! Improvements upon the patch are most welcome.
I'll have to admit, I've been had again (most of the semi-plausible April 1 jokes have gotten me). But just to respond to some of these posts that seem to think it's a good idea, I'll just say there times when extra whitespace inside parens really helps, e.g. in any non-trivial generator expressions.
Flat View: This topic has 25 replies
on 2 pages
[
12
|
»
]