python - tail stuck under the rocks?

[kalberts]

I my days, when C squeezed out Pascal, one argument you could frequenty hear in favor of C was "There's so much typing in Pascal! In C, you can just use {}, and don't need those BEGINs and ENDs. You don't need to write FUNCTION or PROCEDURE, and so on". So we threw out a well designed, fairly safe language in favor of a "you asked for it, you got it" language, to save a few keystrokes. To some people that wasn't enough; even braces required keystrokes (even shifted ones, on most keyboards). Let's get rid of those! And we got Python. If you really want to save keystrokes, why don't you go for APL? Other crazy ways of saving keystrokes is to insist on using tabs rather than spaces, sometimes with semantic significance. (No, I am not talking about Whitespace, but seriously meant file formats.) Obligatory Geek & Poke[^]. You may argue that keywords do not reduce complexity - but it does help you to understand that this closes the while loop, that closes the method definition, and there is the end of the class definition. Besides, distinct keywords help the compiler back on the track after an error, and facilitates much more meaningful error messages.

[kalberts]

Cobol - and Fortran - didn't interpret indents semantically. The coding sheet (or individual line, for those who never saw a coding sheet) was divided into column (or fields of the line), with different functions: Label, line continuation marker, structure level markers, line sequence number etc. This was defined by the column (/field): Within the main field, you could indent or not without changing the semantics. The coding sheets had heavy lines separating the columns; you never misplaced any element accidentally. So even though positioning (in one column, or another column) was significant, it wasn't quite like Python but far more controlled and well defined, and it was very difficult to make mistakes that could pass by without being detected. Those languages had far worse defects ... :-)

[Member 7878116]

The indentation is part of Python, take it or leave it. Where it really gets annoying is when you try to cut'n'paste snippets. 8 space characters does not equal 1 tab. I use Vim with a tab equivalent to 2 spaces for real confusion.

[Asday]

Man, us "Pythonistas" are getting tired of this criticism. Do you indent your C? Of course you do, it's impossible to read poorly indented code. Does your C compiler whinge at you when you forget curly brackets? Of course it does, they define blocks. Except, you're already defining blocks for human eyes with indentation. Why do you also need to define them for machine eyes with curly brackets? Source code is for humans, not machines.

[Ri_Ho]

Yes, just one of the many "features" that relegates python to a 'fast food' language. What's not a 'fast food' language - Tcl\Tk Net: Take a look at Tcl and then you will asking yourself "Why does python even exist?"

[rk2153]

This single feature has held me back from investing time into this language. Doing some RCA my opinion is that technology like language generators has promoted the creation of marginally different quite a few languages—so called jvm languages — There was php and Perl. Anyone not intellectually lazy and a bit more egoless would have perfected php instead of whipping up a new language with brain dead features. Not sure python space or dos backslash takes the top spot for an epoch of productivity killer. Backslash inventor now admits that is his worst decision.

[Member 12247860]

More python indention confusion ???

# Python program to check if the input number is prime or not

num = 15

take input from the user

num = int(input("Enter a number: "))

prime numbers are greater than 1

if num > 1:
for i in range(2,num):
if (num % i) == 0:
print(num,"is not a prime number")
print(i,"times",num//i,"is",num)
break
else:
#print(num % i)
print(num,"is a prime number")

if input number is less than

or equal to 1, it is not prime

else:
print(num,"is not a prime number")

What the heck is that else: statement doing out there, who does it belong to? :)

[kalberts]

