[Python-ideas] Making colons optional?
Riobard Zhan
yaogzhan at gmail.com
Fri Feb 6 07:42:34 CET 2009
On 5-Feb-09, at 6:05 PM, Steven D'Aprano wrote:
> A switch/case statement is equivalent to a series of if...elif...
> statements, so it would be inconsistent to require colons in a
> switch but not in if...elif.
Python does not have switch/case statements. Java/C does not have
significant indentation. Do you mean Java/C should also use colons
after if's, given that they use colons after case's?
> My point was that both languages (Pascal and Python) use colons in a
> way which is very familiar and standard to the English language,
> albeit different usages in the two languages. If newbies to either
> language find colons confusing, that's indicative of the general
> decline of educational standards. If people whose first language is
> not English have trouble with colons, then I sympathize, but then so
> much of Python is based on English-like constructs that colons will
> be the least of their problem.
I did not notice anybody complained about colons because their first
language is not English. Why bring it up?
Yes, colons are natural in English. It is even more natural in English
to end sentences with periods. Do you want to do that in Python?
Erlang does that, and it's ugly.
you cannot
simply copy
what we do in English
to
programming languages
after all
we do not
carriage-return and indent
our sentences
like Python
>> Yes I agree with you that many people like colons. What bothers me
>> is that some people dislike them, but not given the choice to avoid
>> them. We don't like semicolons in Python, but what would stop a
>> hard-core C users to end every statement with a semicolon?
>
> Peer pressure. Everybody would laugh at their code and think they're
> foolish.
Same for semicolons, I would laugh and think it's foolish to type
colons when we have to carriage-return and indent right after them
anyway.
> Flexibility of punctuation hurts computer languages, not helps.
So we should really forbid
x, y = m, n
and instead force
(x, y) = (m, n)
>> By making trailing colons OPTIONAL, we can probably have the chance
>> to field test. If people really think colons improve readability
>> that much, they can still use them, just like we feel semicolons
>> are line noise and void them if possible, even though we CAN use
>> them. I don't think we will ever lose anything to make colons
>> optional.
>
> Of course we do. It makes the language bigger and more complex. The
> parser has to be more complex. Who is going to write that, maintain
> that?
Do you really think making colons optional makes Python bigger and
more complex? One less thing to worry about in addition to indentation
makes the parser more complex?
> Every time you write a def block you have to decide "colon or not?".
> Most people will standardize on one or the other, and the decision
> will go away, but they will still need to read other people's code,
> and then colon-haters will be unhappy, because they have to read
> other people's code containing colons, while colon-likers will be
> unhappy, because they have to read other people's code missing colons.
>
> Optional colons are the worst of both worlds, because it makes
> *everybody* unhappy.
"Every time you start a new line you have to decide "semicolon or
not?". Most people will standardize on one or the other, and the
decision will go away, but they will still need to read other people's
code, and then semicolon-haters will be unhappy, because they have to
read other people's code containing semicolons, while semicolons-
likers will be unhappy, because they have to read other people's code
missing semicolons.
Optional semicolons are the worst of both worlds, because it makes
*everybody* unhappy. "
Does that happen? I would argue if colons are made optional, in the
long run we will treat them like dinosaurs. If you disagree, think
this: try convincing hard-core C users that they should really get rid
of semicolons.
More information about the Python-ideas
mailing list