Pythonic Whitespace

Why does /prog/ dislike Python's use of whitespace? I have never had any problems with Python concerning whitespace, but numerous with C/C++.

Problems with C-style whitespace/bracing:
1) Code can be misleading, because while one reads indentation, it's not significant to the grammar. For instance:

if(true)
    a();
    b(); // This isn't actually in the body of the if.
2) There are over 9000 different ways of aligning bracing. Somehow, the most popular involves wasting a whole line for the opening brace'{'. Interestingly, such code always seems to neglect blank lines everywhere, leading to abominations like:

int a, b;
char c;
if(true)
{
    // do something
}
Why is the line of the if grouped together with the declarations of the variables!? What is wrong with the more readable and structured?:

int a, b;
char c;

if(true) {
    // do something
}
One can't say it's because the blank is a waste, because they often use nearly blank lines with solely '{' all the time!

Of course, Python saves even another line by eliminating the need for a closing brace '{'.

tldr: Why is Python's use of whitespace bad?

It's the easiest and most distinct thing to latch on to when you want to bitch about Python without actually knowing anything about it.
Of course, the premise that you wouldn't have to indent your code correctly if the language didn't care is patently absurd, as is the notion that an incorrectly placed brace is easier to spot than incorrect indentation.
Just take care not to mix spaces and tabs, and you'll be set for life.

The /prog/ secret society discourages the use of FIOC to save humanity as they have divined future events to transpire. One day, a great worm written in PHP will rampage the Internet, copying itself onto every file on every computer, including .py files. The worm was written from copy-pasted pieces of enterprise hardened PHP production code. Of course, the line by line copying from the original unaffected files will be sanitized:
$newline = trim($line); //);//mysql_real_escape_string(

>>3
Except mysql_real_escape_string doesn't really escape strings in a 100% secure way, even though the name implies it does.

>>2
Indeed, there's plenty of things to dislike about Python, but forced indentation is not one of them.

>>5
how about the lack of a case/switch statement?

I dislike additional rules that will cause my program to not work unnecessarily. I'm completely unfamiliar with Python, but the idea of rules for how you can use white space sounds irritating to me, the same as semicolons tend to annoy anyone new to C. Sure it's petty and stupid, but having your program crash because you forgot something simple like a space is discouraging.

I'm guessing anyone complaining about whitespace in Python is new to it and not used to it. It's probably best to ignore them.

>>6
Yes. The lack of enumerations and constants is annoying also.

