Steve Holden wrote: > Michael Hobbs wrote: > >> Ben Finney wrote: >> > [...] > >>> A use case. What problem is being solved by introducing this >>> inconsistency? >>> >>> >> The same problem that is solved by not having to type parens around the >> 'if' conditional, a la C and its derivatives. That is, it's unnecessary >> typing to no good advantage, IMHO. I was coding in Ruby for several >> months and got very comfortable with just typing the if conditional and >> hitting return, without any extra syntax. When I came back to Python, I >> found that I felt annoyed every time I typed the colon, since it >> obviously isn't required. The FAQ says that the colon increases >> readability, but I'm skeptical. The indentation seems to provide more >> than enough of a visual clue as to where the if conditional ends. >> >> > So you'd also like us to shorten the names of the builtins and the the > keywords? Why bother with "def" when we could just use "d", "class" when > we could just use "c"? Or *does* readability matter to some degree? > > Like I said in that paragraph, removing the colon wouldn't seem to degrade readability *that much*, if at all. Personally, even though I find typing the colon to be a small annoyance, that annoyance exceeds any improvement to readability that it might provide; especially considering that indentation sticks out like a big red sign saying the code block starts "HERE, HERE, HERE".
>> As far as using the FAQ as gospel, the FAQ also provides arguments for >> why there isn't a with statement or a switch statement. The with >> statement has already been implemented in 2.5 and there's a PEP to >> implement switch (3103). >> >> > But the "with" statement isn't the one that "with" was reserved for in > the FAQ, which is really talking about the same kind of "with" statement > that Visual Basic uses: an implied left operand for unary "." operations. > > Yeah, okay, I didn't read through the details of the PEP. I picked a bad example to illustrate a point that is still true. The FAQ also tries to argue that it's a Good Thing that join() is a string method, not a list method. It also tries to argue that there's a good reason that lists are different than tuples. I don't think it would surprising that many Python developers don't really buy those arguments either. - Mike -- http://mail.python.org/mailman/listinfo/python-list
