Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-4041-

Pythonic Whitespace

Name: Anonymous 2011-11-05 21:16

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?

Name: Anonymous 2011-11-05 21:56

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.

Name: Anonymous 2011-11-05 22:00

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(

Name: Anonymous 2011-11-06 3:22

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

Name: Anonymous 2011-11-06 21:28

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

Name: Anonymous 2011-11-06 22:19

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

Name: Anonymous 2011-11-06 22:50

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.

Name: Anonymous 2011-11-07 0:16

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

Name: Anonymous 2011-11-07 4:26

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

Name: Anonymous 2011-11-07 5:29

>>1
My favourite C code structure mindfuck:

}

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

Name: Anonymous 2011-11-07 5:31

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

}

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

Name: Anonymous 2011-11-07 5:35

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

Name: Anonymous 2011-11-07 7:30

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

Name: Anonymous 2011-11-07 7:54

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

Name: Anonymous 2011-11-07 8:14

FIOC gtfo

Name: Anonymous 2011-11-07 8:47

>>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();
}

Name: Anonymous 2011-11-07 8:49

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

Name: Anonymous 2011-11-07 8:53

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

Name: Anonymous 2011-11-07 8:54

>>18
*newline
Damn iPhone autocorrect.

Name: Anonymous 2011-11-07 9:26

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

Name: Anonymous 2011-11-07 10:42

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

Name: Anonymous 2011-11-07 10:47

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

Name: Anonymous 2011-11-07 10:52

Lisp is shit.

Name: Anonymous 2011-11-07 11:12

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

Name: Anonymous 2011-11-07 11:24

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

Name: Anonymous 2011-11-07 11:24

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

Name: Anonymous 2011-11-07 11:36

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

Name: Anonymous 2011-11-07 11:38

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

Name: Anonymous 2011-11-07 11:46

>>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']
>>>

Name: Anonymous 2011-11-07 12:30

>>29
You are dangerously insane!

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

Name: Anonymous 2011-11-07 12:35

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

Name: Anonymous 2011-11-08 6:59

>>31
Wow.

Name: Anonymous 2011-11-08 8:26

>>32
Why ``Wow.''?

Name: Anonymous 2011-11-08 12:37

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

Name: Anonymous 2011-11-08 12:58

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

Name: Anonymous 2011-11-08 13:28

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

Name: Anonymous 2011-11-08 13:40

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

Name: Anonymous 2011-11-08 13:49

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.

Name: HAXUS THE TROLLOLOLOL 2011-11-08 13:53

>>9
Then who was CODE

Name: Anonymous 2011-11-08 14:00

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

Name: Anonymous 2011-11-08 14:52

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

Name: Anonymous 2011-11-08 15:17

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

Name: Anonymous 2011-11-08 15:31

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

Name: Anonymous 2011-11-08 18:09

<-- dubz, check'em

Name: Anonymous 2011-11-08 18:52

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

Name: Anonymous 2011-11-08 18:57

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

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

Name: Anonymous 2011-11-08 21:05

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

Name: HAXUS THE SAGE 2011-11-10 0:20

>>46

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

Name: Anonymous 2011-11-11 23:57

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

Name: Anonymous 2011-11-12 3:26

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();
}

Name: Anonymous 2011-11-12 4:55

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

Name: Anonymous 2011-11-12 6:04

>>51

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

Name: Anonymous 2011-11-12 6:17

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

Name: Anonymous 2011-11-12 7:45


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

Name: Anonymous 2011-11-12 8:01

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

Name: Anonymous 2011-11-12 17:48

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

Name: Anonymous 2011-11-12 17:56

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

Name: Anonymous 2011-11-12 18:06

I find this to be the nicest method:

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

Name: Anonymous 2011-11-12 18:55

>>57
not if i really meant


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

Name: Anonymous 2011-11-14 5:05

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

Name: Anonymous 2011-11-14 5:27

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

Name: Anonymous 2011-11-14 5:36

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

Name: Anonymous 2011-11-14 13:43

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

Name: Anonymous 2011-11-14 14:25

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

Name: Anonymous 2011-11-14 14:56

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

Name: Anonymous 2011-11-14 15:34

Curly APL ninja.

Name: Anonymous 2011-11-14 17:15

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

Name: Anonymous 2011-11-14 19:16

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

Name: Anonymous 2011-11-17 16:08

>>67
Tab and backspace keys?
Don't change these.
Name: Email:
Entire Thread Thread List
All trademarks and copyrights on this site are owned by their respective parties. All comments and posts are the responsibility of their own posters.
- Tinychan + 2ch Mode -