The Artima Developer Community
Sponsored Link

Weblogs Forum
Stricter Whitespace Enforcement

25 replies on 2 pages. Most recent reply: Jul 12, 2007 2:25 AM by Vincent O'Sullivan

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 25 replies on 2 pages [ 1 2 | » ]
Guido van van Rossum

Posts: 359
Nickname: guido
Registered: Apr, 2003

Stricter Whitespace Enforcement (View in Weblogs)
Posted: Apr 1, 2005 1:20 AM
Reply to this message Reply
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

you could just as well have written 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:

from __future__ import whitespace

I have hacked up a quick and dirty implementation, which is available at the following SourceForge URL (new, now updated!): http://sourceforge.net/tracker/index.php?func=detail&aid=1175070&group_id=5470&atid=305470

Feedback, as always, is welcome!


Girts Kalnins

Posts: 23
Nickname: smejmoon
Registered: May, 2003

Ordnung muß sein! Posted: Apr 1, 2005 2:06 AM
Reply to this message Reply
Also line breaks in middle of parentheses should be forbidden and no linebreaks with backslashes\

Duncan Booth

Posts: 1
Nickname: duncanb
Registered: Apr, 2005

Re: Stricter Whitespace Enforcement Posted: Apr 1, 2005 2:35 AM
Reply to this message Reply
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.

shibinck

Posts: 1
Nickname: shibinck
Registered: Apr, 2005

Re: Stricter Whitespace Enforcement Posted: Apr 1, 2005 3:14 AM
Reply to this message Reply
april 1!!!

Florian Bösch

Posts: 6
Nickname: pyalot
Registered: Mar, 2005

Re: Stricter Whitespace Enforcement Posted: Apr 1, 2005 3:51 AM
Reply to this message Reply
There's two objections I would like to place.

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

shortvar = 10
longvarnamesomething = 20
a = 50
asdfasdf = 10

is much harder to read then

shortvar = 10
longvarnamesomething = 20
a = 50
asdfasdf = 10


> 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.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Stricter Whitespace Enforcement Posted: Apr 1, 2005 4:35 AM
Reply to this message Reply
Excellent ideas!

A few additional thoughts to ease legibility:
    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.

Marco Lopes

Posts: 1
Nickname: mlopes
Registered: Apr, 2005

Re: Stricter Whitespace Enforcement Posted: Apr 1, 2005 6:01 AM
Reply to this message Reply
I know this is just an Aprils 1st joke but except for the line spacing stuff I like these rules :D

Matt Gerrans

Posts: 1153
Nickname: matt
Registered: Feb, 2002

Re: Stricter Whitespace Enforcement Posted: Apr 1, 2005 8:51 AM
Reply to this message Reply
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.

Lyle Thompson

Posts: 1
Nickname: lylestyle
Registered: Apr, 2005

Re: Stricter Whitespace Enforcement Posted: Apr 1, 2005 9:39 AM
Reply to this message Reply
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

Matt Gerrans

Posts: 1153
Nickname: matt
Registered: Feb, 2002

Re: Stricter Whitespace Enforcement Posted: Apr 1, 2005 11:42 AM
Reply to this message Reply
> 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.



Posts: 1
Nickname: gwyn
Registered: Apr, 2005

Re: Stricter Whitespace Enforcement Posted: Apr 1, 2005 1:09 PM
Reply to this message Reply
The sad thing is that even while knowing the date, I'd still say "Go for it!" :-)

Guido van van Rossum

Posts: 359
Nickname: guido
Registered: Apr, 2003

Re: Stricter Whitespace Enforcement Posted: Apr 1, 2005 1:44 PM
Reply to this message Reply
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.

Patrick Doe

Posts: 1
Nickname: xier
Registered: Apr, 2005

Re: Stricter Whitespace Enforcement Posted: Apr 1, 2005 3:22 PM
Reply to this message Reply
I wish this wasn't an april fools joke... great idea!

Ronald Adam

Posts: 5
Nickname: ron100
Registered: Mar, 2005

Re: Stricter Whitespace Enforcement Posted: Apr 2, 2005 7:14 AM
Reply to this message Reply
Looks good to me! I like it. :)

On a more serious note, it wouldn't be a bad idea to add a reformatter that followed these rules to idle's format menu.

Reguards,
Ron_Adam

bug not

Posts: 41
Nickname: bugmenot
Registered: Jul, 2004

Re: Stricter Whitespace Enforcement Posted: Apr 2, 2005 1:10 PM
Reply to this message Reply
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 [ 1  2 | » ]
Topic: Stricter Whitespace Enforcement Previous Topic   Next Topic Topic: The Flex & Air Jam

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use