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 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&meta=

Tim Delaney

On Wed, Feb 4, 2009 at 10:05 PM, Riobard Zhan 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

I forgot one other comment... Riobard Zhan wrote:

- 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.

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

-1 Please keep Python sources readable. Christian

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.

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

On 5-Feb-09, at 7:31 AM, Steven D'Aprano wrote:

Riobard Zhan wrote:

...

- 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?

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 find colons pretty annoying. ...

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.

...

- What problems do you think will occur if colons are made 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 5-Feb-09, at 1:40 PM, spir wrote:

Le Thu, 05 Feb 2009 17:53:46 +0100, Christian Heimes 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, Feb 5, 2009 at 8:05 AM, Riobard Zhan wrote:

On 5-Feb-09, at 12:37 AM, Ben Finney wrote:

...

...

- We already have indentation to visually separate different levels of code. Why bother with those extra colons at all?

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, 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")

On 5-Feb-09, at 3:37 PM, Chris Rebert wrote:

On Thu, Feb 5, 2009 at 8:05 AM, Riobard Zhan wrote:

...

On 5-Feb-09, at 12:37 AM, Ben Finney wrote:

...

...

- We already have indentation to visually separate different levels of code. Why bother with those extra colons at all?

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.

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 find colons pretty annoying. ...

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

2009/2/5 spir :

Le Wed, 4 Feb 2009 23:35:30 -0330, Riobard Zhan a écrit :

...

Hi everybody,

I'm proposing to make colons optional.

-1. I like the colons. They're not strictly necessary, but defining functions like

...

...

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: * Get rid of ':' at end of headlines. * Allow only single-instruction blocks (suites) for one-liners: "if cond; do_that". Or maybe no separator at all is necessary here for unambiguous parsing? Or replace ':' or ';' by 'then'. This would also allow if...then...else one-liners. Alternatively, make newline+indent compulsery. This is anyway often recommended in style guidelines.

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'.

* Extend name binding format "name:value" to assignments. That is, write "a:1" instead of "a=1. This may avoid tons of misunderstandings (imo, '=' for assignment is a semantic plague, a major error/fault, a pedagogic calamity).

Eww. I'll always keep ':=' and '<-' close to my heart, but I can't envision ':' as assignment.

* Which lets the "=" sign free for better use: use "=" for the semantics of equality, like in math and common interpretation learnt from school.

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....

* Perhaps: use "==" for identity, instead of "is".

I've always been a fan of 'is'. I think it looks nice. -- 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 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 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

[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

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".

Le Fri, 06 Feb 2009 08:40:27 +1100, Ben Finney 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

Le Fri, 06 Feb 2009 02:23:47 -0500, Scott Dial 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? Denis ------ la vida e estranya

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 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 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 4:50 AM, Leif Walsh wrote:

On Fri, Feb 6, 2009 at 2:49 AM, Steven D'Aprano 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 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 6, 2009 at 9:51 AM, Riobard Zhan 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:15 AM, Curt Hagenlocher wrote:

On Fri, Feb 6, 2009 at 6:37 AM, Riobard Zhan 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 6-Feb-09, at 11:40 AM, Leif Walsh wrote:

On Fri, Feb 6, 2009 at 9:51 AM, Riobard Zhan 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.

On Fri, Feb 6, 2009 at 7:14 AM, Riobard Zhan 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

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.

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 -=.

Riobard Zhan schrieb:

On 5-Feb-09, at 7:31 AM, Steven D'Aprano wrote:

...

Riobard Zhan wrote:

...

- 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?

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 find colons pretty annoying. ...

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.

...

...

- What problems do you think will occur if colons are made 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 ...

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 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, and I will probably play with your demo python -- Leonardo Santagada santagada at gmail.com

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 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.

On 6-Feb-09, at 5:57 PM, Ben Finney wrote:

Riobard Zhan 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.

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:

...

- 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?

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 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

On Sat, Feb 7, 2009 at 10:47 PM, Riobard Zhan 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

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

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 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.

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 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

<nitpick> of course a more pythonic approach would format it as this: if (some() and some_other() or some_more(complex=(True,)) and a_final_call(egg=(1,2,3))): do_something() It is clear that the if-clause continues to the next line because there is an unsatisfied "and" in the end of it and it is also consistent with PEP 8's guideline for having operators/keywords before breaking. alternatively: if some() and some_other() or some_more(complex=(True,)) and \ a_final_call(egg=(1,2,3)): do_something() it is even clearer since there is a line continuation token "\". personally, I like this: if some() and some_other() or \ some_more(complex=(True,)) and \ a_final_call(egg=(1,2,3)) \ : do_something() anything more complex than a very simple expression in a multi-line if should really be on its own line, irrespective of whether it has reached the character limit or not. Even more preferably though, that expression shouldn't be that complex, it becomes hard to follow the logic of the if. The program require a little bit of factoring if I saw such expression. </nitpick>

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