On Sat, 30 Jul 2016 08:15 pm, BartC wrote: > Interesting use of 'pass' in this example: > > http://pastebin.com/aYJdgEL4 > > (I do believe he's using 'pass' as 'end'! Although he misses some out in > that case.)
I wouldn't call it so much "interesting" as "a good example of how not to program". All languages -- human and programming -- involve certain quirks, or features which are matters of taste. If it a sign of a poor programmer that ignores the common idioms of a language and writes in another language's "grammar". "If so smart Yoda is, how come English speak he cannot?" People are more forgiving off grammatical errors and weird idioms than computer programs, but still, there are conventions to follow. In English, we can talk about having a quick meal of fast food, but not a fast meal of quick food. Our computers are powerful, never mighty, and if we ever invent a time machine, we'll travel into the past, not onto the past. You can get away with breaking a language's idioms for humour: https://www.youtube.com/watch?v=MNyG-xu-7SQ or, if you're *really* talented, as art. See, for example, James Joyce's Finnegan's Wake, which is as unidiomatic as it is possible to be while still being (just barely) English, but deliberately so. (As opposed to "ee cummings", who was and is lauded far beyond his actual talent.) Th same principles apply to programming languages. But outside of highly optimized code, which is often ugly, or examples of code as art (like code golf, Obfuscated C and Underhanded C competitions, multi-language hybrid code, esoteric languages etc.), the aim of programming should be to maximize *human* communication. And that usually means writing in the idiomatic style of the natives. There are no awards for trying to hammer the round pegs of Algol grammar into the square holes of the Python interpreter. (1) Using "pass" as a form of "end" is simply bizarre. (2) Python allows the semi-colon for the convenience of command-line users, where it is sometimes difficult to write multiple lines of code. Using it inside a .py file is a sign of somebody who is not a native speaker. (3) Separating statements by variable numbers of spaces, between 1 and 13 by my count, is just weird. Given the lack of Python fluency, the lack of documentation and meaningful comments, the unusual (for Python) idioms that hurt readability, and some very odd names (there is one constant called "ONE" with the value 1073741824), the overall impression I get is that the author of that file simply isn't a good programmer. [...] > As I've mentioned, Python also uses explicit block delimiters in the > form of else, elif, except, finally (and whichever ones I've misssed): You are wrong. They are not delimiters. They *begin* a new block, they don't end the previous one except as a side effect of beginning a new block. if condition: block new block It is the dedent (outdent) that ends the if block. "new block" is permitted to be an elif or else statement, of course, but you cannot write: if condition: block else: statement because "else" is not an "end of if" statement. It *begins* a new statement. > if x: a; b elif y: c; d elif z: e; f else: g That's not legal Python syntax. > In the above syntax, it would be: > > if x then a; b elsif y then c; d elsif z then e; f else g fi > > Doesn't it look like there's something missing in the Python? No it does not. > Both the > 'fi' or 'end', and the possibility of an 'h' statement. > > Note the Algol68-style style is more free-format where indents are not > significant. Good for Algol. To my eyes, that makes it harder to read: too many unneeded "ends", to great a risk that the visual structure of the code doesn't match the logical structure of the code. > Anyway, if you're going to talk about annoying things forced upon you by > the language, what about: > > ":" after "else" What about it? When you write a list of items in English, it is more idiomatic and natural to end the clause with a semi-colon: - item one - item two - item three than without it. I've read Cobra code which is very like Python except (among other changes) they've dropped the semi-colons It simply looks wrong Like sentences without punctuation Or perhaps like an painting on a wall just every so slightly on an angle > "()" in "def fn():" I could go either way with that. > "()" in "print (x)" for Python 3 Why? Do you object to other functions using parentheses? > "for i in range(N):" just to repeat a block N times... Why should there be special syntax just for repeating a block N times? There's a general purpose for-loop which performs iteration. Why do you need special syntax to do what it already does? We have a general "if" clause for doing conditional branching. Would you insist on a special purpose if syntax for testing if a number is 2? if number == 1: # general case if number == 7921 # general case iftwo number: # special syntax > That's apart from the obligatory indents which, with an 'end'-delimited > scheme, are not always necessary. Of course they're necessary. The participants of the old "indent style wars" of the 80s and 90s didn't agree on much, but they did agree on one thing: - if you write code without indentation that matches the logical structure of the code, you're a bad programmer. End of story. As far as I am concerned, the 97% of languages which allow the visual structure of the code to differ from their logical structure are BAD LANGUAGES. -- Steven “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
