Hi everybody,
I'm proposing to make colons optional. Let me call this feature
Colonless Python. To show what it is like without colons, here are
some examples adapted from the official tutorial.
---------- sample code -----------
if statement
============
if x < 0
x = 0
print 'Negative changed to zero'
elif x == 0
print 'Zero'
elif x == 1
print 'Single'
else
print 'More'
for statement
=============
for x in a
print x, len(x)
while statement
===============
# Fibonacci series:
# the sum of two elements defines the next
a, b = 0, 1
while b < 10
print b
a, b = b, a+b
function definition
==================
def fib(n) # write Fibonacci series up to n
"""Print a Fibonacci series up to n."""
a, b = 0, 1
while b < n
print b,
a, b = b, a+b
class definition
================
class MyClass
"""A simple example class"""
i = 12345
def f(self)
return 'hello world'
------------- end --------------
Please note that like semicolons, one can still write one-liners with
colons like
if x > 0: y = z; x = y
or
for each in range(10): x += each; x -= each**2
I'm proposing this due to several reasons, namely
I noticed a strong tendency to forget colons by new users of Python
in a second-year computer science undergraduate course. The students
seemed not getting used to colons even near the end of the course. I
guess it is probably because they learn Java and C first, both of
which do not have colons. What other languages do you know that
require colons? Colons seem to be a trap for new Python users from
other languages.
We already have indentation to visually separate different levels of
code. Why bother with those extra colons at all? They should be
optional just like semicolons are optional (and discouraged) for line
breaks. I doubt we will ever lose much, if any, by omitting colons.
I find colons pretty annoying. They interrupt mental flows of
thinking. I have to do a mental break at the end of conditionals,
loops, function and class definitions, and then a physical break to
type "SHIFT+;" to get the colons before I continue on the subsequent
lines. It's not really a big issue, but it is annoying.
What do you think? Specifically, may I ask your feedback on the
following issues?
Do you find yourself sometimes forget to type them and the
interpreter complains?
Are the above pieces of code less readable due to lack of colons?
What problems do you think will occur if colons are made optional?
PS. I had some preliminary discussion in the comments on one of
Guido's blog posts about Python's history. If you are interested, you
can check out this link
http://python-history.blogspot.com/2009/01/pythons-design-philosophy.html#co...
Best, Rio
On Thu, Feb 5, 2009 at 2:05 PM, Riobard Zhan yaogzhan@gmail.com wrote:
I'm proposing to make colons optional. Let me call this feature Colonless Python. To show what it is like without colons, here are some examples adapted from the official tutorial.
http://www.google.com.au/search?hl=en&q=python+make+colon+optional&m...
Tim Delaney
Hi Tim,
Thanks for pointing out the links. Actually I read the original thread
on python-list titled "why not drop the colons". But as I said in the
comments of Guido's blog post, the so called usability surveys did not
pop up any real data (we do not know how the surveys were conducted,
at what context, with what results, etc) to convince the original
proposer (and me). So I think we can probably discuss it. Things
change, right? :P Hope you don't mind that I bring up such an ancient
topic ...
Best, Rio
On 5-Feb-09, at 12:00 AM, Tim Delaney wrote:
> >
On Thu, Feb 5, 2009 at 2:05 PM, Riobard Zhan yaogzhan@gmail.com
wrote:
I'm proposing to make colons optional. Let me call this feature
Colonless Python. To show what it is like without colons, here are
some examples adapted from the official tutorial.
http://www.google.com.au/search?hl=en&q=python+make+colon+optional&m...
Tim Delaney
Riobard Zhan yaogzhan@gmail.com writes:
I've also noticed this, but I also notice that it doesn't take long at all (on the order of hours) for the new user to get used to the requirement.
Because indentation also occurs for other reasons, a major example being continuations of previous lines.
for line in foo:
do_something(
spam, line)
That's three lines at differing indentation levels, but two statements.
I find that the line-end colon is a strong visual indicator that a suite is being introduced, as contrasted with some other difference in indentation.
Not since a few days learning the language, no.
The examples you've chosen, no; but I think that a lot of code which uses multi-line statements with implicit continuation would be made less readable without colons to indicate the introduction of suites.
-- \ “I hate it when my foot falls asleep during the day, because | `\ that means it's gonna be up all night.” —Steven Wright | _o__) | Ben Finney
On 5-Feb-09, at 12:37 AM, Ben Finney wrote: >
Because indentation also occurs for other reasons, a major example being continuations of previous lines.
for line in foo: do_something( spam, line)
That's three lines at differing indentation levels, but two statements.
I find that the line-end colon is a strong visual indicator that a suite is being introduced, as contrasted with some other difference in indentation.
Actually this is the first concrete example for colons. Thanks very
much for bringing it up, Ben! :)
Here is a counter-example for the strong visual indicator cause.
for some_list in some_collection:
do_something(some_list[1:
], something_else)
On Thu, Feb 5, 2009 at 8:05 AM, Riobard Zhan yaogzhan@gmail.com wrote: >
On 5-Feb-09, at 12:37 AM, Ben Finney wrote: >
Because indentation also occurs for other reasons, a major example being continuations of previous lines.
for line in foo: do_something( spam, line)
That's three lines at differing indentation levels, but two statements.
I find that the line-end colon is a strong visual indicator that a suite is being introduced, as contrasted with some other difference in indentation.
Actually this is the first concrete example for colons. Thanks very much for bringing it up, Ben! :)
Here is a counter-example for the strong visual indicator cause.
for some_list in some_collection: do_something(some_list[1: ], something_else)
True; however, the parentheses and brackets are unbalanced and that
immediately stands out, at least for me, so I see something odd is
going on right away.
You do have to admit that example is a bit contrived though. Move the
],
back onto the previous line and the code becomes perfectly clear.
I would also defend colons on the grounds that they let particularly short statements be one-liners:
def add(x,y): return x+y
# this one especially comes up a lot in practice
if x is None: x=42
for i in alist: print(i)
with the added bonus that you're forced to indent if the body becomes multiline (unless you use semicolons that is, in which case you're destined to burn in the Nth circle of Hell for your sin against the BDFL (blessed be his holiness) ;-P).
-1; colons enhance readability and are almost never forgotten after you get over the initial hurdle of learning a new language.
Cheers, Chris
-- Follow the path of the Iguana... http://rebertia.com
On 5-Feb-09, at 3:37 PM, Chris Rebert wrote:
On Thu, Feb 5, 2009 at 8:05 AM, Riobard Zhan yaogzhan@gmail.com
wrote:
>
On 5-Feb-09, at 12:37 AM, Ben Finney wrote: >
Because indentation also occurs for other reasons, a major example being continuations of previous lines.
for line in foo: do_something( spam, line)
That's three lines at differing indentation levels, but two statements.
I find that the line-end colon is a strong visual indicator that a
suite is being introduced, as contrasted with some other
difference in
indentation.
Actually this is the first concrete example for colons. Thanks very
much for
bringing it up, Ben! :)
Here is a counter-example for the strong visual indicator cause.
for some_list in some_collection: do_something(some_list[1: ], something_else)
True; however, the parentheses and brackets are unbalanced and that
immediately stands out, at least for me, so I see something odd is
going on right away.
You do have to admit that example is a bit contrived though. Move the
],
back onto the previous line and the code becomes perfectly clear.
Do you notice immediately that the left ( is unbalanced in your
original example? :P I see it odd right away, too.
Line continuations are not good examples to demonstrate the necessity
of colons, because soon you will run into the problem of requiring
semicolons at the end of every statement. I think Denis made it quite
clear in a previous reply.
do(some(), some_other(), some_more(complex=(True,)),
and_final_call(egg=(1,2,3,zzzzz=False))); # endof
statement is obvious (if semicolons are required)
I would also defend colons on the grounds that they let particularly short statements be one-liners:
def add(x,y): return x+y
# this one especially comes up a lot in practice
if x is None: x=42
for i in alist: print(i)
with the added bonus that you're forced to indent if the body becomes multiline (unless you use semicolons that is, in which case you're destined to burn in the Nth circle of Hell for your sin against the BDFL (blessed be his holiness) ;-P).
I think in my original proposal I stated it very clear the colons are
OPTIONAL and can be used for one-liners, just like semicolons. I did
not propose to eliminate colons all together.
On Wed, Feb 4, 2009 at 10:05 PM, Riobard Zhan yaogzhan@gmail.com wrote:
Hi everybody,
I'm proposing to make colons optional. Let me call this feature Colonless Python.
http://cobra-language.com/docs/hello-world/
George
Riobard Zhan wrote:
Pascal uses colons, but not for the exact same purpose as Python. Both languages use colons in similar ways to it's use in English. In particular, Python uses colons as a break between clauses: larger than a comma, smaller than a period.
I'm sorry you dislike colons, but I like them.
What do you think? Specifically, may I ask your feedback on the following issues?
Perhaps one time in 1000, MUCH less often than I miss a closing parenthesis, and about as often as I accidentally use round brackets instead of square (or visa versa).
I think so.
I came to Python from Pascal and Hypertalk, two very different languages. I never missed Pascal's semi-colons at the end of each line, and Hypertalk rarely use punctuation (other than for arithmetic). I didn't find it difficult to pick up on using colons.
As an exercise, I just took a look at some old Hypertalk code, and found the lack of colons equally distracting in it as I find it in your examples.
I don't think it would lead to any problems, but I think it would make Python less elegant.
-- Steven
On 5-Feb-09, at 7:31 AM, Steven D'Aprano wrote:
Riobard Zhan wrote:
Pascal uses colons, but not for the exact same purpose as Python.
Both languages use colons in similar ways to it's use in English. In
particular, Python uses colons as a break between clauses: larger
than a comma, smaller than a period.
Pascal is my first language. It has been some years ago, so I cannot
remember the detail now. I checked wikipedia and did not find colons
are used after if's. Not sure if you mean declarations? If so, I don't
think that is what we are discussing here; Java and C also use colons
in switch/case statements. AFAIK, Python is quite unique in requiring
trailing colons after if's, for's, and function/class definitions.
>
I'm sorry you dislike colons, but I like them.
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? They have the choice.
And I would also argue that many of those like colons not because they
really feel colons improve readability, but that they have get used to
colons in the first place. You like colons, I don't. How do you know
another Python user will like them or not? 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.
>
I don't think it would lead to any problems, but I think it would
make Python less elegant.
I think omitting colons makes Python more elegant--more uniform, less
clutter. It's an itch every time I see a piece of Ruby code with lots
of def's and if's without trailing colons ...
On Feb 5, 2009, at 4:12 PM, Riobard Zhan wrote:
I think omitting colons makes Python more
elegant--more uniform,
less clutter. It's an itch every time I see a piece of Ruby code
with lots of def's and if's without trailing colons ...
Could you explain to us how ruby does it?
ps: Just remember that they do have an end in the end of suites (which
in my opinion look worse than the colons...)
-- Leonardo Santagada santagada at gmail.com
On 5-Feb-09, at 3:37 PM, Leonardo Santagada wrote:
>
On Feb 5, 2009, at 4:12 PM, Riobard Zhan wrote:
I think omitting colons makes Python more
elegant--more uniform,
less clutter. It's an itch every time I see a piece of Ruby code
with lots of def's and if's without trailing colons ...
Could you explain to us how ruby does it?
ps: Just remember that they do have an end in the end of suites
(which in my opinion look worse than the colons...)
I don't like the end-end-end-end part of Ruby either. But they do have
better starting part IMO.
def foo(var) if var == 10 print "Variable is 10″ else print "Variable is something else" end end
(Note this is actually an optional "then" keyword at the end of "if")
Riobard Zhan wrote:
I don't like the end-end-end-end part of Ruby either.
But they do have
better starting part IMO.
The really annoying thing about ends in Ruby is that if you leave one out, you don't get an error until the very end of the file, giving you no clue where the missing 'end' is...
That sort of thing never seems to happen in Python, thankfully.
I don't think this issue has anything to do with semicolons, though.
-- Greg
Riobard Zhan wrote:
Pascal uses colons, but not for the exact same purpose as Python. Both languages use colons in similar ways to it's use in English. In particular, Python uses colons as a break between clauses: larger than a comma, smaller than a period.
Pascal is my first language. It has been some years ago, so I cannot remember the detail now. I checked wikipedia and did not find colons are used after if's. Not sure if you mean declarations?
I didn't say that Pascal uses colons after IFs. I explicitly said Pascal used colons "not for the exact same purpose as Python".
If so, I don't think that is what we are discussing here; Java and C also use colons in switch/case statements. AFAIK, Python is quite unique in requiring trailing colons after if's, for's, and function/class definitions.
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.
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'm sorry you dislike colons, but I like them.
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.
And I would also argue that many of those like colons not because they really feel colons improve readability, but that they have get used to colons in the first place. You like colons, I don't. How do you know another Python user will like them or not?
I don't really care. I'm sure that there are millions of programmers who don't like brackets around function calls, but we don't make them optional:
myfunction x, y, z
For that matter, commas in lists and tuples:
my function x y z
Flexibility of punctuation in human languages is a good thing, because it enables the writer to express subtle differences in semantics. There is a subtle difference between
Guido is an excellent language designer: he knows what he is doing.
and
Guido is an excellent language designer, he knows what he is doing.
But compared to human languages, the semantics expressed by computer languages are simple and unsubtle. Flexibility of punctuation hurts computer languages, not helps.
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? 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.
-- Steven
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.
Riobard Zhan yaogzhan@gmail.com writes:
On 5-Feb-09, at 7:31 AM, Steven D'Aprano wrote:
I'm sorry you dislike colons, but I like them.
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.
That argument doesn't address the point of the existing syntax. I (and presumably Steven) like the colons in code when I have to read it.
If they are optional, and some significant proportion of coders stop using them to introduce a suite, then they entirely lose their strong association with “here comes a suite” that is the main benefit of having them as complulsory syntax.
We don't like semicolons in Python, but what would stop a hard-core C users to end every statement with a semicolon? They have the choice.
Laziness (the good kind). Once someone discovers that they don't have to add the semicolons, and it doesn't affect the operation of their program, those semicolons will, I predict, become much less frequent.
-- \ “Pinky, are you pondering what I'm pondering?” “I think so, | `\ Brain, but Tuesday Weld isn't a complete sentence.” —_Pinky and | _o__) The Brain_ | Ben Finney
On 5-Feb-09, at 6:10 PM, Ben Finney wrote:
Riobard Zhan yaogzhan@gmail.com writes:
On 5-Feb-09, at 7:31 AM, Steven D'Aprano wrote:
I'm sorry you dislike colons, but I like them.
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.
That argument doesn't address the point of the existing syntax. I (and presumably Steven) like the colons in code when I have to read it.
If they are optional, and some significant proportion of coders stop using them to introduce a suite, then they entirely lose their strong association with “here comes a suite” that is the main benefit of having them as complulsory syntax.
Your strong association with "here comes a suite" should come from
indentation, that's how Python works. Or you should fallback to
opening and ending braces like Java/C (or even old school begin-end
keywords) if you fail to do so.
We don't like semicolons in Python, but what would stop a hard-core C users to end every statement with a semicolon? They have the choice.
Laziness (the good kind). Once someone discovers that they don't have to add the semicolons, and it doesn't affect the operation of their program, those semicolons will, I predict, become much less frequent.
"Once someone discovers that they don't have to add the colons, and
it doesn't affect the operation of their program, those colons will, I
predict, become much less frequent. "
Thank God, finally we are on the right track. Making colons optional
is just the first step to kill both semicolons and colons all together.
Riobard Zhan yaogzhan@gmail.com writes:
On 5-Feb-09, at 6:10 PM, Ben Finney wrote:
If they are optional, and some significant proportion of coders stop using them to introduce a suite, then they entirely lose their strong association with “here comes a suite” that is the main benefit of having them as complulsory syntax.
Your strong association with "here comes a suite" should come from indentation, that's how Python works.
We're going around in circles: I've already demonstrated that there is plenty of indentation changes in Python code that isn't associated with here-comes-a-suite.
Or you should fallback to opening and ending braces like Java/C (or even old school begin-end keywords) if you fail to do so.
Why? I already have indentation plus here-comes-a-suite colons in Python.
-- \ “It's up to the masses to distribute [music] however they want | `\ … The laws don't matter at that point. People sharing music in | _o__) their bedrooms is the new radio.” —Neil Young, 2008-05-06 | Ben Finney
On 6-Feb-09, at 3:47 AM, Ben Finney wrote:
Riobard Zhan yaogzhan@gmail.com writes:
On 5-Feb-09, at 6:10 PM, Ben Finney wrote:
If they are optional, and some significant proportion of coders stop using them to introduce a suite, then they entirely lose their strong association with “here comes a suite” that is the main benefit of having them as complulsory syntax.
Your strong association with "here comes a suite" should come from indentation, that's how Python works.
We're going around in circles: I've already demonstrated that there is plenty of indentation changes in Python code that isn't associated with here-comes-a-suite.
Or you should fallback to opening and ending braces like Java/C (or even old school begin-end keywords) if you fail to do so.
Why? I already have indentation plus here-comes-a-suite colons in Python.
Why do you want a strong association with "here comes a suite" coming
from colons? Why don't you want a strong association with "here comes
a statement" coming from semicolons? Can you explain the inconsistency?
Riobard Zhan yaogzhan@gmail.com writes:
Why do you want a strong association with "here comes a suite" coming from colons?
I want that indication from something, because indentation isn't sufficient. A colon ‘:’ is a good choice because its semantic meaning has a good analogue to the same character in natural language.
Why don't you want a strong association with "here comes a statement" coming from semicolons?
Because “start of a new line at the same indentation level” is sufficient for that. (Not to mention that the very idea of “here comes a statement” is rather foreign; I have so little need for something extra to do that job that I barely recognise it as a job that needs doing.)
Can you explain the inconsistency?
Entirely different requirements.
If that's not enough for you, I think the gulf of understanding is too wide for my level of interest in exploring the reasons.
-- \ “If you go flying back through time and you see somebody else | `\ flying forward into the future, it's probably best to avoid eye | _o__) contact.” —Jack Handey | Ben Finney
On 6-Feb-09, at 5:57 PM, Ben Finney wrote:
Riobard Zhan yaogzhan@gmail.com writes:
Why do you want a strong association with "here comes a suite" coming from colons?
I want that indication from something, because indentation isn't sufficient. A colon ‘:’ is a good choice because its semantic meaning has a good analogue to the same character in natural language.
Why don't you want a strong association with "here comes a statement" coming from semicolons?
Because “start of a new line at the same indentation level” is sufficient for that. (Not to mention that the very idea of “here comes a statement” is rather foreign; I have so little need for something extra to do that job that I barely recognise it as a job that needs doing.)
Sorry, I did not make it clear. Please let me put it straight: I think
it is unnecessary to have an extra indication of "here comes a suite".
The purpose is to introduce a relationship of association, and one
deeper level of indentation does the job perfectly. We even indent
line continuation to reflect such relationships as well. Thus it
should not be insufficient for indentation to give you such strong
indication.
Can you explain the inconsistency?
Entirely different requirements.
Different requirements do not imply different rules. The point of
consistency is that even if we have completely different requirements,
we can still have one rule (or similar rules), so that complexity is
minimized and simplicity is gained.
If that's not enough for you, I think the gulf of understanding is too wide for my level of interest in exploring the reasons.
You are not forced to explain everything. But I think it would be
polite to defend your argument with some detail in a debate.
Riobard Zhan wrote:
Your strong association with "here comes a suite" should come from indentation, that's how Python works.
Your argument makes no sense, since an indention does not automatically indicate a suite. We as programmers regularly indent line-continuations for the sake of code readability, and we rarely break lines after a colon. This is a certainly a style and not a law, but it's the style of Python, codified by PEP 8:
""" The preferred way of wrapping long lines is by using Python's implied line continuation inside parentheses, brackets and braces. If necessary, you can add an extra pair of parentheses around an expression, but sometimes using a backslash looks better. Make sure to indent the continued line appropriately. The preferred place to break around a binary operator is after the operator, not before it. """
Although the binary operator instruction might lead to breaking "[x:y]" into "[x:\ny]", many in the community have rejected that as good form. Perhaps it should be noted in the PEP 8 guidelines that its bad. Presuming that is accepted practice, one can easily assert that colons at the end of a line in (well-written) code precede suites. On the other hand, you have no hope of making such an assertion about indentions.
Or you should fallback to opening and ending braces like Java/C (or even old school begin-end keywords) if you fail to do so.
Huh? You want to add more line noise? The colon is a pleasant compromise between the "please give me some indicator that is visual" and the "please don't make me type extra characters" crowds. Your arguments that people who don't want to type them shouldn't don't hold up when you consider that other people have to read the code, and they are not given the option to put the colons back in upon reading it. And there is the simple fact that a piece of code will be read more often than it is ever wrote. Does your burden out weigh all of the potential readers of your code?
-- Scott Dial scott@scottdial.com scodial@cs.indiana.edu
[noise]
Sounds like there are a lot of fevered egos on both sides of the debate.
Personally, I like colons. I'm sure if python forbade them, I'd stop using it. That said, the folks on the other side seem to have a good argument in that "semicolons are optional; [sic] why aren't colons?"
I don't at all agree with the people calling them line noise or saying that they hurt readability (seriously, what?), but it seems sensible to allow the option. After all, if you have to read someone's code, there's a decent chance that you can use a style guide to force them to use colons. It's also probably not hard to hack the parser to create a tool that simply adds or removes colons to or from old code to make it conform to a new style guide, if this were necessary.
In short, the idiots that are against colons might be idiots, but at least they seem to be more fair.
-- Cheers, Leif
On Fri, Feb 6, 2009 at 2:49 AM, Steven D'Aprano steve@pearwood.info wrote:
"Fairness" is not a language design principle.
Hopefully it would be a principle on which discussion could be based. I was hoping more that the colon-supporters would come up with a good counter to that argument, because I can't.
-- Cheers, Leif
On 6-Feb-09, at 4:50 AM, Leif Walsh wrote:
On Fri, Feb 6, 2009 at 2:49 AM, Steven D'Aprano
steve@pearwood.info wrote:
"Fairness" is not a language design principle.
Hopefully it would be a principle on which discussion could be based. I was hoping more that the colon-supporters would come up with a good counter to that argument, because I can't.
What bothers me here is that colon-lovers seem to assume their choice
is the choice.
On Fri, Feb 6, 2009 at 9:51 AM, Riobard Zhan yaogzhan@gmail.com wrote:
What bothers me here is that colon-lovers seem to assume their choice is the choice.
But, currently, it is. :-P
-- Cheers, Leif
On 6-Feb-09, at 11:40 AM, Leif Walsh wrote:
On Fri, Feb 6, 2009 at 9:51 AM, Riobard Zhan yaogzhan@gmail.com
wrote:
What bothers me here is that colon-lovers seem
to assume their
choice is
the choice.
But, currently, it is. :-P
That's what to be debated. And they fail to give a rational argument
to explain why.
Riobard Zhan schrieb:
On 6-Feb-09, at 11:40 AM, Leif Walsh wrote:
On Fri, Feb 6, 2009 at 9:51 AM, Riobard Zhan yaogzhan@gmail.com
wrote:
What bothers me here is that colon-lovers seem
to assume their
choice is
the choice.
But, currently, it is. :-P
That's what to be debated. And they fail to give a rational argument
to explain why.
I don't want to discredit your efforts here, but that's simply the laziness you kind of acquire when you know that the discussion won't make any difference.
Georg
-- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
Riobard Zhan wrote:
What bothers me here is that colon-lovers seem to assume their choice is the choice.
Colons are not the only choice, but they are the choice made nearly twenty years ago. Colons are the status quo. We don't have to justify the choice, you have to justify the change.
All we have to do is nothing, and nothing will change. You have to convince others, and either change the interpreter or convince somebody else to change the interpreter, and convince the Python-dev team and Guido to accept that change. Given the opposition on this list, do you think that is likely?
-- Steven
On 6-Feb-09, at 8:11 PM, Steven D'Aprano wrote:
Colons are not the only choice, but they are the
choice made nearly
twenty years ago. Colons are the status quo. We don't have to
justify the choice, you have to justify the change.
All we have to do is nothing, and nothing will change. You have to
convince others, and either change the interpreter or convince
somebody else to change the interpreter, and convince the Python-dev
team and Guido to accept that change. Given the opposition on this
list, do you think that is likely?
"Earth-center theory is not the only choice, but they are the choice
made nearly two thousand years ago. Earth-center theory is the status
quo. We don't have to justify the choice, you have to justify the
change.
All we have to do is nothing, and nothing will change. You have to
convince others, and convince the church leaders and Pope to accept
that. Given the opposition in this country, do you think that is
likely?"
Sorry, the above is not really a proper analogy, but I failed to find
a better way to make it obvious how I felt when reading your words.
Don't take it wrong. I fully agree with your words. They are very true
and convincing. I know it is nearly impossible even before I posted
the original proposal. It is very difficult to justify a change for
such a trivial issue. People will say, "OK, I'm perfectly fine with
colons. Why bother?" And I cannot come up with anything more
compelling than it will make the language more consistent and elegant.
Nevertheless, it can be discussed; I will not be prosecuted for
bringing it up, right? :P
Riobard Zhan wrote:
I know it is nearly impossible even before I posted the original proposal. It is very difficult to justify a change for such a trivial issue. People will say, "OK, I'm perfectly fine with colons. Why bother?" And I cannot come up with anything more compelling than it will make the language more consistent and elegant.
You haven't convinced anyone that the change will make the language more consistent or elegant. Most people who have replied believe that such a change would make the language FOOLISHLY consistent and LESS elegant.
By all means try to get your idea across, that's what this list is for. But in the absence of support from anyone else, you probably should realise that this isn't going anywhere.
-- Steven
On 8-Feb-09, at 4:41 AM, Steven D'Aprano wrote:
Riobard Zhan wrote:
I know it is nearly impossible even before I
posted the original
proposal. It is very difficult to justify a change for such a
trivial issue. People will say, "OK, I'm perfectly fine with
colons. Why bother?" And I cannot come up with anything more
compelling than it will make the language more consistent and
elegant.
You haven't convinced anyone that the change will make the language
more consistent or elegant. Most people who have replied believe
that such a change would make the language FOOLISHLY consistent and
LESS elegant.
You haven't convince me the current choice makes Python SMARTLY
inconsistent and MORE elegant, either. I do agree with you that we
might probably stay the course, given the difficult nature of changing
an entrenched habit for no obvious gain. But that does not
necessarily mean the old habit is a good choice in the first place.
By all means try to get your idea across, that's what
this list is
for. But in the absence of support from anyone else, you probably
should realise that this isn't going anywhere.
You seem to assume everyone else thinks in your way, which I do not
think is the case. There are people who think we should kill colons
(see the comment area here [http://python-history.blogspot.com/2009/02/early-language-design-and-develop...
] and here [http://python-history.blogspot.com/2009/01/pythons-design-philosophy.html#co...
]). And if you are following the thread entirely, you will see there
is an id called spir/Denis who thinks the same.
The problem is virtually all those who think colons should be optional
will not even bother with such a trivial issue, let alone coming
here and discussing it. In fact I would not bother either, until I was
redirected here by Guido. The primary motive I came here was to throw
in the proposal and see if there are any good counter-arguments to the
idea. Up till now, I've yet seen one, except perhaps what Curt
mentioned as "there doesn't even have to be a rational basis for that".
Now spir/Denis gave up. I think I should follow him, too.
Riobard Zhan wrote:
The problem is virtually all those who think colons should be optional will not even bother with such a trivial issue, let alone coming here and discussing it.
That may be true, but most people who think colons should not be optional also don't bother coming here and discussing it.
In fact I would not bother either, until I was redirected here by Guido. The primary motive I came here was to throw in the proposal and see if there are any good counter-arguments to the idea. Up till now, I've yet seen one,
So you say.
except perhaps what Curt mentioned as "there doesn't even have to be a rational basis for that".
Now spir/Denis gave up. I think I should follow him, too.
Earlier you said that you didn't think it would be difficult to make the Python compiler accept optional colons. If you really believe that the majority of people would prefer your suggestion, why don't you come back when you have a patch, then see how many people are interested to try it out? Who knows, you might prove the nay-sayers wrong. (But I doubt it.)
-- Steven
On 6-Feb-09, at 4:10 AM, Leif Walsh wrote:
the folks on the other side seem to have a good argument in that "semicolons are optional; [sic] why aren't colons?"
That's exactly the point. Explain the inconsistency, please.
Hints for [sic] part: use semicolons for one-liners; ditto for colons.
That's why making them "optional". A colon and a semicolon are used in
this one-liner.
Le Fri, 06 Feb 2009 02:23:47 -0500, Scott Dial scott+python-ideas@scottdial.com a écrit :
Riobard Zhan wrote:
Your strong association with "here comes a suite" should come from indentation, that's how Python works.
Your argument makes no sense, since an indention does not automatically indicate a suite. We as programmers regularly indent line-continuations for the sake of code readability, and we rarely break lines after a colon. [...]
Your argument makes no sense, because it adresses semi-colons as well. Do you really mean semi-colons must be compulsary for the sake of readibility?
la vida e estranya
On 6-Feb-09, at 3:53 AM, Scott Dial wrote:
Riobard Zhan wrote:
Your strong association with "here comes a suite" should come from indentation, that's how Python works.
Your argument makes no sense, since an indention does not
automatically
indicate a suite.
Indentation does not automatically indicate a statement, either. Why
do you omit semicolons?
Huh? You want to add more line noise? The colon is a
pleasant
compromise
between the "please give me some indicator that is visual" and the
"please don't make me type extra characters" crowds. Your arguments
that
people who don't want to type them shouldn't don't hold up when you
consider that other people have to read the code, and they are not
given
the option to put the colons back in upon reading it. And there is the
simple fact that a piece of code will be read more often than it is
ever
wrote. Does your burden out weigh all of the potential readers of
your code?
So you do agree colons are line noise? Colons are unpleasant for me
not because I have to type them (though this certainly is a factor,
too), but I have to read them every time I read Python code and they
disrupt the mental flow.
You are assuming colons improve readability, which I disagree.
Readability comes from indentation, not from punctuation. If you logic
holds, you might have to use semicolons as well.
On Fri, Feb 6, 2009 at 6:37 AM, Riobard Zhan yaogzhan@gmail.com wrote: >
You are assuming colons improve readability, which I disagree.
"Readability" isn't an entirely objective metric. But making colons optional would mean that you're now looking at two different kinds of code -- with colons and without. And it's extremely hard for me to imagine that having two different kinds of code would not harm readability.
-- Curt Hagenlocher curt@hagenlocher.org
On 6-Feb-09, at 11:15 AM, Curt Hagenlocher wrote:
On Fri, Feb 6, 2009 at 6:37 AM, Riobard Zhan yaogzhan@gmail.com
wrote:
>
You are assuming colons improve readability, which I disagree.
"Readability" isn't an entirely objective metric. But making colons optional would mean that you're now looking at two different kinds of code -- with colons and without. And it's extremely hard for me to imagine that having two different kinds of code would not harm readability.
Not when we dump colons like semicolons. We don't see two different
kinds of code, one with semicolons and the other without.
On Fri, Feb 6, 2009 at 7:14 AM, Riobard Zhan yaogzhan@gmail.com wrote: >
But making colons optional would mean that you're now looking at two different kinds of code -- with colons and without. And it's extremely hard for me to imagine that having two different kinds of code would not harm readability.
Not when we dump colons like semicolons. We don't see two different kinds of code, one with semicolons and the other without.
If you're suggesting that -- for consistency -- it shouldn't be legal to have an empty statement after a semicolon, I might be tempted to agree. I've never seen anyone use a semicolon where it's optional.
In any event, as several people have suggested, there's basically zero likelihood of Python ever being changed to make colons optional. And there doesn't even have to be a rational basis for that. If it were 1994 and Python were still young, we could discuss the relative merits of required/optional/disallowed. But at this point, you're basically trying to convince people that their many years of experience with reading Python code should be thrown away in order to accommodate a small number of new users who sometimes forget a trivial piece of punctuation.
-- Curt Hagenlocher curt@hagenlocher.org
On 6-Feb-09, at 12:07 PM, Curt Hagenlocher wrote: >
In any event, as several people have suggested, there's basically zero likelihood of Python ever being changed to make colons optional. And there doesn't even have to be a rational basis for that.
I understand the nearly impossible likelihood; entrenched habits are
really difficult to change, especially when there seems no obvious gain.
The last sentence is very true (even in a broader sense; not limited
to language design). It sometimes made me very sad.
>
So you do agree colons are line noise? Colons are unpleasant for me
not because I have to type them (though this certainly is a factor,
too), but I have to read them every time I read Python code and
they disrupt the mental flow.
You are assuming colons improve readability, which I disagree.
Readability comes from indentation, not from punctuation. If you
logic holds, you might have to use semicolons as well.
Just because punctuation is not necessary does not mean it's not
useful. For example, you could argue that "f(1,2,3)" and "f(1 2 3)"
should be both allowed. Or you could argue that you dont even need
colons OR semicolons in one-liners: "if condition do_f() do_g()
do_h()". At some point aesthetics matters (even if it is an objective
thing).
One major difference between semicolons and colons is their frequency
of use. A colon once every 8-10 lines of code is less tedious/noisy
than a semicolon on EVERY line of code. Second, a colon always
precedes a linebreak AND an indent (a visible change), but semicolons
never precede anything but a simple linebreak. Colons and indents are
complementary. Third, colons and semicolons look similar; in some
ways, colons are more useful when semicolons are NOT used because
visual ambiguity is lower.
I almost never forget a colon in Python, because (to me) they feel and
look natural (and the parser gives a great error message when a colon
is missing!). I get missing-semicolon and missing-brace errors in C++
often enough (albeit infrequent) that I do NOT miss them in Python
(and the cryptic error messages they cause, sometimes in different
files than the one they're missing from)
Jared
Riobard Zhan writes:
It is pretty clear that colon-supporters do not pay attention to the inconsistency of semicolons being optional and colons being mandatory that I mentioned
So what? Commas are also mandatory. They look like semicolons so we should make them optional too. Am I joking? Sure but look at this syntax:
f(1 2 3 a=4 b=5 c=6)
I can figure out where each parameter ends easily enough without the commas [because my implicit multiplication proposal was rejected :-(]. Sure some people will quibble that
f(1 -2)
is a problem and so on but that can be fixed just as C distinguishes between x =- y and x = -y.* That's not the real problem. The real problem is that we want* those commas to break up the flow of text. In English, a comma is a pause in the reading. If you, stick extra, commas in, your sentences you will, confuse people. Colons, semicolons, dashes, etc. all server similar purposes to cue the reader in on what the sentences is about? Hah, tricked you there with that question mark.
Enough of this for me. Consistency for consistency's sake is overrated. Let's get on to important stuff like whether we number the bits from the right end or left end of the number and whether array indexes should start at 1 or 0.
--- Bruce
P.S. Colons are redundant by their very nature that they use two dots when one is all you need (or love is all you need (or something like that)).
** For the historically challenged, original C used =- instead of -=.
On 6-Feb-09, at 2:27 PM, Bruce Leban wrote:
So what? Commas are also mandatory. They look like
semicolons so we
should make them optional too. Am I joking?
You can not generalize that far. Most programming languages require
commas (notable exceptions include Lisp and Tcl), but Python is the
only language that requires trailing colons. There are some
differences between making commas optional and making trailing colons
optional.
On Sat, Feb 7, 2009 at 10:47 PM, Riobard Zhan yaogzhan@gmail.com wrote:
>
On 6-Feb-09, at 2:27 PM, Bruce Leban wrote:
So what? Commas are also mandatory. They look like semicolons so we should make them optional too. Am I joking?
You can not generalize that far. Most programming languages require commas (notable exceptions include Lisp and Tcl), but Python is the only language that requires trailing colons.
Nope. See http://en.wikipedia.org/wiki/Smalltalk
Sure Lisp doesn't use commas. Parenthesis can be made optional in Lisp too. Therefore semicolons, colons, commas and parenthesis are all equally optional. Woohoo! No pesky syntax!
There are some differences between making commas optional and making
trailing colons optional.
"There are some differences between making X optional and making Y optional" for all features X and Y.
Clearly the use of the specific semicolon character is confusing you. So let's replace it with a better symbol: \n as in this example:
for i in x: foo(i) \n bar(i+1)
Sure a \n is optional at the end of any line because a blank line is always allowed. So what?
--- Bruce
On 8-Feb-09, at 3:50 AM, Bruce Leban wrote:
You can not generalize that far. Most programming
languages require
commas (notable exceptions include Lisp and Tcl), but Python is the
only language that requires trailing colons.
Nope. See http://en.wikipedia.org/wiki/Smalltalk
Just checked. Smalltalk's colons seem to have completely different
semantics. Correct me if I'm wrong, but they appear to be at the end
of every keyword, including ifTrue and ifElse.
There are some differences between making commas
optional and making
trailing colons optional.
"There are some differences between making X optional and making Y
optional" for all features X and Y.
This generalization is meaningless. You deliberately ignored the
original context.
Clearly the use of the specific semicolon character
is confusing
you. So let's replace it with a better symbol: \n as in this example:
for i in x: foo(i) \n bar(i+1)
Sure a \n is optional at the end of any line because a blank line is
always allowed. So what?
What's the point you are trying to make?
On Sat, Feb 7, 2009 at 11:58 PM, Riobard Zhan yaogzhan@gmail.com wrote:
>
On 8-Feb-09, at 3:50 AM, Bruce Leban wrote:
You can not generalize that far. Most programming languages require commas
(notable exceptions include Lisp and Tcl), but Python is the only language that requires trailing colons.
Nope. See http://en.wikipedia.org/wiki/Smalltalk
Just checked. Smalltalk's colons seem to have completely different semantics. Correct me if I'm wrong, but they appear to be at the end of every keyword, including ifTrue and ifElse.
Your statement that no programming language used trailing colons is simply false. I and many others have said that colons and semicolons have completely different semantics as well and you have chosen to ignore that.
Clearly the use of the specific semicolon character is confusing you. So
let's replace it with a better symbol: \n as in this example:
for i in x: foo(i) \n bar(i+1)
Sure a \n is optional at the end of any line because a blank line is always allowed. So what?
What's the point you are trying to make?
The point is that the \n token and the : token have different semantics entirely. The \n token is used to separate statements on a single line. You seem to think that they are related because they look similar and now they don't.
One more final point: in some languages, the semicolon is a statement TERMINATOR as it is in C and in others it is a statement SEPARATOR as it is in Pascal. I think your time would be better served by working to convince the Pascal people and the C people to reconcile that inconsistency than this discussion.
--- Bruce
On 8-Feb-09, at 2:18 PM, Bruce Leban wrote:
Your statement that no programming language used
trailing colons is
simply false. I and many others have said that colons and semicolons
have completely different semantics as well and you have chosen to
ignore that.
I apologize for the imprecise statement. It would be more precise if I
say Python is one of the very, very few languages that require
trailing colons. In either case, Smalltalk's colons are completely
different animals (they signify keywords, which are used to build
control constructs via message passing) than Python, and it makes no
sense to compare the two. And Smalltalk is not as widespread as many
other "mainstream" languages; therefore it is rather an exception for
Python to require trailing colons (but not so to require commas). That
is the difference between making colons optional and making commas
optional; that is also why I think your generalization to commas will
not work.
I fully understand your view that semicolons and colons are somehow
different in semantic. It is just that you and many others have chosen
to ignore the fact that different semantics do not necessarily imply
different rules, otherwise we will have too many rules to worry about.
In this case, I do not think the difference between their semantics is
huge enough to treat them differently.
Clearly the use of the specific semicolon character
is confusing
you. So let's replace it with a better symbol: \n as in this example:
for i in x: foo(i) \n bar(i+1)
Sure a \n is optional at the end of any line because a blank line is
always allowed. So what?
What's the point you are trying to make?
The point is that the \n token and the : token have different
semantics entirely. The \n token is used to separate statements on a
single line. You seem to think that they are related because they
look similar and now they don't.
One more final point: in some languages, the semicolon is a
statement TERMINATOR as it is in C and in others it is a statement
SEPARATOR as it is in Pascal. I think your time would be better
served by working to convince the Pascal people and the C people to
reconcile that inconsistency than this discussion.
I think you misunderstood my point of relating semicolons and colons.
My point is that colons are not so much different than semicolons as
visual indicators that they deserve a different rule than semicolons
(with one being mandatory while the other optional), because we
already have indentation as a very effective visual indicator to tell
us everything we need to be told.
Riobard Zhan writes:
"Once someone discovers that they don't have
to add the colons, and
it doesn't affect the operation of their program, those colons will, I
predict, become much less frequent. "
Thank God, finally we are on the right track. Making colons optional
is just the first step to kill both semicolons and colons all together.
I think the language you are looking for is called "Haskell".
On 6-Feb-09, at 4:32 AM, Stephen J. Turnbull wrote:
Riobard Zhan writes:
"Once someone discovers that they don't have
to add the colons, and
it doesn't affect the operation of their program, those colons
will, I
predict, become much less frequent. "
Thank God, finally we are on the right track. Making colons optional
is just the first step to kill both semicolons and colons all
together.
I think the language you are looking for is called "Haskell".
I think the mailing list I am posting to is called "Python Ideas".
On Fri, Feb 06, 2009 at 10:47:48AM -0330, Riobard Zhan wrote:
On 6-Feb-09, at 4:32 AM, Stephen J. Turnbull wrote:
Riobard Zhan writes:
"Once someone discovers that they don't have to add the colons, and it doesn't affect the operation of their program, those colons will, I predict, become much less frequent. "
Thank God, finally we are on the right track. Making colons optional
is just the first step to kill both semicolons and colons all
together.
I think the language you are looking for is called "Haskell".
I think the mailing list I am posting to is called "Python Ideas".
I think the idea of making colons optional is dead on arrival.
Oleg Broytmann http://phd.pp.ru/ phd@phd.pp.ru
Programmers don't die, they just GOSUB without RETURN.
On 6-Feb-09, at 10:51 AM, Oleg Broytmann wrote:
On Fri, Feb 06, 2009 at 10:47:48AM -0330, Riobard Zhan wrote:
On 6-Feb-09, at 4:32 AM, Stephen J. Turnbull wrote:
Riobard Zhan writes:
"Once someone discovers that they don't have
to add the colons,
and
it doesn't affect the operation of their program, those colons
will,
I
predict, become much less frequent. "
Thank God, finally we are on the right track. Making colons
optional
is just the first step to kill both semicolons and colons all
together.
I think the language you are looking for is called "Haskell".
I think the mailing list I am posting to is called "Python Ideas".
I think the idea of making colons optional is dead on arrival.
What do you think the idea of making semicolons optional?
On Fri, Feb 06, 2009 at 11:23:32AM -0330, Riobard Zhan wrote:
What do you think the idea of making semicolons optional?
You are trying to change the language - and changing the language is a major, big scale change - but you are trying to change the language for nothing. Small inconsistency (even if I'd agree there is an inconsistency there) doesn't by itself warrant such a major change. -1000 for the change.
http://python.org/dev/peps/pep-0008/ : "A Foolish Consistency is the Hobgoblin of Little Minds"
Oleg Broytmann http://phd.pp.ru/ phd@phd.pp.ru
Programmers don't die, they just GOSUB without RETURN.
On 6-Feb-09, at 11:39 AM, Oleg Broytmann wrote:
On Fri, Feb 06, 2009 at 11:23:32AM -0330, Riobard Zhan wrote:
What do you think the idea of making semicolons optional?
You are trying to change the language - and changing the language is
a major, big scale change - but you are trying to change the
language for
nothing. Small inconsistency (even if I'd agree there is an
inconsistency
there) doesn't by itself warrant such a major change. -1000 for the
change.
Making colons is not a major, big scale change. You can use them if
you want. There is even no backward compatibility issues. I guess
hardly anybody would notice if we do make the change.
By comparison, what do we get by making "print" a function? Why not
create a "put" or "echo" built-in function if we really want the
flexibility? Isn't that a major, big scale change?
On Fri, Feb 06, 2009 at 11:55:12AM -0330, Riobard Zhan wrote:
On 6-Feb-09, at 11:39 AM, Oleg Broytmann wrote:
On Fri, Feb 06, 2009 at 11:23:32AM -0330, Riobard Zhan wrote:
What do you think the idea of making semicolons optional?
You are trying to change the language - and changing the language is
a major, big scale change - but you are trying to change the language
for
nothing. Small inconsistency (even if I'd agree there is an
inconsistency
there) doesn't by itself warrant such a major change. -1000 for the
change.
Making colons is not a major, big scale change.
It is, because it is now a part of the language. Changing the language is always a major change. If you don't understand - well, we failed to communicate, and I am stopping now. You have to learn to live with small inconsistencies.
By comparison, what do we get by making "print" a
function? Why not
create a "put" or "echo" built-in function if we really want the
flexibility? Isn't that a major, big scale change?
Yes, it was a major change, and it warranted a new major release - 3.0.
Oleg Broytmann http://phd.pp.ru/ phd@phd.pp.ru
Programmers don't die, they just GOSUB without RETURN.
On 6-Feb-09, at 12:01 PM, Oleg Broytmann wrote:
It is, because it is now a part of the
language. Changing the
language
is always a major change. If you don't understand - well, we failed to
communicate, and I am stopping now.
It's OK. We just have different understanding of how "big" is "big".
You have to learn to live with small inconsistencies.
I'm perfectly fine with them. Have lived with them for a couple of
years.
By comparison, what do we get by making "print" a function? Why not create a "put" or "echo" built-in function if we really want the flexibility? Isn't that a major, big scale change?
Yes, it was a major change, and it warranted a new major release -
3.0.
The original context is that you thought it's not worth a "big/major"
change to make colons optional because we get nothing, then I asked by
comparison what do we get by making "print" a function (a "bigger"
change for me) when we really have the option to just add a new built-
in function with a slightly different name.
On Sun, 08 Feb 2009 03:17:33 -0330, Riobard Zhan wrote:
The original context is that you thought it's not worth a "big/major" change to make colons optional because we get nothing, then I asked by comparison what do we get by making "print" a function (a "bigger" change for me) when we really have the option to just add a new built- in function with a slightly different name.
No, it is not an option because 1) it is duplication of feature 2) having two different print construct that have subtle differences confuses the hell out of newbies 3) people won't use that new built-in function 4) if people don't use the new built-in function, overriding print would involve some dark magic 5) to override print statement you need to mess with sys.stdout, which is messy as you need to keep a reference to the original sys.stdout or face infinite recursion.
The case for colon is different from the case of semicolon. Statements between semicolons have sibling relationship, while the statement before a colon and the statements after the colon have parent-child relationship.
Sibling relationship is not significant enough to require anything more than a newline or -- in the case of several statements in one line -- a semicolon. Parent-Child relationship is much more important and having colon before the child statements makes it visually easy to distinguish the parent and children.
The case for you requesting optional colon is like asking for code like this to be legal:
def foo(bar): print 'foo' print 'bar' spit() antigravity(bar) print 'koo'
which would be interpreted as
def foo(bar): print 'foo' print 'bar' spit() antigravity(bar) print 'koo'
and saying: "consistent indentation is unnecessary as computer can syntactically distinguish them as long as the number spaces is equal or more than the first indentation of the suite"
yeah, although computers can distinguish them easily, human can't.
On Fri, Feb 06, 2009, Riobard Zhan wrote: >
I think the mailing list I am posting to is called "Python Ideas".
That doesn't mean that people will have any interest in your ideas. You should pay attention to what people are telling you and spend less time arguing with them. Keep in mind that Guido is still BDFL, and you have
Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/
Weinberg's Second Law: If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization.
On 6-Feb-09, at 11:08 AM, Aahz wrote:
On Fri, Feb 06, 2009, Riobard Zhan wrote: >
I think the mailing list I am posting to is called "Python Ideas".
That doesn't mean that people will have any interest in your ideas.
You
should pay attention to what people are telling you and spend less
time
arguing with them.
It is pretty clear that colon-supporters do not pay attention to the
inconsistency of semicolons being optional and colons being mandatory
that I mentioned, and try to argue with me using a set of reasons why
they love colons when in fact the same reasons would obviously make
them love semicolons, and ignore the fact that they are used to colons
not because it is a better idea but they are never allowed to omit.
Keep in mind that Guido is still BDFL, and you have effectively zero chance of convincing him to drop the colons.
It does not stop me giving it a try.
Riobard Zhan writes:
It is pretty clear that colon-supporters do not pay
attention to the
inconsistency of semicolons being optional and colons being mandatory
that I mentioned,
The inconsistency is quite small. In fact, in English colons and semicolons have both different syntax and different semantics, and the same is true of Python. In English, the semicolon expresses a conjunction of two not necessarily related sentences. Python is the same, except that since we all run von Neumann machines, conjunction implies sequencing. The colon, on the other hand, represents a relationship of some kind. A native-speaker simply doesn't write things like "The sky is blue: mesons are composed of two quarks." (Well, the coiner of the work "quark" might, which is the exception that proves the rule.) And the same is true in Python; the code fragment preceding the colon controls the statement (suite) following it. Thus, the apparent isomorphism of the semantics is quite superficial, almost syntactic itself.
Syntactically, in English a semicolon takes two sentences to conjoin. A colon, on the other hand, must have a full sentence on one side or the other, but the other side may be almost anything.[1] Similarly in Python: both what precedes the semicolon and what follows it must be complete statements, while what precedes the colon must be a fragment, and what follows it is a complete statement (suite). So the colon and semicolon do not have isomorphic syntax, either.
In fact, the semicolon is indeed redundant, as it is precisely equivalent to a newline + the current level of indentation. This kind of redundancy is quite unusual in Python, so I wonder if the BDFL might regret having permitted semicolons at all, as he has expressed regret for allowing the extended assignment operators (eg, +=).
and try to argue with me using a set of reasons
why
they love colons when in fact the same reasons would obviously make
them love semicolons, and ignore the fact that they are used to colons
not because it is a better idea but they are never allowed to omit.
I think that
if condition:
act (appropriately)
is more readable than
if (condition)
act (appropriately);
or
if condition
act (appropriately)
In C, the visual parallelism of the control structure and the function call is spurious, and the trailing semicolon actually terminates the f statement, which is not the way I really think about it.
In colon-less Python, the control fragment is insufficiently divided from the controlled suite. Just as in English, a bit of redundancy to reflect the hierarchical relationship between the control structure and the controlled suite is useful.
In Python, the same character is used, which is helpful to those whose native languages use colons. This is indeed good design. It expresses, and emphasizes, the hierarchical structure of the control construct, and does so using a syntax that any English-speaker (at least) will recognize as analogous.
I don't expect to convince you that the required colon is good design, but I think it puts paid to the notion that colons and semicolons are isomorphic. It is not true that what we conclude about semicolons is necessarily what we should conclude about colons.
Footnotes: [1] That's not entirely true. It is possible to write something like
Required colon: an idea which is still correct.
which does not contain any complete sentence, and where the colon is actually a copula. But even then, it's a relationship.
On 6-Feb-09, at 12:51 PM, Stephen J. Turnbull wrote:
The inconsistency is quite small. In fact, in English colons and semicolons have both different syntax and different semantics, and the same is true of Python. In English, the semicolon expresses a conjunction of two not necessarily related sentences. Python is the same, except that since we all run von Neumann machines, conjunction implies sequencing. The colon, on the other hand, represents a relationship of some kind. A native-speaker simply doesn't write things like "The sky is blue: mesons are composed of two quarks." (Well, the coiner of the work "quark" might, which is the exception that proves the rule.) And the same is true in Python; the code fragment preceding the colon controls the statement (suite) following it. Thus, the apparent isomorphism of the semantics is quite superficial, almost syntactic itself.
Syntactically, in English a semicolon takes two sentences to conjoin. A colon, on the other hand, must have a full sentence on one side or the other, but the other side may be almost anything.[1] Similarly in Python: both what precedes the semicolon and what follows it must be complete statements, while what precedes the colon must be a fragment, and what follows it is a complete statement (suite). So the colon and semicolon do not have isomorphic syntax, either.
>
In fact, the semicolon is indeed redundant, as it is precisely equivalent to a newline + the current level of indentation. This kind of redundancy is quite unusual in Python, so I wonder if the BDFL might regret having permitted semicolons at all, as he has expressed regret for allowing the extended assignment operators (eg, +=).
I have no problem with the different semantics of colons and
semicolons. What I do have problem is that colons are mandatory but
semicolons are optional, while both are completely redundant. Colons
are redundant too because they are precisely equivalent to a newline +
a deeper level of indentation.
In colon-less Python, the control fragment is insufficiently divided from the controlled suite. Just as in English, a bit of redundancy to reflect the hierarchical relationship between the control structure and the controlled suite is useful.
I think indentation is sufficient to divide them. A block indented one
level deeper is always associated with the previous one level
shallower code. We even indent line continuation to reflect such
relationships.
In Python, the same character is used, which is helpful to those whose native languages use colons. This is indeed good design. It expresses, and emphasizes, the hierarchical structure of the control construct, and does so using a syntax that any English-speaker (at least) will recognize as analogous.
The hierarchical structure is expressed by indentation. Colons simply
(over)emphasize it. That's why I think they are redundant. Choosing
the colon character is fine. Making it mandatory is bad.
I don't expect to convince you that the required colon is good design, but I think it puts paid to the notion that colons and semicolons are isomorphic. It is not true that what we conclude about semicolons is necessarily what we should conclude about colons.
Forgive me if I do not fully understand your point, but it appears to
me that you conclude semicolons are optional because they are
redundant. I think the conclusion is precisely the same for colons.
Riobard Zhan wrote:
Colons are redundant too because they are precisely equivalent to a newline + a deeper level of indentation.
You have been given many examples showing that this is not true. At best, it is often true, but certainly not always.
At this point, the horse is not just dead, it has rotted away to a skeleton. I don't believe there is any point continuing to beat it. If anyone other than Riobard thinks differently, please speak up.
-- Steven
Riobard Zhan writes:
Forgive me if I do not fully understand your point,
You don't.
but it appears to me that you conclude semicolons are optional because they are redundant.
It appears to me that you're responding to something other than what I wrote. I wrote nothing about why semicolons are optional, only about why I believe they are redundant.
I think the conclusion is precisely the same for colons.
My point was precisely that two syntaxes are appropriate balance with two semantics, but we have three syntax elements, so one is redundant. If you claim that is an argument for symmetry in treatment of colons and semicolons, I guess you are of the school that 3 - 1 = 1 for sufficiently large values of 1? But no, my point is that we can get rid of one but not both, assuming that syntax should reflect semantics to this extent. And it's pretty obvious which one to get rid of!
You pretty clearly disagree with that principle, but I think it's an important aspect of what makes Python attractive to me: syntactic units and dividers do correspond to semantic units, according to my intuition.
On 8-Feb-09, at 4:51 AM, Stephen J. Turnbull wrote: >
It appears to me that you're responding to something other than what I wrote. I wrote nothing about why semicolons are optional, only about why I believe they are redundant.
I apologize if you do not intend to do so, but the form of your
argument really tricked me to think so. See here
"In fact, the semicolon is indeed redundant, as it is precisely equivalent to a newline + the current level of indentation. This kind of redundancy is quite unusual in Python, so I wonder if the BDFL might regret having permitted semicolons at all"
I take it as if the semicolons should be eliminated, but due to a
mistake they became optional, because they are redundant.
I think the conclusion is precisely the same for colons.
My point was precisely that two syntaxes are appropriate balance with two semantics, but we have three syntax elements, so one is redundant. If you claim that is an argument for symmetry in treatment of colons and semicolons, I guess you are of the school that 3 - 1 = 1 for sufficiently large values of 1? But no, my point is that we can get rid of one but not both, assuming that syntax should reflect semantics to this extent. And it's pretty obvious which one to get rid of!
I do not disagree the principle in general. But in this case I think
it is not necessary to have extra syntax of colons when indentation
works very well. So two are redundant, both semicolons and colons.
Even Guido admits requiring colons is redundancy (see here [http://python-history.blogspot.com/2009/02/early-language-design-and-develop...
]); he just thinks this redundancy is good.
On Feb 6, 2009, at 1:11 PM, Riobard Zhan wrote:
>
On 6-Feb-09, at 11:08 AM, Aahz wrote:
On Fri, Feb 06, 2009, Riobard Zhan wrote: >
I think the mailing list I am posting to is called "Python Ideas".
That doesn't mean that people will have any interest in your
ideas. You
should pay attention to what people are telling you and spend less
time
arguing with them.
It is pretty clear that colon-supporters do not pay attention to the
inconsistency of semicolons being optional and colons being
mandatory that I mentioned, and try to argue with me using a set of
reasons why they love colons when in fact the same reasons would
obviously make them love semicolons, and ignore the fact that they
are used to colons not because it is a better idea but they are
never allowed to omit.
Keep in mind that Guido is still BDFL, and you have effectively zero chance of convincing him to drop the colons.
It does not stop me giving it a try.
I Will give you an idea, change the rules of the parser so your idea
works (making colon optional) and maybe even making comas optional and
then show us how it works and then maybe convert the whole stdlib to
be colon free (and maybe comma free)... this is probably going to
convince more people that you are right... or it will convince you
that you are wrong :). I think it will be quite simple to do (as you
say it they are there just because so it should be a simple grammar
change).
Good luck,
Leonardo Santagada santagada at gmail.com
On 6-Feb-09, at 7:50 PM, Leonardo Santagada wrote: >
I Will give you an idea, change the rules of the
parser so your idea
works (making colon optional) and maybe even making comas optional
and then show us how it works and then maybe convert the whole
stdlib to be colon free (and maybe comma free)... this is probably
going to convince more people that you are right... or it will
convince you that you are wrong :). I think it will be quite simple
to do (as you say it they are there just because so it should be a
simple grammar change).
Good luck, and I will probably play with your demo python
Thank you very much for the suggestion! I don't think making colons
optional is a technical problem at all. Eventually I'll have to
convince people on this list that it would be a (slightly) better idea
(best would be to kill colons, semicolons, and as a consequence, one-
liners, completely); or they convince me the opposite. I'm doing the
harder part first.
Riobard Zhan wrote:
It is pretty clear that colon-supporters do not pay attention to the inconsistency of semicolons being optional and colons being mandatory
No, it is pretty clear that you do not understand the fundamental difference in semantics between colons and semi-colons. It is not an inconsistency.
Colons are used as an indicator of association: the block following the colon is strongly associated with the line containing the colon, just like in English. This reinforces the association due to indentation, and makes it more obvious in complicated cases:
if (some very complicated statement) or (another big statement which goes over many lines) or clause: do something here else: do something else
Semi-colons are used as a separator, and they are designed for one-liners. They are permitted in multi-line programs only because there is no need to bother forbidding them, but they are completely redundant if followed by a line break instead of another statement.
x = 1; y = 2 # the semi-colon is useful
x = 1; y = 2 # the semi-colon is useless line noise
Because colons are used for a very different thing than semi-colons, any inconsistency between the rules for one and the rules for the other is imaginary. Different purposes, different rules.
-- Steven
On 6-Feb-09, at 9:00 PM, Steven D'Aprano wrote:
No, it is pretty clear that you do not understand the
fundamental
difference in semantics between colons and semi-colons. It is not an
inconsistency.
I'm not arguing it is inconsistent because they have similar
semantics. I'm arguing it is inconsistent because both are redundant
but one is optional while the other mandatory.
You do agree indentation signifies association, and colons reinforce
the association. To me, it means indentation is good enough, and
colons are redundant if followed by a line break and indentation
instead of a statement.
Because colons are used for a very different thing
than semi-colons,
any inconsistency between the rules for one and the rules for the
other is imaginary. Different purposes, different rules.
It is real. That you have different rules for semicolons and colons is
the inconsistency. There should be just one rule instead of two.
Different purposes do not automatically imply different rules,
otherwise we will have too many rules to hold in memory.
Le Fri, 6 Feb 2009 03:12:36 -0330, Riobard Zhan yaogzhan@gmail.com a écrit :
Laziness (the good kind). Once someone discovers that they don't have to add the semicolons, and it doesn't affect the operation of their program, those semicolons will, I predict, become much less frequent.
"Once someone discovers that they don't have to add the colons, and
it doesn't affect the operation of their program, those colons will, I
predict, become much less frequent. "
Thank God, finally we are on the right track. Making colons optional
is just the first step to kill both semicolons and colons all together.
Probably...
la vida e estranya
Le Fri, 06 Feb 2009 08:40:27 +1100, Ben Finney ben+python@benfinney.id.au a écrit :
We don't like semicolons in Python, but what would stop a hard-core C users to end every statement with a semicolon? They have the choice.
Laziness (the good kind). Once someone discovers that they don't have to add the semicolons, and it doesn't affect the operation of their program, those semicolons will, I predict, become much less frequent.
Ditto for colons!
<div class = "meta_note"> Strange that you do not realize that all arguments pro / against semi-colons apply to colons as well: they have same syntactic position and the same semantics. So that clear, consistent, choices are: * both to trash * both compulsery * both optional My opinion: the rest is blahblah confusing habits and good design. Saying "I prefere this because I'm used to it." is fully respectable. This does not mean that other options are weaker design choices. </div>Denis
la vida e estranya
On 6-Feb-09, at 5:41 AM, spir wrote:
Le Fri, 06 Feb 2009 08:40:27 +1100, Ben Finney ben+python@benfinney.id.au a écrit :
We don't like semicolons in Python, but what would stop a hard-core C users to end every statement with a semicolon? They have the choice.
Laziness (the good kind). Once someone discovers that they don't
have
to add the semicolons, and it doesn't affect the operation of their
program, those semicolons will, I predict, become much less frequent.
Ditto for colons!
<div class = "meta_note"> Strange that you do not realize that all arguments pro / against semi-colons apply to colons as well: they have same syntactic position and the same semantics. So that clear, consistent, choices are: * both to trash * both compulsery * both optional My opinion: the rest is blahblah confusing habits and good design. Saying "I prefere this because I'm used to it." is fully respectable. This does not mean that other options are weaker design choices. </div>Exactly! Making colons optional just like colons makes Python
more
consistent. It is a better design, even though we might have to fight
old habits at the beginning.
Riobard Zhan schrieb:
On 5-Feb-09, at 7:31 AM, Steven D'Aprano wrote:
Riobard Zhan wrote:
Pascal uses colons, but not for the exact same purpose as Python.
Both languages use colons in similar ways to it's use in English. In
particular, Python uses colons as a break between clauses: larger
than a comma, smaller than a period.
Pascal is my first language. It has been some years ago, so I cannot
remember the detail now. I checked wikipedia and did not find colons
are used after if's. Not sure if you mean declarations? If so, I don't
think that is what we are discussing here; Java and C also use colons
in switch/case statements. AFAIK, Python is quite unique in requiring
trailing colons after if's, for's, and function/class definitions.
Python is also quite unique in using indentation to delimit blocks, so I'm not sure what point you're trying to make.
>
I'm sorry you dislike colons, but I like them.
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? They have the choice.
And I would also argue that many of those like colons not because they
really feel colons improve readability, but that they have get used to
colons in the first place. You like colons, I don't. How do you know
another Python user will like them or not? 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.
By making colon syntax flexible, we also lose a consistent look and feel of the language. [1]
I think it's a good indicator for optional syntax if you can formulate new rules for PEP 8 that state when to use it. In the case of colons, you'd have to either forbid or mandate them; I'd be at a loss to find another consistent rule. So, making them optional is pointless; we should either keep them or remove them. And removing is out of the question.
Applying that indicator to semicolons, there is a clear rule in PEP 8 that states when to use them: to separate two statements on one line.
I don't think it would lead to any problems, but I think it would
make Python less elegant.
I think omitting colons makes Python more elegant--more uniform, less
clutter. It's an itch every time I see a piece of Ruby code with lots
of def's and if's without trailing colons ...
That's your prerogative. However, the only person around here whose itches alone, in the face of a wall of disagreeing users, can lead to a change in the language, is Guido.
cheers, Georg
[1] Yes, I have read all those remarks about semicolons. What you all fail to recognize is that the majority of Python users like the colons, and wouldn't program without them. You can call it habit if you can't understand that it fits their thinking process, that's all the same: the colon won't just go away, just because it's made optional. Therefore, consistency is lost, not gained.
-- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
On 6-Feb-09, at 3:16 PM, Georg Brandl wrote:
Riobard Zhan schrieb:
On 5-Feb-09, at 7:31 AM, Steven D'Aprano wrote:
Riobard Zhan wrote:
Pascal uses colons, but not for the exact same purpose as Python. Both languages use colons in similar ways to it's use in English. In particular, Python uses colons as a break between clauses: larger than a comma, smaller than a period.
Pascal is my first language. It has been some years ago, so I cannot
remember the detail now. I checked wikipedia and did not find colons
are used after if's. Not sure if you mean declarations? If so, I
don't
think that is what we are discussing here; Java and C also use colons
in switch/case statements. AFAIK, Python is quite unique in requiring
trailing colons after if's, for's, and function/class definitions.
Python is also quite unique in using indentation to delimit blocks, so I'm not sure what point you're trying to make.
Sorry, I did not make it obvious. Please let me re-state it more
clearly.
I pointed out that Python is quite unique in requiring trailing colons
because I don't think there are any other popular languages do so.
Therefore I did not understand why you mentioned Pascal. I was trying
to figure out if you mean Pascal uses colons in declarations.
I think it's a good indicator for optional syntax if you can formulate new rules for PEP 8 that state when to use it. In the case of colons, you'd have to either forbid or mandate them; I'd be at a loss to find another consistent rule. So, making them optional is pointless; we should either keep them or remove them. And removing is out of the question.
Applying that indicator to semicolons, there is a clear rule in PEP 8 that states when to use them: to separate two statements on one line.
I thought semicolons and multiple statements on one line are
discouraged in PEP 8. Did I miss something? :|
However, the only person around here whose itches alone, in the face of a wall of disagreeing users, can lead to a change in the language, is Guido.
Agreed. That's what BDFL means.
I'm not trying to impose my itches on you. I'm not the BDFL. I'm
explaining why I think omitting colons makes Python more elegant.
Yes, I have read all those remarks about semicolons.
Thanks very much! I thought you ignored them before. I apologize :)
What you all fail to recognize is that the majority of Python users like the colons, and wouldn't program without them.
I doubt it. Would you not program other languages because they do not
have colons? Do you really think the majority of Python users care
about colons that much? I bet they will never notice if there is any
colons missing in a piece of Python code if colons are made optional.
On Sun, 08 Feb 2009 03:17:14 -0330, Riobard Zhan wrote:
I think it's a good indicator for optional syntax if you can formulate new rules for PEP 8 that state when to use it. In the case of colons, you'd have to either forbid or mandate them; I'd be at a loss to find another consistent rule. So, making them optional is pointless; we should either keep them or remove them. And removing is out of the question.
Applying that indicator to semicolons, there is a clear rule in PEP 8 that states when to use them: to separate two statements on one line.
I thought semicolons and multiple statements on one line are discouraged in PEP 8. Did I miss something? :|
Discouraged doesn't mean you can't use them. In fact the first section of PEP8 after the "Introduction" is "A Foolish Consistency is the Hobgoblin of Little Minds". lambda is discouraged, but when you think using lambda is more readable then defining a function, use it. PEP 8 is made to increase readability of code, if there is any PEP8 rules that decreases readability in your code, violate the rule.
However, the only person around here whose itches alone, in the face of a wall of disagreeing users, can lead to a change in the language, is Guido.
Agreed. That's what BDFL means.
I'm not trying to impose my itches on you. I'm not the BDFL. I'm explaining why I think omitting colons makes Python more elegant.
And you have failed to convince others that it is "more" elegant.
Yes, I have read all those remarks about semicolons.
Thanks very much! I thought you ignored them before. I apologize :)
Vice versa, we expect you to read other's post.
What you all fail to recognize is that the majority of Python users like the colons, and wouldn't program without them.
I doubt it. Would you not program other languages because they do not have colons? Do you really think the majority of Python users care about colons that much? I bet they will never notice if there is any colons missing in a piece of Python code if colons are made optional.
They might not notice it when they were writing it, but several days later when fixing an unrelated bug they would feel an itch.
I forgot one other comment...
Riobard Zhan wrote:
While I would not support the removal of colons, I would support a better error message when one is missing.
for x in 1,2,3 File "<stdin>", line 1 for x in 1,2,3 ^ SyntaxError: invalid syntax
Perhaps this should say why the syntax is missing?
SyntaxError: linebreak in statement or missing colon
-- Steven
Le Wed, 4 Feb 2009 23:35:30 -0330, Riobard Zhan yaogzhan@gmail.com a écrit :
Hi everybody,
I'm proposing to make colons optional.
I 99% agree with that. But 100% sure this will never happen. No chance at all, imo... Still, it may be worth exchanging some thoughts on the topic as an opprtunity to take some distance, and watch python common traits with an outer look (correct?).
Block starts already are indicated, to humans as well as to the machine, by instruction type and indentation. Parsing for validity check or for editor smart indentation may rely on instruction 'type':
if last_instruction.type in block_headline_types: <whatever>
I personly do not find that expression's semantics more complicated than e.g.:
if last_instruction.text.endswith(':'): <whatever>
The first one has the additional advantage to prevent the common error of editors indenting after comments that happen to end with ":" ;-) Which by the way shows that relying on ':' is an wrong algorithm; as well as the fact that we get an error when forgetting ':' shows that python parsers actually rely on more information, namely instruction type. Smart unindent in editors is already done that way, by identifying instructions like 'return' that very probably end a block and thus are followed by unindentation:
if last_instruction.type in probable_unindent_types: do_unindent
On the other hand, at the human semantic level, the presence of a ':' nicely introduces a block. One could object that this fact is basically western culture centered (like e.g. '#' meaning number is, as far as I know, purely english), but this is True for all common programming conventions. Computer science and technics is a product of western culture, anyway. People from other cultures have to get familiar with much more than arbitrary meaning of signs, before having a chance to explore computer programming.
A kind of meaning conflict nevertheless exists even in python itself: a ':' sign even more nicely carries a sense of binding, or link. Python uses this common world semantics in dict litteral key:value pairs.
Starting from this point, and looking for clarity and consistency, my wished syntactic revolution ;-) reads as follows:
Again, this is not intended as a proposal for python, not even a hope ;-) Just a reflexion on alternative syntactic ruleset. I would enjoy comments & critics about that.
Denis
PS: I will take the opportunity to propose a thread on the topic of "binding vs rebinding".
la vida e estranya
On 5-Feb-09, at 8:56 AM, spir wrote:
Le Wed, 4 Feb 2009 23:35:30 -0330, Riobard Zhan yaogzhan@gmail.com a écrit :
Hi everybody,
I'm proposing to make colons optional.
I 99% agree with that. But 100% sure this will never happen. No
chance at all, imo... Still, it may be worth exchanging some
thoughts on the topic as an opprtunity to take some distance, and
watch python common traits with an outer look (correct?).
I am a little bit different than you in the numbers--I 100% dislike
colons, but 99% sure they will never be made optional. That last 1%
leads me to give it a try here :) I totally agree with you that
discussing such issues would be a great chance to learn something
about Python. How many Python users outside this mailing list
understand the rationale behind colons? I guess it might be a few.
It's an issue worth thinking.
A kind of meaning conflict nevertheless exists even
in python
itself: a ':' sign even more nicely carries a sense of binding, or
link. Python uses this common world semantics in dict litteral
key:value pairs.
Colons are also used for slicing. Seem to be overused ...
On Thu, Feb 5, 2009 at 4:26 AM, spir denis.spir@free.fr wrote:
Le Wed, 4 Feb 2009 23:35:30 -0330, Riobard Zhan yaogzhan@gmail.com a écrit :
<snip>
I'm sorry but regarding these bullet points, C makes for a persuasive
argument for not changing the meaning of those operators. Pretty much
everyone in computing either knows well or is at least familiar with C
and probably knows one of its syntactic descendants quite well, so
gratuitous deviation from C violates the Principle of Least Surprise
for anyone who already is a programmer. Newbies may trip over it, but
they catch on eventually. If you did want to change the assignment
operator, the colon seems visually a poor choice IMHO; it's too easily
overlooked and x : y
looks rather sparse on a line by itself.
The other somewhat popular choices of assignment syntax that I've seen
are x := y, x <- y, and let x = y. The first and last of those still
use a =, albeit with something extra, and so aren't too much of a
stretch. x <- y is particularly deviant and isn't readable (as in read
it out loud) IMHO; you either have to read it right-to-left (which is
unnatural) as "Take y and put it into x", or as "x has y placed into
it" (which uses the passive voice and so does not fit well with an
imperative language.
Cheers, Chris
-- Follow the path of the Iguana... http://rebertia.com
On Thu, Feb 5, 2009 at 3:33 PM, Chris Rebert pyideas@rebertia.com wrote: [snip]
The other somewhat popular choices of assignment syntax that I've seen are x := y, x <- y, and let x = y. The first and last of those still use a =, albeit with something extra, and so aren't too much of a stretch. x <- y is particularly deviant and isn't readable (as in read it out loud) IMHO; you either have to read it right-to-left (which is unnatural) as "Take y and put it into x", or as "x has y placed into it" (which uses the passive voice and so does not fit well with an imperative language.
Furthermore, the "take y and put it into x" might be an appropriate interpretation for C but not for Python. For Python it should be instead something like "Assign the name x to object y" which could be visually represented by x -> y instead of x <- y as you mention.
André
>
Cheers, Chris
-- Follow the path of the Iguana... http://rebertia.com
Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
On Thu, Feb 5, 2009 at 11:53 AM, Andre Roberge andre.roberge@gmail.com wrote:
On Thu, Feb 5, 2009 at 3:33 PM, Chris Rebert pyideas@rebertia.com wrote: [snip]
The other somewhat popular choices of assignment syntax that I've seen are x := y, x <- y, and let x = y. The first and last of those still use a =, albeit with something extra, and so aren't too much of a stretch. x <- y is particularly deviant and isn't readable (as in read it out loud) IMHO; you either have to read it right-to-left (which is unnatural) as "Take y and put it into x", or as "x has y placed into it" (which uses the passive voice and so does not fit well with an imperative language.
Furthermore, the "take y and put it into x" might be an appropriate interpretation for C but not for Python. For Python it should be instead something like "Assign the name x to object y" which could be visually represented by x -> y instead of x <- y as you mention.
Indeed. Of course, I think that commits the equally cardinal sin of flipping the direction of the assignment operator, from variable-value to value-variable. :)
Cheers, Chris
-- Follow the path of the Iguana... http://rebertia.com
2009/2/5 spir denis.spir@free.fr:
Le Wed, 4 Feb 2009 23:35:30 -0330, Riobard Zhan yaogzhan@gmail.com a écrit :
Hi everybody,
I'm proposing to make colons optional.
def foo(x) ... return x+1
just looks sloppy to me. The colon helps show it's a definition. Perhaps this is my anglocentrism (sp?) showing, as in "Here is my function: ...". Native English speakers will notice how helpful that colon is.
[snip]
Starting from this point, and looking for clarity and consistency, my wished syntactic revolution ;-) reads as follows:
I sort of like this. One-liners should be doable with "if cond then stmt else stmt" instead of "if cond: stmt". I just think it's prettier; I can't really prove this or try to convince many people. Another option would be to add "if cond then stmt else stmt", and also require a newline after a colon, though this would mentally separate the two forms of 'if'.
Eww. I'll always keep ':=' and '<-' close to my heart, but I can't envision ':' as assignment.
Yeah, yeah, yeah...the day we finally get rid of the throngs of programmers complaining that assignment is too many characters for their weak little fingers to type will also be the day we finally get 'import soul' working correctly, and never have to program again. If only....
I've always been a fan of 'is'. I think it looks nice.
-- Cheers, Leif
On 5-Feb-09, at 10:04 AM, Christian Heimes wrote:
-1
Please keep Python sources readable.
Christian
-1
Please elaborate (better yet, give concrete examples) why it makes
Python code less readable.
The reason I propose to make colons optional is that I fail to see
colons make code more readable. They seem to be line noise to me. You
might disagree, but please explain why.
Riobard Zhan schrieb:
On 5-Feb-09, at 10:04 AM, Christian Heimes wrote:
-1
Please keep Python sources readable.
Christian
-1
Please elaborate (better yet, give concrete examples) why it makes Python code less readable.
The reason I propose to make colons optional is that I fail to see colons make code more readable. They seem to be line noise to me. You might disagree, but please explain why.
The colon at the end makes it clear it's the end of the statement, too.
Some example:
def method(self, some, very, long, method, going, over, lots, and, lots, and, lots, of, lines): pass
The second example makes it even more obvious:
if (some() and some_other() or some_more(complex=(True,))
and a_final_call(egg=(1,2,3))):
do_something()
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.
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.
Christian
Christian Heimes wrote:
def method(self, some, very, long, method, going, over, lots, and, lots, and, lots, of, lines): pass
This example line-continues via parentheses, so why isn't the right-paren enough?
if (some() and some_other() or
some_more(complex=(True,))
and a_final_call(egg=(1,2,3))):
do_something()
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))):
do_something()
With or without the colon, and it's more readable than your version (IMHO), and clearly the colon provides no aide to it.
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..
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.
-- Scott Dial scott@scottdial.com scodial@cs.indiana.edu
-- Scott Dial scott@scottdial.com scodial@cs.indiana.edu
2009/2/5 Scott Dial scott+python-ideas@scottdial.com:
Christian Heimes wrote:
def method(self, some, very, long, method, going, over, lots, and, lots, and, lots, of, lines): pass
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): ... pass
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))):
do_something()
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))): do_something()
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 that colon.
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 unreadability.
-- Cheers, Leif
Scott Dial writes:
Christian Heimes wrote:
def method(self, some, very, long, method, going, over, lots, and, lots, and, lots, of, lines): pass
This example line-continues via parentheses, so why isn't the right-paren enough?
My eyes are going; I no longer can see how many open parens are there without moving focus. The colon is a local indicator that allows me to avoid backtracking.
if
(some() and some_other() or some_more(complex=(True,))
and a_final_call(egg=(1,2,3))):
do_something()
This example uses the same mechanism as above.
Except that Python syntax allows you to omit one level of parentheses and still continue across lines, which you couldn't do without the colon. In this example I probably couldn't count the parentheses correctly even if I could see them all without moving eye focus.
I love Lisp, but I'm also very glad that Python is not Lisp.
On Thu, 05 Feb 2009 12:07:39 -0500, Scott Dial wrote:
if
(some() and some_other() or some_more(complex=(True,))
and a_final_call(egg=(1,2,3))):
do_something()
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))):
do_something()
With or without the colon, and it's more readable than your version
Lie Ryan wrote:
On Thu, 05 Feb 2009 12:07:39 -0500, Scott Dial wrote:
personally, I like this:
if some() and some_other() or \ some_more(complex=(True,)) and \ a_final_call(egg=(1,2,3)) \ : do_something()
My preference is to lead with keywords or symbols when it's convenient:
if (some() and some_other() or some_more(complex=(True,)) and a_final_call(egg=(1, 2, 3))): do_something()
For long math expressions spanning multiple lines I usually split before addition or subtraction signs.
if (some_long_value * another_long_value
+ some_long_value * a_special_quanity
- an_offset_of_some_size):
do_something()
With syntax highlighting these becomes even more readable. The eye and mind just follow along the vertical line of highlighted keywords or operations until it reaches the end.
As far as optional things go, I'd like the '\' to be optional for multiple lines that end with a ':'. Adding parentheses around the expression works, but it seems like a compromise to me.
Cheers, Ron
On Tue, 10 Feb 2009 10:54:52 -0600, Ron Adam wrote:
Lie Ryan wrote:
On Thu, 05 Feb 2009 12:07:39 -0500, Scott Dial wrote:
personally, I like this:
if some() and some_other() or \ some_more(complex=(True,)) and \ a_final_call(egg=(1,2,3)) \ : do_something()
My preference is to lead with keywords or symbols when it's convenient:
if (some() and some_other() or some_more(complex=(True,)) and a_final_call(egg=(1, 2, 3))): do_something()
For long math expressions spanning multiple lines I usually split before addition or subtraction signs.
if (some_long_value * another_long_value
+ some_long_value * a_special_quanity -
an_offset_of_some_size):
do_something()
With syntax highlighting these becomes even more readable. The eye and mind just follow along the vertical line of highlighted keywords or operations until it reaches the end.
As far as optional things go, I'd like the '\' to be optional for multiple lines that end with a ':'. Adding parentheses around the expression works, but it seems like a compromise to me.
Cheers, Ron
Under ideal circumstances, when I see codes like that I'll turn it into a function. Such a complex expression decreases readability exponentially, turning it into a function would make it much more readable. Worse is if the expression uses a lot of parentheses, it becomes a nightmare trying to count the parentheses, keep it balanced, and keep it logically correct.
r = 1.0 / ( (np * pn)(n*p) + lw )
where r = readability n = number of terms p = number of parentheses used to change evaluation order l = number of lines w = average width of each line
n = 4, l = 4, p = 3, w = 20 the readability of that expression is:
r = 2.6547283374476086e-45
Le Thu, 05 Feb 2009 17:53:46 +0100, Christian Heimes lists@cheimes.de a écrit :
[...]
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.
So why not support a PEP to introduce compulsory ';' at the end of all not-compound statements? All your comments and exemples hold both for ordinary statements and block headlines -- or do I miss the point?
The second example makes it even more obvious:
if (some() and some_other() or some_more(complex=(True,))
and a_final_call(egg=(1,2,3))):
Do(some(), some_other(), some_more(complex=(True,)), and_final_call(egg=(1,2,3,zzzzz=False))); # endof statement is obvious
Denis
Christian
Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
la vida e estranya
On 5-Feb-09, at 1:40 PM, spir wrote:
Le Thu, 05 Feb 2009 17:53:46 +0100, Christian Heimes lists@cheimes.de a écrit :
[...]
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.
So why not support a PEP to introduce compulsory ';' at the end of
all not-compound statements? All your comments and exemples hold
both for ordinary statements and block headlines -- or do I miss the
point?
The second example makes it even more obvious:
if (some() and some_other() or some_more(complex=(True,)) and a_final_call(egg=(1,2,3))):
Do(some(), some_other(), some_more(complex=(True,)),
and_final_call(egg=(1,2,3,zzzzz=False))); # endof
statement is obvious
This is exactly the point in my mind! :)
If semicolons are optional, so should be colons. If line continuation
really matters, we should use both anyway. Why the irregularity?
On Thu, 05 Feb 2009 14:59:59 -0330, Riobard Zhan wrote:
The second example makes it even more obvious:
if (some() and some_other() or some_more(complex=(True,)) and a_final_call(egg=(1,2,3))):
Do(some(), some_other(), some_more(complex=(True,)), and_final_call(egg=(1,2,3,zzzzz=False))); # endof statement is obvious
This is exactly the point in my mind! :)
What is that piece of code supposed to mean? Is it supposed to mean the same as the easy to understand if-clause above it? Among the parentheses clouds, I can't see the end-of-line easily...