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?

>>1
I've also got a problem with C-like syntaxes.

>>40
Nope, I use C. You've probably never used it, it's a language without retarded restrictions on white space.

>>42
The initial development of C occurred at AT&T Bell Labs between 1969 and 1973
LOL! 'nuff said.

<-- dubz, check'em

class Qwe (object):
    @property
    def f (self):
        del self # fuck you

Properties in Python are so well liked that they have an entire British web page devoted to them.

http://www.pythonproperties.co.uk/

>>46
properties are the best python-specific feature apart from syntactic indentation

>>46

pretty dang sad.
http://www.pythonproperties.co.uk/

>>38
You know, there's programs/mini-programs/routines that could indent such code for you. If you editor doesn't have them, it sucks.

Also, you shouldn't even have that freedom/option, because eventually at some point in time, somebody else is going to have to read your code, and they're going to hate you for it. If you let people abuse something, they will. And so for indenting/bracketing, I think the option to abuse it should be abolished all together, for the good of the public.

>>40
Don't use ad-hominem attacks please.

I do not know anybody, who is legitimately decent or better at C++, who puts their { on a separate line. Anybody with more than half a brain uses OTBS


if (something) {
　　do_something();
} else if (something_else) {
　　do_other_thing();
} else {
　　crash();
}

>>50

I like this pattern, cuz say you copy and paste line 3, then you get:


if (something) {
　　do_something();
} else if (something_else) {
} else if (something_else) {
　　do_other_thing();
} else {
　　crash();
}

and whatdoyaknow, valid c code! No need to type your own bracket structure again. Same with deleting lines:


if (something) {
　　do_something();
　　do_other_thing();
} else {
　　crash();
}

You'll still have to do more editing to get the correct logic of course, but at least you don't need to make more syntax constructing.

>>51

Yes, there are reasons it is used universally and called the One True Brace Style.

>>50
This is ugly. It should be written like this:
if (something)
{
    do_something();
}
else
{
    if (something_else)
    {  
        do_other_thing();
    }  
    else
    {  
        crash();
    }  
}


if (something)
  { do_something(); }
else
  { if (something_else)
      { do_other_thing(); }
    else
      { crash(); } }

One True Lispy Style
something ? do_something()
          : (something_else ? do_other_thing()
                            : crash());

>>49
You know, there's programs/mini-programs/routines that could indent such code for you


if a:
b()
c()
d()

hmm... how should this be indented?

>>56
Isn't it obvious?
if a: b()
c()
d()

I find this to be the nicest method:

if (condition)
{
    //do something!
}
else
{
    //do something else!
}

>>57
not if i really meant


if a:
    b()
    c()
d()

>>50
Ditto.

>>53
>>54
>>58
There's a special circle of hell just for people like you.

>>56
>>59
Oh, I see your point. I suppose such a thing could only be done in brackets languages. Also though: 1) Porting loops to or from a brackets language would still be simple. 2) Any decent editor will allow you to select a block of text, and simply tab it all over by hitting the tab key.

Still, that's not a valid argument against it though. You should be indenting it as you code.

>>60
class Anus:
  def tryhax(self):
    while self.nothaxxed:
      if self.anuslock == True:
        try:
          anuslock = self.getAnusLock
          ...
        except AnusLockedException:
          ...
      else:
        try:
          self.hax()
          ...
        except FailedAnusHaxxingException:
          ...

I, then, realize that tryhax does not only work with anii, but with anything that can be haxxed! So I factor it out of (my) Anus.
I also realize that the code is terrible!, the if can be removed and the trys can be merged into one. After the unlimited kill/yank works, the indentation is a fucking mess. ``I know!'', I say, ``I'll just use an autoindenter for Python!''. Now I have uncountably many problems.

>>60
>>50
>>53-54,58
>>56,59

Yeah but then again, who doesn't indent their code?

>>63
I don't.

- It's annoying to do
- It makes the code look longer than it is
- It makes the code hard to read and modify later, no matter what your opinion may be.

In addition I like to do things like this: for(int i=0;i<5;i++){if(a!=x){fuck();gaysex();}else{shit();v=5;slam_turd_in_eye();}}
...and it just looks and feels way better on one line.

>>64
I pity whoever will have to read or fix your code.

Curly APL ninja.

>>65
I pity whoever refuses to use code formatting tools.

>>64
You should never put conditionals inside tight for-loops, you will be forgiven in this case since it's only five iterations long.

Also since the if test doesn't do any testing with the i variable you can either move it outside the for loop, or your code relies on mutating global variables inside of functions which is HORRIBLE and not thread-safe.

>>67
Tab and backspace keys?