Tabs -vs- Spaces: Tabs should have won.

[rantingrick]

On Jul 17, 2:35 am, Thorsten Kampe <thors... at thorstenkampe.de> wrote:
> * rantingrick (Sat, 16 Jul 2011 09:51:02 -0700 (PDT))
>
> > 3) Tabs create freedom in the form of user controlled indention.
>
> > Indention width should be a choice of the reader NOT the author. We
> > should never "code in" indention width; but that is EXACTLY what we
> > are doing with spaces! No, the reader should be able to choose the
> > indention width without ANY formatting required or without any
> > collateral damage to the source code. Tabs offer freedom, spaces offer
> > oppression.
>
> Why are you so obsessed with indentation length? Indentation length is
> just /one/ of the formatting choices that the author makes for the
> reader - and probably the /least/ significant one.

I am not OBSESSED with it, i am just PERTURBED that we are not using
tabs; since tabs offer freedom to view the source at ANY indentation
level you choose REGARDLESS of what the author "thought" was
appropriate. It is a wise choice to only allow tabs in a language that
has FORCED indention. This is one way we can actually promote freedom
whist maintaining unity.

> There is for instance maximum line length,

I like to keep lines at 80. Sometimes i go over if the code is not
something you would need to read often. If the code was to go into the
stdlib i would make sure it was 110% style guide compliant.

>  the number of empty lines,

I hate  vertical white-space. I follow Python style guide suggestions,
and then some! I hate when people insert spaces into code blocks and
function/method bodies. If you feel a space must be inserted then that
is a good clue you should be using a comment there instead. Vertical
breaks should only happen before and after classes, methods,
functions, groups of GLOBALS, groups of import statements. Think of
func/method bodies as paragraphs and classes as sections of a book.
Two vertical spaces between classes and one vertical space between
func/methods.

> the author's method of alignment, spaces between the equals sign and so
> on.

I believe non-compliant spacing in args should throw an syntax error.
I hate this:

>>> func( arg1 = 1, arg2 = 3 )

It should be...

>>> func(arg1=1, arg2=3)

Much easier to read when formatted into logical groups.

>  These are all much more "dominant" in the source code and none of
> this is left for the reader's disposition.

It should be MANDATED. And these @holes who refuse to format their
code in a community standard will suffer the plague of syntax errors.
Who do these people think they are? Do they believe the rules do not
apply to them? I'll tell you who they are, they are F'ING format
criminals.

> Compare for instance
>
> variable        = 11
> anothervariable = 22
>
> def whatever (prettylong     = 1,
>               alsoprettylong = 22,
>               anotherone     = 33):
>     pass
>
> to
>
> variable=11
> anothervariable=22
> def whatever (prettylong=1, alsoprettylong=22, anotherone=33):
>     pass

Both examples show non-compliance to the Python style guide.Except for
this...

------------------
FUNCTIONS/METHODS
------------------
def whatever(
    prettylong=1,
    alsoprettylong=22,
    anotherone=33):

OR

def whatever(prettylong=1, alsoprettylong=22,
             anotherone=33):

I think the second is more readable for block openers. Note the
closing bracket and colon on last line!

------------------
 CONTAINER TYPES
------------------

d = {
    1:1,
    2:2,
    3:3,
    4:4,
    }

Note closing bracket on newline; and all alone! For hand stitching
containers you should put the "closer" on a newline that matches the
"opener's" indention level.

------------------
 VARIABLES
------------------

variable = 11
anothervariable = 22

Stop trying to be an individual in a community. When you write code
for just you then write it any way you like. Go ahead and use that
Joker font and 10 space indention. Go ahead an use foolish spacing and
whatever. However when you are writing code in public or for the
stdlib you should always be Style Guide compliant.

You guys should feel lucky i am not the BDFL, because i would cast
plagues of exceptions on your lazy butts!