On Thu, Feb 5, 2009 at 8:05 AM, Riobard Zhan yaogzhan@gmail.com wrote: >

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 7:31 AM, Steven D'Aprano wrote:

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.

>

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 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 3:37 PM, Leonardo Santagada wrote:

>

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 didn't say that Pascal uses colons after IFs. I explicitly said Pascal used colons "not for the exact same purpose as Python".

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.

Peer pressure. Everybody would laugh at their code and think they're foolish.

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.

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

Riobard Zhan yaogzhan@gmail.com writes:

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.

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

Riobard Zhan yaogzhan@gmail.com writes:

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.

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

Riobard Zhan yaogzhan@gmail.com writes:

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.

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

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

Riobard Zhan wrote:

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.

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

Leif Walsh wrote:

"Fairness" is not a language design principle.

-- Steven

On 6-Feb-09, at 4:50 AM, Leif Walsh wrote:

What bothers me here is that colon-lovers seem to assume their choice
is the choice.

On 6-Feb-09, at 11:40 AM, Leif Walsh wrote:

That's what to be debated. And they fail to give a rational argument
to explain why.

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

-- Steven

Riobard Zhan wrote:

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

That may be true, but most people who think colons should not be optional also don't bother coming here and discussing it.

So you say.

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

Le Fri, 06 Feb 2009 02:23:47 -0500, Scott Dial scott+python-ideas@scottdial.com a écrit :

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 Fri, Feb 6, 2009 at 6:37 AM, Riobard Zhan yaogzhan@gmail.com wrote: >

"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 Fri, Feb 6, 2009 at 7:14 AM, Riobard Zhan yaogzhan@gmail.com wrote: >

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

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

On 6-Feb-09, at 2:27 PM, 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. There are some
differences between making commas optional and making trailing colons
optional.

On 8-Feb-09, at 3:50 AM, Bruce Leban wrote:

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.

This generalization is meaningless. You deliberately ignored the
original context.

What's the point you are trying to make?

On 8-Feb-09, at 2:18 PM, Bruce Leban wrote:

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.

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 6-Feb-09, at 4:32 AM, Stephen J. Turnbull wrote:

I think the mailing list I am posting to is called "Python Ideas".

On 6-Feb-09, at 10:51 AM, Oleg Broytmann wrote:

What do you think the idea of making semicolons optional?

On 6-Feb-09, at 11:39 AM, Oleg Broytmann wrote:

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 6-Feb-09, at 12:01 PM, Oleg Broytmann wrote:

It's OK. We just have different understanding of how "big" is "big".

I'm perfectly fine with them. Have lived with them for a couple of
years.

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 Fri, Feb 06, 2009, Riobard Zhan wrote: >

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

effectively zero chance of convincing him to drop the colons.

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.

Riobard Zhan writes:

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

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

On 8-Feb-09, at 4:51 AM, Stephen J. Turnbull wrote: >

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 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 6-Feb-09, at 7:50 PM, Leonardo Santagada wrote: >

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.

On 6-Feb-09, at 9:00 PM, Steven D'Aprano wrote:

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.

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 :

Probably...

Denis

la vida e estranya

On 6-Feb-09, at 5:41 AM, spir wrote:

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.

On 6-Feb-09, at 3:16 PM, Georg Brandl wrote:

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 thought semicolons and multiple statements on one line are
discouraged in PEP 8. Did I miss something? :|

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.

Thanks very much! I thought you ignored them before. I apologize :)

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 5-Feb-09, at 8:56 AM, spir wrote:

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.

Colons are also used for slicing. Seem to be overused ...

On Thu, Feb 5, 2009 at 3:33 PM, Chris Rebert pyideas@rebertia.com wrote: [snip]

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é

>

2009/2/5 spir denis.spir@free.fr:

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.

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

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.

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

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

Scott Dial writes:

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

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.

Lie Ryan wrote:

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

Le Thu, 05 Feb 2009 17:53:46 +0100, Christian Heimes lists@cheimes.de a écrit :

[...]

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?

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

la vida e estranya

On Thu, 05 Feb 2009 14:59:59 -0330, Riobard Zhan wrote:

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