>>7
I've never "forgotten to indent code". As I said before, I've had numerous problems with forgetting things in C/C++ (missing brace, missing semicolon (especially at the end of classes (Notice how one doesn't need it in Java.)), but never in Python. If you're so disorganized to refuse to indent you're code properly, you'll be punished worse in C/C++, by the ways I've already enumerated.

I've helped many people (not just freshmen) at university write code, and they all share something in common: They're code is completely disorganized. They follow no coherent naming scheme (Not only identifiers start with lowercase, classes with uppercase (Something I wish languages would also enforce.), but consistent use of terms like "number, amount, count, size, length, etc"), neglect logical use of whitespace all together (not just in blocking), like in: for(int i=0;i<1234;i++) ... While neglecting these things won't stop your code from compiling, they'll muddle your mind, and it's no wonder they have persistent problems. Yet, I feel that my preaching is lost on them. They're much more concerned with looking cool using shitty console editors than programming efficiently.

I deplore you to at least try Python before complaining about how its whitespace rules are restrictive, for I promise you that they are not.

>>8
I'm trying to remember that language with the forced uppercase first names of classes
you're code

>>1
My favourite C code structure mindfuck:

}

while (0)
{
   printf("This line actually gets printed!\n");
}

>>10
Oh, wait, that's syntactically incorrect, it was even better:

}

while (1);
{
   printf("This line actually gets printed!\n");
}

>>6
case/switches are essentially the same as a Python if elif structure, hell 'elif' even has the same number of letters as 'case'. What is there to complain about?
Similairly what advantage do constants have over variables which you never change?

def foo():
foo():
():
Why does Guido force me to write that?

Who else is fascinated by the striking resemblance of guido and alfonso cano?

FIOC gtfo

>>12
switch in C is a jump table, meaning O(1), while if/else if/.../else is O(N).
You can use dictionaries of functions in Python for the same effect as Java 7 switch:
d.get(a, b)()
is about the same as
switch (a) {
    /* the cases come here */
    default:
        b();
}

>>13
Requiring parentheses even in case of no arguments makes code more regular. C++ forces you to drop parentheses in a similar situation (argumentless variable initialization) and it hurts.

They have experimented with removing semicolons early in Python's life (maybe even before it was released to the public) and discovered that it was error-prone.

>>17
But having colons is plain retarded, since the things that need them (if, elif, else, for, def, class, try, except, finally,  ..., except lambda) always require them just before the beeline anyway (stuff such as if a: b shouldn't be permitted anyway.

>>18
*newline
Damn iPhone autocorrect.

>>18
stuff such as if a: b shouldn't be permitted anyway
Stuff like that is occasionally useful, but it doesn't require a semicolon anyway: except for a pathological case of implicit string constant joining, no concatenation of two Python expressions forms a valid expression. Oh, also unary minus.

The reason is that they tried it with Python's predecessor, ABC, and didn't like it: http://docs.python.org/faq/design.html#why-are-colons-required-for-the-if-while-def-class-statements

>>17
It only makes code more regular if they're required when there are arguments.

Also parentheses to call methods but not to access attributes is terrible. Ofc you can fix it with properties but why not just do it right to begin with like ruby, scala etc.

>>20
Eh ... they use syntax highlighting in the example with semicolon and none in the example without semicolon.

Notice how the second one is slightly easier to read.

fuck you pythonfags

Lisp is shit.

>>21
It only makes code more regular if they're required when there are arguments.
... and when you don't need to nest method calls. No, I, for one, agree the benefits probably outweigh the slight increase in complexity, but I can understand why Guido feels otherwise.

Also, by mentioning Scala in this context you just betrayed the fact that you are not actually a programmer, you don't write code (at least not in Scala) but learn trivia about languages for your ``nerd cred''. "Scala doing it right", my arse.

parentheses to call methods but not to access attributes is terrible. Ofc you can fix it with properties
You don't make sense.

>>22
I guess they run Python parser on preformatted blocks and apply syntax highlighting only to those which parse without errors. So that they don't get random highlights everywhere. Or maybe Guido deeply cares about justifying the decision to use colons, so he concocted this cunning deception, I don't know, that's possible too!

>>24
When you use different syntax for accessing a value that lives in an attribute and one produced by a method call you may have to change all client code when the implementation changes. properties prevent that by giving you attribute-syntax (without parentheses) for methods.

>>24
parentheses to call methods but not to access attributes is terrible. Ofc you can fix it with properties
You don't make sense.

You can use properties to call methods without using (), such as this:

>>> class Qwe(object):
...     def asd(self):
...         print 'zxc'
...     f = property(asd, None, None) # getter is asd(self), setter and deleter are None
...
>>> q = Qwe()
>>> q.asd()
zxc
>>> q.f
zxc
>>>

>>24
And by ruby and scala doing it right I meant that they adhere to the uniform access principle. (but ye, I don't actually program in scala, though I don't see how that's relevant)

class Qwe (object):
    @property
    def f (self):
        return 'FIOC'

>>28
With arguments (for example, use a dict):

>>> class Qwe(object):
...     @property
...     def f(self):
...         pass
...     @f.setter
...     def f(self, args):
...         print args
...
>>> q = Qwe()
>>> q.f = [None, 'asd']
[None, 'asd']
>>>

>>29
You are dangerously insane!

Also, you can't return a value this way. I suggest overloading the bitwise-or operator.

>>30
>>> class Qwe(object):
...     @property
...     def f(self):                          
...         a = self.result
...         del self.result
...         return a
...     @f.setter
...     def f(self, val):
...         self.result = val * 2
...
>>> q = Qwe()
>>> q.f = 12
>>> print q.f
24
>>>

>>31
Wow.

>>32
Why ``Wow.''?

>>31
Well, that sucks! As I said, using the bitwise-or is much more fun!

import functools

class Or_wrapper(object):
    __slots__ = 'op'
    def __init__(self, op):
        self.op = op
    def __or__(self, arg):
        return self.op(arg)
   
def partial(f, argc):
    if argc == 0:
        return f()
    return Or_wrapper(lambda arg: partial(functools.partial(f, arg), argc - 1))

def partial_method(f):
    return property(lambda self: partial(f, f.func_code.co_argcount) | self)


class Qwe(object):
    @partial_method
    def f1(self):
        return 42
    @partial_method
    def f2(self, a, b):
        return a + b

q = Qwe()
print q.f1
print q.f2 | 3 | 5
Though to be honest I think that C++ is a better language for such exercises: first of all, you can override destructor and implicit conversions to avoid silently ignoring calls with not enough arguments, second, you can override comma operator directly instead of using awkward substitutions.

>>1
Why does /prog/ dislike my use of tl;dr? I have never had any problems with concerning tl, because I dr.

>>12
Switch/Case is nice because it uses a jump table and one doesn't have to rewrite x == ... multiple times.

Constants are nice because if you accidentally try to change one, then the compiler will tell you about it.

>>33
I really cannot stand GNU quotes. They look fine in a terminal, but not anywhere else. They're almost as annoying as the people who put two spaces after every sentence.

>>35
Overriding the comma operators is evil. Hell, the comma *being* an operator is evil enough.

>>36
But if I do, I can write print x, 10, "asdf"; in C++! What is wrong with you, man!

To make it simple Python's few requirements for whitespace give your coding more freedom.
I don't want to have any requirements. I like freedom. So even though I may not think making an entire program without any intending is a good idea, I want the option.

Something I have to take a giant block of code and through it in a sort of loop. In those cases I just don't worry about indenting everything in the new loop and go with it.

>>9
Then who was CODE

>>38
you say this as though keeping track of correct indentation when generating code as opposed to just dumping block delimiters is HARD!

gtfo python hater. i bet you use ruby