Can we please, please stop talking about how Python's forced indentation makes code readable? The "forced" part is not an issue. At all.
Ever since structured programming was invented, proper indentation is the first basic thing that makes code more readable. It's so basic that people don't even seem to think about it.
The idea that Python programmers wouldn't indent their source code properly if not for the language rules is ridiculous! Same as all other even remotely competent programmers.
Python's indentation rules don't make Python code more readable, because proper indentation is the norm in any language. And if you have to be forced to indent your code, no language can save you from yourself.
All well written programs are indented properly, but not all properly indented programs are well written.
It’s amusing how people twist trains of thought into ridiculous ideas.
The point of Python’s use of indentation is not that it forces you to write clean code. As you showed, that sort of argument is ridiculous.
Rather, the impetus behind its use of indentation is that since all good code is properly indented, the language can actually make use of the presence of indentation and thereby relieve you of having to mark blocks up in some visually noisy way.
I happen to think that this has disadvantages too grave to ignore, and is therefore a bad idea, but as a design decision it isn’t absurd in the way that that the straw man is that most people attack instead.
Re:straw man
Eric Wilhelm on 2008-08-23T19:29:42
Well, the straw man keeps attacking people in this case.
Found in some python:
except NoSectionError:
# How the fsck do I leave an empty except block?
xyzzy = 3.14159265Sigh... All of this confusion and noise for lack of bacon in the syntax. Of course, I guess he could have read the documentation and found that the one true way to not throw a specific exception is to put 'pass' in the except block. This is where "the one true way" bites you, because people will always find illogical and unexpected ways to do things another way (ironically, in response to having been cornered by the one true way.) I'm sure I could go read the documentation and find some (perhaps syntactically inconsistent) way out of that corner (or not, you never know with python), but I've got better things to do today than bash on a baconless language.
passthe{}please.Re:straw man
Aristotle on 2008-08-24T01:52:00
What I wrote was not meant as an argument in favour of using indentation to avoid delineation for blocks. I believe that there are many good reasons to denote blocks explicitly.
All I was saying is that the impetus for using indentation to denote blocks was not to force programmers to indent properly. People should stop wasting their time arguing against a ridiculous straw man. There are plenty of good criticisms to make about the conclusion (that one can rely solely on indentation for syntactic cues) once you accept the premise (that improper indentation is not worth supporting) – like the one you made, f.ex.
(My own favourite criticism is that explicit syntactic markers allow editors to 100% correctly re-indent code for me after I shuffle slabs of code around while refactoring. With indentation as syntax, there is no way for the editor to avoid enlisting the aid of the user.)
Arguing that forced proper indentation does not improve programs just means you are violently agreeing with the premise without realising that you missed all the argument that was hung on this point. At best you end up looking clueless, but in any case you don’t contribute anything meaningful to the debate.
Re:straw man
Eric Wilhelm on 2008-08-24T05:13:57
The premise that blocks implicitly delimited via indentation "should suffice" is flawed, yes (because we want a programming language to be expressive, and blocks are not just a procedural construct (they are also a primitive (and I like bacon.)))
Perhaps "forced indentation makes your code better" is indeed some kind of brilliant straw man which prevents the majority of users from realizing that the bacon has gone AWOL?
Anyway, "straw man bites dog" was maybe not the right way to put it and I'll just assume that your use of 'you' in this comment is intended in the fourth person, because perhaps we should move on to address the real problem where Perl is not seen as a preferred (or accepted) language by some (many?, or is it just the talkative ones?) tech managers.
That is: why does $company think Python is so great?. Is it because of the caliber of Perl developer they are able to hire, some perception of "maintainability", or (I suspect) a tendency to latch on to the prescriptive "one true way" notion as something that they will be more easily able to manage and meter?
Re:straw man
Aristotle on 2008-08-24T05:49:20
There is much more to Python than just this one flaw (disguised as a benefit). I don’t know terribly much about it, but f.ex. I like the
__CALL__(I think) mechanism whereby you can treat an object like a function and “call” it. That gives you some neat ways to do things that in Perl are a lot more cumbersome. The language is also a lot more regular than Perl, which is not always an advantage from a linguistic point of view, but has a strong allure on the people coming at languages from a symbolic logic point of view.As for Perl, no one makes noise about it, but it’s still used big style. I’m not sure if that doesn’t maybe make us the new COBOL programmers, so I don’t know if this is something to be proud of or not.
Also, I don’t really see this as a competition. Perl, Python and Ruby are, ultimately, extremely similar languages. To think that there is a huge rift between the Perl and Python camps is just narcissism of small differences. This is part of what I meant when I said it makes you look clueless to argue about silly straw men.
Re:straw man
btilly on 2008-08-25T22:42:19
What does __CALL__ make more convenient? The convenience can't be that big because all you save is slipping a method name.
Anyways if you need that in Perl, use overload to overload '&{}' and your object can now be called as a function. Or (in a way that is more obvious to the maintenance programmer) you can just use an anonymous function as your object.
Re:straw man
Aristotle on 2008-08-26T07:40:45
The convenience is not big, but big enough to matter. This kind of thing is easy in Perl, but effortless in Python.
Overloading
&{}is less convenient: either you pass a function reference, in which case that piece of code has a marked syntactical difference from all your other methods, or you pass a method name, in which case cause and effect are separated (and you need to come up with an extra identifier; plus there’s still lots of extra syntax to set this method apart).Another part of the difference is due to the absence of sigils and explicit references in Python. One particular effect is that you can assign an object with
__CALL__to a property of another object and then for all intents and purposes it looks just like a method. In Perl, it takes sufficiently much more work to do something like that that you’re likely to go for another design.I absolutely grant that this is a pretty small thing, but it was one of the bits that struck me as “this would be so nice to have in Perl.” As I said, I have not enough experience with Python to suggest what I would consider its real strengths relative to Perl if only I did know about them.
