[Python-ideas] Making colons optional?
leif.walsh at gmail.com
Thu Feb 5 23:08:24 CET 2009
2009/2/5 Scott Dial <scott+python-ideas at scottdial.com>:
> Christian Heimes wrote:
>> def method(self, some, very, long, method,
>> going, over, lots,
>> and, lots,
>> and, lots, of, lines):
> This example line-continues via parentheses, so why isn't the
> right-paren enough?
Because I can sweep the code visually for colons very easily. Consider:
>>> def method(self, some, very, long, method,
... going, over, lots, of,
... lines, with, some=(default, argument,
... lists, that, are), also=(continued),
... and=None, some=None, more=1):
We could keep getting more and more complicated, certainly, but I
think I've made my point, and I'm probably not going to convince you.
>> if (some() and some_other() or some_more(complex=(True,))
>> and a_final_call(egg=(1,2,3))):
> This example uses the same mechanism as above. BTW, I tend to indent
> this as:
> if (some() and some_other() or some_more(complex=(True,))
> and a_final_call(egg=(1,2,3))):
> With or without the colon, and it's more readable than your version
> (IMHO), and clearly the colon provides no aide to it.
For your definition of 'clearly', perhaps. I get a lot of help out of
>> You see a line starting with "if" but not ending with a colon. You know
>> for sure that you have to search for a trailing colon in order to find
>> the end of a very long "if" line.
> I'd also add that every C programmer has dealt with this before with
> single-statement if clauses that require no braces. This is after all
> the reason why I indent line-continued test expression the way I do..
This is why good C programmers always use braces around one-liners. :P
>> Yes, the colon is extra noise but it's the kind of good noise that makes
>> life more joyful like the noise of rain on a roof. Did you notice that
>> I'm using a colon in my regular postings, too? I've used two colons to
>> separate my text from the examples. Colon separators are natural to me.
> All said, I would prefer to keep the colons as well.. I like regularity
> of colon<=>suite equilibrium. Even if the splicing operator spits in the
> face of it, rarely do you see [x:y] line-continued to leave a naked
> colon at the end of the line.
If I were code-reviewing something with [x: at the end of a line, I'd
fire the programmer instantly. There's no excuse for that kind of
More information about the Python-ideas