So maybe we should shut up and accept that Python Is, After All, Doing The Right Thing? No. If your attitude is that "Noone should keep on critizising my language of choice!", then maybe you should search for another language. There is a distinct difference between visualizing the semantics through indentation (and to some degree braces), and to assign semantics to the intentation in itself. If you think assigning semantics to use of whitespace, you should take a look at the Whitespace language. There you can get everything you want in that direction! Whitespace semantics is crazy, judged from a readability and reliability point of view. Nothing related to indentation has any semantics in the C class of languages, so pretending that they are similar is a complete misunderstanding. A week or two ago, someone posted an April 1st proposal from Bjarne Strostrup (I am assuming that it really was written by him), a proposal about extending the operatior definitinions of C++, to allow operators to be defined for whitespace. He goes on to propose operator definitions for lack of whitespace. Sometimes, I suspect that Python addicts never noticed the publication date. (I did save Strostrup's proposal, but not the link. I might be able to dit it up from my browsing history, if anyone insists.)

[Asday]

>So maybe we should shut up and accept that Python Is, After All, Doing The Right Thing? Strawman. >If your attitude is that "Noone should keep on critizising my language of choice!", then maybe you should search for another language. Ad hominem and straw man. >you think assigning semantics to use of whitespace, you should take a look at the Whitespace language Strawman. Whitespace makes the prose easier to read, it's like a foil. >Nothing related to indentation has any semantics in the C class of languages, so pretending that they are similar is a complete misunderstanding. Either a strawman or you're really really stupid. My point is that everyone who writes good C indents their code blocks. It's almost incredible to me that you could fail to understand that, but looking at how your post opened I figured I'd give you the benefit of the doubt. >A week or two ago, someone posted an April 1st proposal from Bjarne Strostrup (I am assuming that it really was written by him), a proposal about extending the operatior definitinions of C++, to allow operators to be defined for whitespace. He goes on to propose operator definitions for lack of whitespace. Sometimes, I suspect that Python addicts never noticed the publication date. What relevance does that have to anything? Did I say that C++ should do away with braces and use indentation instead?

[dpminusa]

I experienced this when Python 3 was released. Is this a Python 2 throw-back other than the semi-colon Python 3 wants?

"Courtesy is the product of a mature, disciplined mind ... ridicule is lack of the same - DPM"

[kalberts]

If "you pythonians" are so sensitive and "tired of this criticism", I suggest that whenever you see any critical remark about Python, you leave that discussion thread immediately. When you answer to voices critical to Python semantic indentation with a "tired of this critisism", it is very close to "shut up - we don't want to hear about it", only your opinion about Python should be heard. When I am told, directly or indirectly, to shut up, it is not strawmanning to infer that you believe you have The Right Answer on the issue. When you state that you "are tired of this critisism", it is quite clearly a request from you to stop the critisism. Even though I clearly understand you that way, I still made it conditional, if it is so, then... That is not an "ad hominem attack", it is drawing conclusions based on your statement, on the condition that I have interpreted it correctly. An given that explicit condition, it is certainly not strawmanning. Others may read "us Pythonians are tired of this critisism" as "we welcome critical opinions on this issue", but I guess the way I read it is more like the common interpretation. Sure, we use indentation to ease reading in almost all modern programming languages, but the critisism was on the semantics of indentation - which is non-existent in C. You were the one who brought in C indentation, and then you blame me for strawmanning when I reject your invalid parallels between Python and C. Isn't that sort of turning things upside-down? I pointed out that Python semantic indentation is conceptually different from C layout for readability, and you suggest that I am "really stupid" and I "fail to understand" (but this is of course not ad hominem attacks...). I cannot suggest that you seem to not grasp the difference between assigning semantics to whitespace and not assigning semantics to whitespace - that would be another ad hominem attack, so I am not saying so. I must assume that you understand the difference. But then - maybe because I am "really stupid" honestly "fail to understand" why you, with your full comprehension of semantics and non-semantics, do not see the relevance to Strostrups proposal to assign semantics to whitespace to the degree that you can treat whitespace as an operator. He shows the absurdity of whitespace semantics by suggesting that even the abscence of something that (in C) is without semantics should be given a semantic interpretation... Actually, that

[DerekT P]

Fortran: screen?? You were doing it wrong. If you'd had the punch card deck you'd have spotted the mistake straight away... :laugh:

[kalberts]

During my first student year, we actually did punch cards! Or, we filled in coding sheets, handed them in for punching by trained typists (especially well trained in mistyping...), and the turnaround time could be 36-48 hours in rush periods. Interactive terminals on 300 bps serial lines were reserved for graduate students. During the second year, we got three 16 bit minis, each handling 16 screens at 9600 bps, and a full screen editor, which made the big and proud Univac 1100 mainframe look so much like a clunky old wreck that we were ordered to reduce the line speed of the mini's terminals to 1200 bps, so that we did not put too much shame to the great mainframe. (The TAs, I was one, managed those three minis more or less ourselves.) Then (fall of 1979) Fortran was replaced by Pascal as the language for the "101 Basic programming" course for half of the students. Some departments refused to switch - noone in their branch of engineering would ever be programming anything but Fortran! Other departments accepted Pascal only conditionally: The EE departement accepted it only if the Computer Science students (like myself) were required to take a course which covered e.g. 3-phase power distribution networks... The incident with the I/l mixup happened around 1985, after I had completed my degree and was working at the University Computer Center. The guy with the problem was in the Mechanical Engeneering department; they still clung to Fortran as The Only Language at that time. But they did accept screens then! (Besides, I don't think there ever was delivered any punched card reader for the 32-bit supermini series that they were using.) A few years ago, a studymate of mine, working at the University supercomputer center, surprised me by telling that for FEM, weather forecasts and similar typical supercomputer applications, Fortran is still the language of choice! It is no longer Fortran IV, though... Strangely enough, I cannot find on the Internet who said, in the discussions of the proposed language extensions to become Fortran 77: "I don't know what programming languages will look like in year 2000, but they will be called Fortran..." - one of the big gurus of the time, maybe Hoare or Dijkstra. When I paraphrased that statement in my earlier post, it was intended as a historical reference, but it seems like the quote has not survived history. Whoever said it was perfectly right: Fortran 2003 is called Fortran, but looks nothing like Fortran IV.