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