On Mon, Jan 09, 2017 at 07:25:45PM +0800, Simon Lovell wrote:
The Good: Syntactically significant new lines Syntactically significant indenting Different types of array like structures for different situations Mostly simple and clear structures Avoiding implicit structures like C++ references which add only negative value Avoiding overly complicated chaining expressions like "while(*d++=*s++);" Single syntax for block statements (well, sort of. I'm ignoring lines like "if a=b: c=d") Lack of a with statement which only obscures the code
Python has a `with` statement. As a newcomer to this community, and apparently the language as well, do you understand how obnoxious and arrogant it comes across for you to declare what is and isn't "good" and "bad" about the language, particularly when you appear to know the language very well? Most of your comments aren't even a little bit objective, they're subjective judgements based on (I expect) what you are used to, and nothing more. Matters of taste, at best, and yet you're stating them as objective fact. So if you feel that my response is a tad blunt or even brusque, perhaps you can understand why.
The Bad: Colons at the end of if/while/for blocks. Most of the arguments in favour of this decision boil down to PEP 20.2 "Explicit is better than implicit".
This is the first time I've heard this ridiculous explanation for the use of colons! Where did you get it from? It sounds like the sort of nonsense that gets highly voted on StackOverflow. The reason for colons is a FAQ: https://docs.python.org/3/faq/design.html#why-are-colons-required-for-the-if...
No end required for if/while/for blocks.
Thank you Guido, for avoiding needing all those redundant and unnecessary "end" statements that other languages waste my time with.
This code block doesn't compile, even given that function "process" takes one string parameter: f=open(file) endwhile="" while (line=f.readline())!=None: process(line) endwhile
Assignment is not and should not be an expression, at very least not using the same = (pseudo-)operator which is used as an assignment statement. It may be acceptible with some other syntax that cannot be easily mistyped when you want == equality, but not = alone. But what is that obfuscated code meant to do? Operate on the file, one line at a time? This is simpler: with open(file) as f: for line in f: process(line) and it has the advantage of also automatically closing the file when the `with` block gets exited.
Inadequacy of PEP249 - Python Database Specification.
[...] I cannot comment on this.
Variables never set to anything do not error until they are used,
Fair enough, that is a minor annoyance occasionally.
No do-while construct
What do you mean by "do-while" and how do you expect it to differ from "while"?
else keyword at the end of while loops is not obvious to those not familiar with it. Something more like whenFalse would be clearer
Indeed. for...else and while...else are much more accurately described as for...then, while...then. The code in the "else" block is *unconditionally* executed following the for... or while... block, which makes the block a "then" rather than "else". To avoid that block, you have to jump out of the entire compound block, using "break", "return" or "raise". But we're stuck with the name now.
Changing print from a statement to a function in Python 3 adds no positive value that I can see
Consistency: print doesn't need to be a special cased statement. It does nothing special that a function can't do. So why make it a statement? As a function, it can be passed around as a first class value, used as a callback, monkey-patched or shadowed or mocked as needed. None of these things are possible with a statement. It can use the same ordinary syntax as other functions, instead of the bizarre and ugly special case syntax used as a statement: # Python 3 print(value, end='', file=sys.stderr) # Python 2 print >>sys.stderr, value, # note the magical trailing comma If Python was invented today, what arguments could anyone make for having print be a statement instead of a function? "It saves typing two parentheses." Anything else?
Upper delimiters being exclusive while lower delimiters are inclusive.
Dijkstra explained it well: http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html Half-open ranges are much superior for avoiding off-by-one errors than closed ranges.
This is very counter intuitive. e.g. range(1,4) returns [1,2,3]. Better to have the default base as one rather than zero IMO. Of course, the programmer should always be able to define the lower bound. This cannot be changed, of course.
It is true that starting counting at zero takes a bit of getting used to, and there are times when it is more convenient to start at one. But no one solution is ideal all the time, and we have to pick one system or the other, or else we end up with an overly complex syntax with marginal utility.
Lack of a single character in a method to refer to an attribute instead of a local variable, similar to C's "*" for dereferencing a pointer
The lack of single-character syntax for many things helps prevents Python code looking like line noise.
Inability to make simple chained assignments e.g. "a = b = 0"
Python does support chained assignment.
Conditional expression (<true-value> if <condition> else <false-value>) in Python is less intuitive than in C (<condition> ? <true-value> : <false-value>). Ref PEP308. Why BDFL chose the syntax he did is not at all clear.
What is "intuitive" to people who have learned C and C-influenced languages is a perplexing, mysterious enigma almost impossible to google for or look up in books. flag ? 1 : 2 means nothing to people who haven't memorized what it means. But Python's ternary syntax is actual grammatically correct English: 1 if flag else 2 and it puts one of the values first, in the most important part, instead of the flag.
The Ugly: Persisting with the crapulence from C where a non zero integer is true and zero is false - only ever done because C lacked a boolean data type. This is a flagrant violation of PEP 20.2 "Explicit is better than implicit" and should be removed without providing backwards compatibility.
Thanks for your opinion, but I prefer the status quo. Welcome to the list. -- Steve