Re: A case for "real" multiline comments
On Thu, Apr 19, 2012 at 10:15 PM, Devin Jeanpierre wrote: > Why don't you allow nested multiline comments? Many languages (e.g. > ML, Scheme, Haskell, etc.) allow you to nest multi-line comments. It's > mostly the C family of languages that refuse to do this, AFAIK. Allowing nesting or not allowing nesting is a design choice. If you write code that looks for the string /* or */ in a REXX program, you need to be careful in case it mis-nests (the usual recommendation is to use "/"||"*" instead of "/*" as a single literal). It makes no difference which way you choose, there's always issues to deal with. > Least importantly: Why are multiline comments line-oriented? Why not > inline, like with the C-style /* ... */ comments? This doesn't seem > like a "proper" multiline comment. That thought was to avoid the complaint that you can easily lose the comment markers somewhere other than clearly at the beginning of the line. By demanding that they delimit entire lines, we avoid this. Of course, Python could choose to support /* */ comments instead/as well. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: A case for "real" multiline comments
On Thu, Apr 19, 2012 at 2:56 AM, Chris Angelico wrote: > So, here's a proposal. (Maybe I should take this part to another list > or the Python issue tracker.) Introduce a new keyword or reuse > existing keywords to form a marker that unambiguously says "Ignore > these lines" and then subsequently "Stop ignoring lines". These > markers must go on their own lines, optionally with whitespace and/or > a one-line comment, but nothing else. This could accidentally > terminate or nest if a triple-quoted string contains Python code, but > that would always be an issue. > -8<- > > The exact choice of keywords is open to discussion, I just looked at > keyword.kwlist on my Python 3.2 and tried to come up with something. > This syntax looks like it wouldn't nest, so it's unideal for the > proposal. > > Does Python need multi-line code removal? And if so, will something > like this work? Two questions: Why don't you allow nested multiline comments? Many languages (e.g. ML, Scheme, Haskell, etc.) allow you to nest multi-line comments. It's mostly the C family of languages that refuse to do this, AFAIK. Least importantly: Why are multiline comments line-oriented? Why not inline, like with the C-style /* ... */ comments? This doesn't seem like a "proper" multiline comment. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: A case for "real" multiline comments
On Thu, Apr 19, 2012 at 8:17 PM, Alek Storm wrote: >> comment def >> ... parser completely ignores these lines ... >> comment break > > > I believe the more Pythonic syntax would be: > > comment: > ...some > ...indented > ...lines > > God help us if that ever happens. Certainly not. That completely ignores the whole point of this, which is to remove a block of lines without editing them all. Anyway, replace "comment:" with "if 0:" and you have it already. No, this is something that's parsed before indentation blocks are processed. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: A case for "real" multiline comments
Chris Angelico wrote: [snip] Since Python doesn't have multiline comments, triple-quoted strings are sometimes pressed into service. [snip] Chris Angelico Let the triple quotes where they're meant to be. Use your text editor, any decent one will allow you to comment uncomment a block of code. JM -- http://mail.python.org/mailman/listinfo/python-list
Re: A case for "real" multiline comments
I think docstrings should look like strings, because they're essentially data: they end up as the __doc__ attribute of whatever class or function they're documenting. Conversely, they shouldn't be used as multi-line comments that aren't data (in the middle of functions) - the parser should disallow strings as stand-alone expressions after the initial docstring. This wouldn't solve Jordan's problem outright, since his string was inside a list, but it may prevent people from making that mistake in the future, since docstrings would have a purpose more specialized than "multi-line comment". comment def > ... parser completely ignores these lines ... > comment break > I believe the more Pythonic syntax would be: comment: ...some ...indented ...lines God help us if that ever happens. Alek On Thu, Apr 19, 2012 at 1:56 AM, Chris Angelico wrote: > On Thu, Apr 19, 2012 at 4:04 PM, Cameron Simpson wrote: > > Bah! To get into a function's docstring they need to be parsed by the > > Python compiler. Ergo, not comments. > > > > Calling them comments in disguise is a bit of a stretch. > > They're fundamentally the same thing as Doxygen/Javadoc/etc comments. > The interpreter could easily have been written to take the contents of > a comment immediately preceding a function definition and store it as > an attribute. It's not fundamentally a literal string, because there's > nowhere for it to "go". It's a special feature of the parser that > takes a pile of text and stores it somewhere for self-documentation > purposes. > > > Sorry, he's made a misparsed program (not parsed as he intended) by > > using a string where he should have used a comment? And because of this > > he says we need (or should want) multiline comments? > > Since Python doesn't have multiline comments, triple-quoted strings > are sometimes pressed into service. In this particular instance, a > triple-quoted string *cannot* be used. Ergo, he is making the case > that Python needs multiline comments. It makes perfectly good sense. > You can disagree with it, but you can't scoff at his logic. > > > A multiline comment can just as easily be misused to similar effect: > > > > list = [ > > Object1(arg) /* bored now > > Object2(arg), > > Object3(arg), > > */ > > Object4(arg) > > ] > > Heh, you can do far worse with slash-star comments. > > list = [ > Object1(arg), > Object2(arg), /* > Object3(arg), * Important comment > Object4(arg), */ > Object5(arg), > ] > > Oops, just how many objects are in that list? > > > I'd be more included to call implicit string concatenation a syntax > > flaw, for all that it makes breaking strings us pretty nice. > > > > | You just happen to disagree, and you prefer single line comments. :) > > > > With cited reasons. > > Yes, so let's have a sane discussion :) I do see your reasons, and > there's no perfect solution. > > > A multiline comment can have its top or bottom off the screen, so the > > reader need not know they're looking at commented out code. And the > > number of parse errors I've seen where the offending comment opener was > > WAY WAY back in the code because someone forgot or removed a closing > > comment marker is huge. > > Yep. That's a pretty tricky one to find, if your editor doesn't > color-code comments. It's also tricky to handle when your editor is > buggy. As mentioned, I use SciTE; a while back, there was an odd > little bug in it with regard to a combination of #if and /* and #endif > and */ in some order, and the parser did get confused. (The author is > pretty good at dealing with reported bugs, though. It didn't take long > from report to patch.) But in the normal case, where you're using a > decent editor that knows what's commented and what's not? It's pretty > easy to figure out what's going on. And if someone mucked up comment > markers in an edit, source control should help you pin the error down. > > > | ... preprocessor #if 0 #endif pair. > > > > Which are also something of a pain to match up, leading to (hopefully > > correctly labelled) #endifs thus: > > > > #endif /* !FEATUREMACRO */ > > Well, I was thinking of having *only* the #if 0 construct, nothing > else, so there's no need to worry about matching them up. > > > I realise I could paint myself into opposing all multiline constructs, > > especially loops and ifs, but I am generally quite happy with single > > line comments. For one thing, they pretty much force yo
Re: A case for "real" multiline comments
On Thu, Apr 19, 2012 at 4:04 PM, Cameron Simpson wrote: > Bah! To get into a function's docstring they need to be parsed by the > Python compiler. Ergo, not comments. > > Calling them comments in disguise is a bit of a stretch. They're fundamentally the same thing as Doxygen/Javadoc/etc comments. The interpreter could easily have been written to take the contents of a comment immediately preceding a function definition and store it as an attribute. It's not fundamentally a literal string, because there's nowhere for it to "go". It's a special feature of the parser that takes a pile of text and stores it somewhere for self-documentation purposes. > Sorry, he's made a misparsed program (not parsed as he intended) by > using a string where he should have used a comment? And because of this > he says we need (or should want) multiline comments? Since Python doesn't have multiline comments, triple-quoted strings are sometimes pressed into service. In this particular instance, a triple-quoted string *cannot* be used. Ergo, he is making the case that Python needs multiline comments. It makes perfectly good sense. You can disagree with it, but you can't scoff at his logic. > A multiline comment can just as easily be misused to similar effect: > > list = [ > Object1(arg) /* bored now > Object2(arg), > Object3(arg), > */ > Object4(arg) > ] Heh, you can do far worse with slash-star comments. list = [ Object1(arg), Object2(arg), /* Object3(arg), * Important comment Object4(arg), */ Object5(arg), ] Oops, just how many objects are in that list? > I'd be more included to call implicit string concatenation a syntax > flaw, for all that it makes breaking strings us pretty nice. > > | You just happen to disagree, and you prefer single line comments. :) > > With cited reasons. Yes, so let's have a sane discussion :) I do see your reasons, and there's no perfect solution. > A multiline comment can have its top or bottom off the screen, so the > reader need not know they're looking at commented out code. And the > number of parse errors I've seen where the offending comment opener was > WAY WAY back in the code because someone forgot or removed a closing > comment marker is huge. Yep. That's a pretty tricky one to find, if your editor doesn't color-code comments. It's also tricky to handle when your editor is buggy. As mentioned, I use SciTE; a while back, there was an odd little bug in it with regard to a combination of #if and /* and #endif and */ in some order, and the parser did get confused. (The author is pretty good at dealing with reported bugs, though. It didn't take long from report to patch.) But in the normal case, where you're using a decent editor that knows what's commented and what's not? It's pretty easy to figure out what's going on. And if someone mucked up comment markers in an edit, source control should help you pin the error down. > | ... preprocessor #if 0 #endif pair. > > Which are also something of a pain to match up, leading to (hopefully > correctly labelled) #endifs thus: > > #endif /* !FEATUREMACRO */ Well, I was thinking of having *only* the #if 0 construct, nothing else, so there's no need to worry about matching them up. > I realise I could paint myself into opposing all multiline constructs, > especially loops and ifs, but I am generally quite happy with single > line comments. For one thing, they pretty much force you to mark all the > lines with leading comment syntax; you can't ever be misled. Yes, that is true. It's tedious, though, when you want to quickly remove a dozen lines of code; most editors that allow you to block-comment code have only one way of doing it, and if that way doesn't suit your personal style, it grates. I'd still rather have a proper multiline comment. So, here's a proposal. (Maybe I should take this part to another list or the Python issue tracker.) Introduce a new keyword or reuse existing keywords to form a marker that unambiguously says "Ignore these lines" and then subsequently "Stop ignoring lines". These markers must go on their own lines, optionally with whitespace and/or a one-line comment, but nothing else. This could accidentally terminate or nest if a triple-quoted string contains Python code, but that would always be an issue. Option 1: New keyword. comment def ... parser completely ignores these lines ... comment break Option 2: Reuse keywords. from None import ... ignore these lines ... from True import The exact choice of keywords is open to discussion, I just looked at keyword.kwlist on my Python 3.2 and tried to come up with something. This syntax looks like it wouldn't nest, so it's unideal for the proposal. Does Python need multi-line code removal? And if so, will something like this work? Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
Re: A case for "real" multiline comments
On 19Apr2012 15:13, Chris Angelico wrote: | On Thu, Apr 19, 2012 at 2:29 PM, Cameron Simpson wrote: | > On 18Apr2012 22:07, Jordan Perr wrote: | > | I came across this case while debugging some Python code that contained an | > | error stemming from the use of multiline strings as comments. The code | > | contained a very long list of objects, and I had commented out some of the | > | objects using the multiline string. | > | > You are aware that a string is not a comment? | | They're often (ab)used as comments, since Python lacks a multiline | comment facility. Even docstrings are really comments in disguise. Bah! To get into a function's docstring they need to be parsed by the Python compiler. Ergo, not comments. Calling them comments in disguise is a bit of a stretch. | > I'd just do this: | > | > list = [ | > Object1(arg), | > ## Object2(arg), | > ## Object3(arg), | > Object4(arg) | > ] | > | > Multiple lines of single line comments. Frankly, I find this much easier | > to see (all the disabled lines are delineated with nice bright comment | > markers, and the beginning and end of the comment (were it a multiline | > comment) can't disappear off my screen. | > | > I would say you've made a case _against_ multiline coments. | | On the contrary, he has definitely made a case for multiline comments. Sorry, he's made a misparsed program (not parsed as he intended) by using a string where he should have used a comment? And because of this he says we need (or should want) multiline comments? A multiline comment can just as easily be misused to similar effect: list = [ Object1(arg) /* bored now Object2(arg), Object3(arg), */ Object4(arg) ] I'd be more included to call implicit string concatenation a syntax flaw, for all that it makes breaking strings us pretty nice. | You just happen to disagree, and you prefer single line comments. :) With cited reasons. A multiline comment can have its top or bottom off the screen, so the reader need not know they're looking at commented out code. And the number of parse errors I've seen where the offending comment opener was WAY WAY back in the code because someone forgot or removed a closing comment marker is huge. | I like multiline comments, but they do have their associated problems, | most notably nesting. It gets quite awkward commenting out code that | searches for comment markers, too. | Perhaps what's needed is not a C-style /* */ comment marker, but | something which must always be on a line of its own, and can therefore | ONLY delimit entire-line comments. Something like what's often done | with a preprocessor #if 0 #endif pair. Which are also something of a pain to match up, leading to (hopefully correctly labelled) #endifs thus: #endif /* !FEATUREMACRO */ I realise I could paint myself into opposing all multiline constructs, especially loops and ifs, but I am generally quite happy with single line comments. For one thing, they pretty much force you to mark all the lines with leading comment syntax; you can't ever be misled. | There's no way you can "lose" | the #endif at the end of a line, True. Cheers, -- Cameron Simpson DoD#743 http://www.cskk.ezoshosting.com/cs/ It's better, when you're racing with someone you don't know so well, to stick to the inside line - it's easier to avoid the bits. - Barry Sheene, bike GP commentator -- http://mail.python.org/mailman/listinfo/python-list
Re: A case for "real" multiline comments
On Thu, Apr 19, 2012 at 2:29 PM, Cameron Simpson wrote: > On 18Apr2012 22:07, Jordan Perr wrote: > | I came across this case while debugging some Python code that contained an > | error stemming from the use of multiline strings as comments. The code > | contained a very long list of objects, and I had commented out some of the > | objects using the multiline string. > > You are aware that a string is not a comment? They're often (ab)used as comments, since Python lacks a multiline comment facility. Even docstrings are really comments in disguise. > I'd just do this: > > list = [ > Object1(arg), > ## Object2(arg), > ## Object3(arg), > Object4(arg) > ] > > Multiple lines of single line comments. Frankly, I find this much easier > to see (all the disabled lines are delineated with nice bright comment > markers, and the beginning and end of the comment (were it a multiline > comment) can't disappear off my screen. > > I would say you've made a case _against_ multiline coments. On the contrary, he has definitely made a case for multiline comments. You just happen to disagree, and you prefer single line comments. :) I like multiline comments, but they do have their associated problems, most notably nesting. It gets quite awkward commenting out code that searches for comment markers, too. Perhaps what's needed is not a C-style /* */ comment marker, but something which must always be on a line of its own, and can therefore ONLY delimit entire-line comments. Something like what's often done with a preprocessor #if 0 #endif pair. There's no way you can "lose" the #endif at the end of a line, and editors can still syntax-highlight it (at least, SciTE does; haven't looked at many editors lately). It nests correctly, but can't ever mis-nest with a literal string. Thoughts? ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: A case for "real" multiline comments
On Thu, Apr 19, 2012 at 12:29 AM, Cameron Simpson wrote: > I'd just do this: > > list = [ > Object1(arg), > ## Object2(arg), > ## Object3(arg), > Object4(arg) > ] > > Multiple lines of single line comments. Frankly, I find this much easier > to see (all the disabled lines are delineated with nice bright comment > markers, and the beginning and end of the comment (were it a multiline > comment) can't disappear off my screen. My text editor just greys it out either way, so I don't get this readability argument. Does anyone use an editor that doesn't highlight comments appropriately? Fortunately, my editor can insert single-line comments in bulk, so multi-line comments aren't a big deal to me. I don't really get why Python doesn't have them, though. > I would say you've made a case _against_ multiline coments. Could you explain how? -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: A case for "real" multiline comments
On 18Apr2012 22:07, Jordan Perr wrote: | I came across this case while debugging some Python code that contained an | error stemming from the use of multiline strings as comments. The code | contained a very long list of objects, and I had commented out some of the | objects using the multiline string. You are aware that a string is not a comment? | This caused a string to be appended to | the list instead of ignoring the section. Consider the following code: | | list = [ | Object1(arg), | """ | Object2(arg), | Object3(arg), | """ | Object4(arg) | ] | | Real multiline comments would produce [Object1, Object4]. The list, in | fact, contains [Object1, "Object2, Object3", Object4]. I can't really see a | good way to get around this without true multiline comments. I'd just do this: list = [ Object1(arg), ## Object2(arg), ## Object3(arg), Object4(arg) ] Multiple lines of single line comments. Frankly, I find this much easier to see (all the disabled lines are delineated with nice bright comment markers, and the beginning and end of the comment (were it a multiline comment) can't disappear off my screen. I would say you've made a case _against_ multiline coments. Cheers, -- Cameron Simpson DoD#743 http://www.cskk.ezoshosting.com/cs/ Sam Jones on the Nine Types of User: Frying Pan/Fire Tactician - "It didn't work with the data set we had, so I fed in my aunt's recipe for key lime pie." Advantages: Will usually fix error. Disadvantages: 'Fix' is defined VERY loosely here. Symptoms: A tendancy to delete lines that get errors instead of fixing them. Real Case: One user complained that their program executed, but didn't do anything. The scon looked at it for twenty minutes before realizing that they'd commented out EVERY LINE. The user said, "Well, that was the only way I could get it to compile." -- http://mail.python.org/mailman/listinfo/python-list
A case for "real" multiline comments
I came across this case while debugging some Python code that contained an error stemming from the use of multiline strings as comments. The code contained a very long list of objects, and I had commented out some of the objects using the multiline string. This caused a string to be appended to the list instead of ignoring the section. Consider the following code: list = [ Object1(arg), """ Object2(arg), Object3(arg), """ Object4(arg) ] Real multiline comments would produce [Object1, Object4]. The list, in fact, contains [Object1, "Object2, Object3", Object4]. I can't really see a good way to get around this without true multiline comments. - Jordan -- http://mail.python.org/mailman/listinfo/python-list
Re: multiline comments
Sion Arrowsmith wrote: > It appears to me that our fundamental difference is that you see value > in long-term preservation of sections of commented-out code without > any kind of real comment as to what's going on, whereas I consider > this to be appallingly bad practice. Then you're reading too much into my examples. Real code would be accompanied by descriptive comments. -- http://mail.python.org/mailman/listinfo/python-list
Re: multiline comments
Edward Elliott <[EMAIL PROTECTED]> wrote: >Sion Arrowsmith wrote: >> Really? Under what circumstances is it easier to see what's going on >> with start/end comments than with comment-to-end-of-line? >Off the top of my head: > [ ... ] It appears to me that our fundamental difference is that you see value in long-term preservation of sections of commented-out code without any kind of real comment as to what's going on, whereas I consider this to be appallingly bad practice. -- \S -- [EMAIL PROTECTED] -- http://www.chaos.org.uk/~sion/ ___ | "Frankly I have no feelings towards penguins one way or the other" \X/ |-- Arthur C. Clarke her nu becomeþ se bera eadward ofdun hlæddre heafdes bæce bump bump bump -- http://mail.python.org/mailman/listinfo/python-list
Re: multiline comments
"OKB (not okblacke)" <[EMAIL PROTECTED]> writes: > Ben Finney wrote: > > If your revision control system is so inconvenient to use that > > you'd rather have large blocks of commented-out code, it's time to > > start using a better RCS -- perhaps a distributed one, so you can > > commit to your own local repository with abandon while trying out > > changes. > > I don't buy this kind of argument. It seems strange to say > that the language is designed a certain way because users are > expected to use certain kinds of third-party tools to manage their > code. You're reading a causal relationship where none was asserted. > What if I'm just putting together a little script to do something > and I don't want to mess with a revision control system? If it's so little, why are single-line comments not enough? If it's large enough that large blocks of code need changing frequently, I assert revision control is needed. The barriers to using a good revision control system are so low these days it's poor practice to avoid using one for anything but throw-away programs. -- \ "The illiterate of the future will not be the person who cannot | `\ read. It will be the person who does not know how to learn." | _o__) -- Alvin Toffler | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: multiline comments
Ben Finney wrote: > Indeed. Using revision control means never needing to comment out > blocks of code. > > If your revision control system is so inconvenient to use that you'd > rather have large blocks of commented-out code, it's time to start > using a better RCS -- perhaps a distributed one, so you can commit to > your own local repository with abandon while trying out changes. I don't buy this kind of argument. It seems strange to say that the language is designed a certain way because users are expected to use certain kinds of third-party tools to manage their code. What if I'm just putting together a little script to do something and I don't want to mess with a revision control system? -- --OKB (not okblacke) Brendan Barnwell "Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail." --author unknown -- http://mail.python.org/mailman/listinfo/python-list
Re: multiline comments
rx wrote: > Still a little strange to newcomers that there are three ways to do the > same and that you should be carefull to use the right '''/""" inside the > comment else the comment will not work for some reason. > > #comment > > ''' > comment > ''' > > """ > comment > """ Please, note that triple quotes are not for comments. They may be used like that and they are used like that, but their primary intention is for multiline strings (something like the here docs in Perl, for example). Triple quotes can also be used like this: usage = """ This program accepts the following options: --help, -h Display this message --verbose, -v Display more details """ This defines a multiline string. If you had to use only single quotes then you'd have to insert "\n" for each newline. -- Jorge Godoy <[EMAIL PROTECTED]> "Quidquid latine dictum sit, altum sonatur." - Qualquer coisa dita em latim soa profundo. - Anything said in Latin sounds smart. -- http://mail.python.org/mailman/listinfo/python-list
Re: multiline comments
"Jorge Godoy" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > rx wrote: > >> I don't understand the problem - why should comments (and I hope you >> believe there should be a one line comment at least) be restricted to one >> line. It doesn't work that way for if, while, for. > > It is the minimum case that can solve a problem commenting one line -- or > part of it as in "print '3' # print the number 3" -- or commenting > multiple > lines. It is also easier to deal with since you don't have to end your > comment all the time. > > For "if", "while", "for", etc. you have ":" and the indentation. You > don't > have an "endif", "endwhile", "endfor" (so, why having an "end comment"?). > > -- > Jorge Godoy <[EMAIL PROTECTED]> > There no reason why a multiple line comment couldn't be indented (then the indentation is the end of comment in some sense), but I don't find that logical - after all its my comment and I don't want python to tell me how to indent it. -- http://mail.python.org/mailman/listinfo/python-list
Re: multiline comments
> > Of course! You should have used """ since you already used ''' in your > triple-quoted text. But I'm just repeating what I already said (and kept > above so that you can see it again). > > -- > Jorge Godoy <[EMAIL PROTECTED]> > Sorry - I should have read more carefully. I like the idea and will use it I think. Still a little strange to newcomers that there are three ways to do the same and that you should be carefull to use the right '''/""" inside the comment else the comment will not work for some reason. #comment ''' comment ''' """ comment """ -- http://mail.python.org/mailman/listinfo/python-list
Re: multiline comments
rx wrote: > I don't understand the problem - why should comments (and I hope you > believe there should be a one line comment at least) be restricted to one > line. It doesn't work that way for if, while, for. It is the minimum case that can solve a problem commenting one line -- or part of it as in "print '3' # print the number 3" -- or commenting multiple lines. It is also easier to deal with since you don't have to end your comment all the time. For "if", "while", "for", etc. you have ":" and the indentation. You don't have an "endif", "endwhile", "endfor" (so, why having an "end comment"?). -- Jorge Godoy <[EMAIL PROTECTED]> "Quidquid latine dictum sit, altum sonatur." - Qualquer coisa dita em latim soa profundo. - Anything said in Latin sounds smart. -- http://mail.python.org/mailman/listinfo/python-list
Re: multiline comments
"Jorge Godoy" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > rx wrote: > >> I have commented out a lot of C++ code and miss the block feature in >> python more than I missed the nested comments in C++. >> Besides nothing really strange happened. >> Sometimes you just need to dissable some of the code temporarly as >> quickly >> as possible, and I like that it is not higlighted any more, since I will >> not look into it before I dissable the comment. > > This is how I do it: select the lines I want to comment and ask Emacs to > comment that region. It is the same command and method for "n" different > languages and I don't care if there is multiline comment support or not. > It is really as fast as inserting /* and ending with */ (in fact, I type > less than to achieve that since I only use three keys, counting the > Ctrl-Space to start the block). It would be much nicer to have it in the language since there are many editors and many ways to do what you do (it would also make it more easy to make a editor). Besides it could be done with two keys if that really important - but I doubt it. But in a way you are also right if you use more than a few languages in the same editor, but then again the editor would still be able to do the commenting if you prefered that. I don't understand the problem - why should comments (and I hope you believe there should be a one line comment at least) be restricted to one line. It doesn't work that way for if, while, for. -- http://mail.python.org/mailman/listinfo/python-list
Re: multiline comments
rx wrote: > > "Jorge Godoy" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] >> Edward Elliott wrote: >> > >> >> You can use either """ or '''. I don't keep changing them in my code, so >> I >> can always use the other type (usually I use " so for commenting things >> out >> I'd use ') to do that. >> > > Try that on this code: > > a=3 > a=a*a > b='''This is a > very long > long > text''' > print a > > > like: > > a=3 > ''' > a=a*a > b='''This is a > very long > long > text''' > ''' > print a > > > > raises SyntaxError Of course! You should have used """ since you already used ''' in your triple-quoted text. But I'm just repeating what I already said (and kept above so that you can see it again). -- Jorge Godoy <[EMAIL PROTECTED]> "Quidquid latine dictum sit, altum sonatur." - Qualquer coisa dita em latim soa profundo. - Anything said in Latin sounds smart. -- http://mail.python.org/mailman/listinfo/python-list
Re: multiline comments
rx wrote: > I have commented out a lot of C++ code and miss the block feature in > python more than I missed the nested comments in C++. > Besides nothing really strange happened. > Sometimes you just need to dissable some of the code temporarly as quickly > as possible, and I like that it is not higlighted any more, since I will > not look into it before I dissable the comment. This is how I do it: select the lines I want to comment and ask Emacs to comment that region. It is the same command and method for "n" different languages and I don't care if there is multiline comment support or not. It is really as fast as inserting /* and ending with */ (in fact, I type less than to achieve that since I only use three keys, counting the Ctrl-Space to start the block). -- Jorge Godoy <[EMAIL PROTECTED]> "Quidquid latine dictum sit, altum sonatur." - Qualquer coisa dita em latim soa profundo. - Anything said in Latin sounds smart. -- http://mail.python.org/mailman/listinfo/python-list
Re: multiline comments
Jorge Godoy wrote: > You can use either """ or '''. I don't keep changing them in my code, so I > can always use the other type (usually I use " so for commenting things out > I'd use ') to do that. It's close, only problem is it doesn't nest. It'll have to be good enough for now. >>Forcing programmers to write clean code with syntax is like teaching a pig >>to sing: it wastes your time and annoys the pig. Good coding is a state >>of mind, not a parser option. > > If the latter can help, why not? Because in this case it limits the expressive power of the language. Multiline comments enable clearer communication of intent (see earlier post for some reasons why). -- http://mail.python.org/mailman/listinfo/python-list
Re: multiline comments
Peter Tillotson wrote: > discouraged except where vital. Perhaps we should make them really hard > and elegant - mandate latex/mathml markup so good editors can display > the equations we are implementing :-) I like this guy already! :) -- http://mail.python.org/mailman/listinfo/python-list
Re: multiline comments
> > Also, if you remove the start of the block first, then your editor might > not > be highlighting anymore... With nested comments things get even worse > because you might miss the end of the outer block or something like that. > > -- > Jorge Godoy <[EMAIL PROTECTED]> > I have commented out a lot of C++ code and miss the block feature in python more than I missed the nested comments in C++. Besides nothing really strange happened. Sometimes you just need to dissable some of the code temporarly as quickly as possible, and I like that it is not higlighted any more, since I will not look into it before I dissable the comment. -- http://mail.python.org/mailman/listinfo/python-list
Re: multiline comments
Jorge Godoy wrote: > Edward Elliott wrote: > Try using Subversion. You can work and make diffs disconnected from the > network. rcs isn't the issue. I'm already assuming a local store, a networked one just makes my argument even easier. >>I'm not saying nested comments solve every problem, just that > > I don't miss them. :-) Fair enough. > Well, I believe they are since it looks like a habit of yours to use > multiline comments. It is common for people coming from other programming > languages that support them. Yes I cut my teeth on C, C++, and Java. That was a long time ago. I don't miss them because they're more C-like (the C-family actually has an awful implementation), I miss them because they're useful. Actually I never used multiline much until I did a project in ML and saw how they should work. However the last 4 years I've used Perl, Python, and PHP almost exclusively. I'm used to single-line comments, I just find their expressive power lacking. No shame in borrowing the best features of other languages. -- http://mail.python.org/mailman/listinfo/python-list
Re: multiline comments
Sion Arrowsmith wrote: > Jorge Godoy <[EMAIL PROTECTED]> wrote: >>Is it harder to remove "n" lines of code commented out with "#" than "n" >>lines of multiline commented code? How? > > I'd say it's harder to remove the latter, due to having to search for > the end of comment sequence, rather than simply looking for where the > block comment stops. Like I said, it's debatable. Depends on the editing conditions you assume. It's easy to imagine situations where either type comes out ahead. -- http://mail.python.org/mailman/listinfo/python-list
Re: multiline comments
"Jorge Godoy" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Edward Elliott wrote: > > > You can use either """ or '''. I don't keep changing them in my code, so > I > can always use the other type (usually I use " so for commenting things > out > I'd use ') to do that. > Try that on this code: a=3 a=a*a b='''This is a very long long text''' print a like: a=3 ''' a=a*a b='''This is a very long long text''' ''' print a raises SyntaxError -- http://mail.python.org/mailman/listinfo/python-list
Re: multiline comments
Sion Arrowsmith wrote: > Really? Under what circumstances is it easier to see what's going on > with start/end comments than with comment-to-end-of-line? Off the top of my head: 1. The code is usually easier to read as # can obscure the first token on the line. This can be alleviated by leaving a space after the # or coloring the # differently. 2. It's easier to see where a nested comment begins and ends. Instead of counting #s at the beginning of lines, just find the matching closer. This is fairly simple to automate in a good editor. Counting #s can be automated as well, but fails if the programmer gets lazy and doesn't add extra #s when nesting, i.e. turns this: line 1 #line 2 line 3 into this #line 1 #line 2 #line 3 instead of this #line 1 ##line 2 #line 3 3. Preserves history better. Say I have consecutive lines commented out. With #s, all you see is this: #line 1 #line 2 #line 3 #line 4 If they were commented out in two chunks at different times, multiline comments can preserve that information: (* line 1 line 2 *) (* line 3 line 4 *) This isn't meant to be an exhaustive list. There are ways to address all these things with single-line comments, but it takes more work. Economy of expression favors nested comments in my book. Gregor has a good point about grep, but C-based languages with /**/ suffer the same problem. I think the answer is smarter searches, not dumber comments. -- http://mail.python.org/mailman/listinfo/python-list
Re: multiline comments
"Edward Elliott" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Ben Finney wrote: >> Indeed. Using revision control means never needing to comment out >> blocks of code. > > Typing (* and *) on a few line will always be quicker, easier, and less > confusing than any rcs diffs/restores. Once you delete the code you can > no longer see it or add pieces back in without retrieving it from an > external store. I'm not saying nested comments solve every problem, just > that there exists a certain (perhaps small) class of problems they solve > particularly well. > > Personally, I rarely leave code commented out beyond a single coding > session. But my particular coding habits aren't relevant here. Well I perfectly agree, and why make a dependence on external tools (IDE/CVS) if you can build it into the language with no conflicts by using some strange ascii combinations. I'm sure something like: a() (# b() c() #) d() would be fine. -- http://mail.python.org/mailman/listinfo/python-list
Re: multiline comments
Sion Arrowsmith wrote: > I'd say it's harder to remove the latter, due to having to search for > the end of comment sequence, rather than simply looking for where the > block comment stops. And you've extra problems if you allow nested > comments, because then you'll have to count how deep you've gone. Of > course, if you can completely trust your editor's syntax highlighter > you might be OK, but wasn't part of the point of this argument about > not *requiring* smart editors to be productive? Also, if you remove the start of the block first, then your editor might not be highlighting anymore... With nested comments things get even worse because you might miss the end of the outer block or something like that. -- Jorge Godoy <[EMAIL PROTECTED]> "Quidquid latine dictum sit, altum sonatur." - Qualquer coisa dita em latim soa profundo. - Anything said in Latin sounds smart. -- http://mail.python.org/mailman/listinfo/python-list
Re: multiline comments
Jorge Godoy <[EMAIL PROTECTED]> wrote: >Is it harder to remove "n" lines of code commented out with "#" than "n" >lines of multiline commented code? How? I'd say it's harder to remove the latter, due to having to search for the end of comment sequence, rather than simply looking for where the block comment stops. And you've extra problems if you allow nested comments, because then you'll have to count how deep you've gone. Of course, if you can completely trust your editor's syntax highlighter you might be OK, but wasn't part of the point of this argument about not *requiring* smart editors to be productive? -- \S -- [EMAIL PROTECTED] -- http://www.chaos.org.uk/~sion/ ___ | "Frankly I have no feelings towards penguins one way or the other" \X/ |-- Arthur C. Clarke her nu becomeþ se bera eadward ofdun hlæddre heafdes bæce bump bump bump -- http://mail.python.org/mailman/listinfo/python-list
Re: multiline comments
Edward Elliott <[EMAIL PROTECTED]> wrote: >On top of that, the expressive power of nested comments seems greater than >an endless string of ^#s. Sometimes it's just easier to see what's going on. Really? Under what circumstances is it easier to see what's going on with start/end comments than with comment-to-end-of-line? -- \S -- [EMAIL PROTECTED] -- http://www.chaos.org.uk/~sion/ ___ | "Frankly I have no feelings towards penguins one way or the other" \X/ |-- Arthur C. Clarke her nu becomeþ se bera eadward ofdun hlæddre heafdes bæce bump bump bump -- http://mail.python.org/mailman/listinfo/python-list
Re: multiline comments
nice one Jorge :-) Jorge Godoy wrote: > Peter Tillotson wrote: > >> I'm not sure I agree, revision control is great but not the only answer. >> In multi-developer teams working on the trunk, it its kind of >> inconvenient if someone checks in broken code. It also blocks critical > > This is something that should be a policy: no untested and working code > should be commited to the trunk; if you need to commit it for any reason > create a branch and do it there. typo committing broken code to trunk should punishable by stocks at least -- perhaps a public flogging. Though on a serious note, you need a good reason for creating arbitrary branches and a clearly defined naming policy. You also need to remember to get off the branch asap before you inadvertently start a major fork. >> path development if the person responsible for the code you conflict >> with happens to be out on holiday. Block commenting is a clear flag to > > Here I believe that no code revision system is a substitute for project. If > you have two conflicting changes on the same line of code, then you surely > are missing some discussion on the code and more documentation on what is > being done / has been done. Revision management is no substitute for > meetings and projects. > >> that developer that something has changed - ideally he'd notice, see >> sensible revision control comments, see the flag on the wiki or you >> would remember to tell him. But if all of that fails, if it is commented >> in the code it should get picked up at a code review. > > I believe that it is easier to see multiple commented out lines than just > the beginning and ending of a multiline comment. Specially when you're > screening the code instead of reading it line by line. > >> Personally, I prefer clear code, minimally commented with good high >> level descriptions of particularly complex section / algorithms. The > > We have the same taste, except that I prefer documenting more things than > just complex algorithms so I have a lot of comments and docstrings in my > code. >> later doesn't always fit neatly on one line. There is an argument that >> these should go into their own functions and be commented at the >> function level. Again I'm not sure I agree entirely - function comments >> that are auto extracted to create api docs (sorry Java background :-)) >> need only outline What a function does. There is a place for multiline >> comments to describe How that is achieved. > > I still believe that you're working with an inappropriate environment if > your editor can't use some extension for the language you choose (coming > from a Java background you might like PyDev on Eclipse, even though its > indentation features aren't as nice as Emacs' features...) or being able to > repeat the comment symbol from one line to the next when it wraps (keeping > indentation, of course!) Sadly i don't get to code at the coalface much recently. I've tinkered in python with pydev and vi over the last couple of years - i just really dislike coding on a white background. I'm sure eclipse can do it - i'm just not sure i've got the perseverance to work out how. >> Having said all that, I generally don't like comments, they are often >> maintained poorly, too numerous, too verbose (red rag :-)) - so i'm >> undecided whether they should be made easier for developers or >> discouraged except where vital. Perhaps we should make them really hard >> and elegant - mandate latex/mathml markup so good editors can display >> the equations we are implementing :-) > > :-) There's an approach that allows using those... I don't remember which > docsystem allows for MathML markup. But then, I'd go with DocBook + MathML > + SVG ;-) (Hey! You started! And you even said that you didn't like > verbose comments... ;-)) > oooh - but surely a picture is worth a thousand words and with SVG no truer word was spoken :-) I was only half kidding about latex. I can just about read pure latex but that human readable xml stuff always defeats me -- http://mail.python.org/mailman/listinfo/python-list
Re: multiline comments
Edward Elliott wrote: > And when the section I want to comment out contains a legit doc string in > the middle, triple-quotes won't work. There are valid reasons to nest You can use either """ or '''. I don't keep changing them in my code, so I can always use the other type (usually I use " so for commenting things out I'd use ') to do that. > comments which have nothing to do with laziness or sloppy code. > > Forcing programmers to write clean code with syntax is like teaching a pig > to sing: it wastes your time and annoys the pig. Good coding is a state > of mind, not a parser option. If the latter can help, why not? -- Jorge Godoy <[EMAIL PROTECTED]> "Quidquid latine dictum sit, altum sonatur." - Qualquer coisa dita em latim soa profundo. - Anything said in Latin sounds smart. -- http://mail.python.org/mailman/listinfo/python-list
Re: multiline comments
Peter Tillotson wrote: > I'm not sure I agree, revision control is great but not the only answer. > In multi-developer teams working on the trunk, it its kind of > inconvenient if someone checks in broken code. It also blocks critical This is something that should be a policy: no untested and working code should be commited to the trunk; if you need to commit it for any reason create a branch and do it there. > path development if the person responsible for the code you conflict > with happens to be out on holiday. Block commenting is a clear flag to Here I believe that no code revision system is a substitute for project. If you have two conflicting changes on the same line of code, then you surely are missing some discussion on the code and more documentation on what is being done / has been done. Revision management is no substitute for meetings and projects. > that developer that something has changed - ideally he'd notice, see > sensible revision control comments, see the flag on the wiki or you > would remember to tell him. But if all of that fails, if it is commented > in the code it should get picked up at a code review. I believe that it is easier to see multiple commented out lines than just the beginning and ending of a multiline comment. Specially when you're screening the code instead of reading it line by line. > Personally, I prefer clear code, minimally commented with good high > level descriptions of particularly complex section / algorithms. The We have the same taste, except that I prefer documenting more things than just complex algorithms so I have a lot of comments and docstrings in my code. > later doesn't always fit neatly on one line. There is an argument that > these should go into their own functions and be commented at the > function level. Again I'm not sure I agree entirely - function comments > that are auto extracted to create api docs (sorry Java background :-)) > need only outline What a function does. There is a place for multiline > comments to describe How that is achieved. I still believe that you're working with an inappropriate environment if your editor can't use some extension for the language you choose (coming from a Java background you might like PyDev on Eclipse, even though its indentation features aren't as nice as Emacs' features...) or being able to repeat the comment symbol from one line to the next when it wraps (keeping indentation, of course!) > Having said all that, I generally don't like comments, they are often > maintained poorly, too numerous, too verbose (red rag :-)) - so i'm > undecided whether they should be made easier for developers or > discouraged except where vital. Perhaps we should make them really hard > and elegant - mandate latex/mathml markup so good editors can display > the equations we are implementing :-) :-) There's an approach that allows using those... I don't remember which docsystem allows for MathML markup. But then, I'd go with DocBook + MathML + SVG ;-) (Hey! You started! And you even said that you didn't like verbose comments... ;-)) -- Jorge Godoy <[EMAIL PROTECTED]> "Quidquid latine dictum sit, altum sonatur." - Qualquer coisa dita em latim soa profundo. - Anything said in Latin sounds smart. -- http://mail.python.org/mailman/listinfo/python-list
Re: multiline comments
Edward Elliott wrote: > Sure they can be abused. So can a thousand other language features. My > point is you can't teach good coding through syntax, and trying to causes > more problems than it solves. I like the phrase: there are some languages that incentivates bad practices in programming; there is Python that doesn't. Some rigid syntax indeed makes you think one way -- and that's one of Python's motto, isn't it? "There's one right way to do it" -- but that will make your code more understandable and readable in the future. > I would argue the current system is in fact slightly worse, because people > will comment out code chunks anyway (either lots of #s or triple-quotes) > and are less likely to remove them when it's more work. But either way, > social pressure is infinitely more effective at cleaning up code than > comment syntax. Is it harder to remove "n" lines of code commented out with "#" than "n" lines of multiline commented code? How? The same question goes for triple quoted code. -- Jorge Godoy <[EMAIL PROTECTED]> "Quidquid latine dictum sit, altum sonatur." - Qualquer coisa dita em latim soa profundo. - Anything said in Latin sounds smart. -- http://mail.python.org/mailman/listinfo/python-list
Re: multiline comments
Edward Elliott wrote: > Typing (* and *) on a few line will always be quicker, easier, and less > confusing than any rcs diffs/restores. Once you delete the code you can > no longer see it or add pieces back in without retrieving it from an > external store. Try using Subversion. You can work and make diffs disconnected from the network. You can't, of course, commit / update but you can work with it and have what you need to compare original code (i.e. the one from the last commit) to new code and go back to original code if needed. > I'm not saying nested comments solve every problem, just that > there exists a certain (perhaps small) class of problems they solve > particularly well. I don't miss them. :-) > Personally, I rarely leave code commented out beyond a single coding > session. But my particular coding habits aren't relevant here. Well, I believe they are since it looks like a habit of yours to use multiline comments. It is common for people coming from other programming languages that support them. -- Jorge Godoy <[EMAIL PROTECTED]> "Quidquid latine dictum sit, altum sonatur." - Qualquer coisa dita em latim soa profundo. - Anything said in Latin sounds smart. -- http://mail.python.org/mailman/listinfo/python-list
Re: multiline comments
Ben Finney wrote: > "Atanas Banov" <[EMAIL PROTECTED]> writes: > >> Edward Elliott wrote: >>> Saying coders shouldn't use multiline comments to disable code >>> misses the point. Coders will comment out code regardless of the >>> existence of multiline comemnts. There has to be a better >>> argument for leaving them out. >> i beg to differ: you'd be surprised how much effect can little >> inconveniences have. >> >> want to comment block of code? use tripple-quotes. does not nest? >> ahhh, maybe it's time to get rid of that block you commented out a >> month ago "just in case the new code doesnt work". > > Indeed. Using revision control means never needing to comment out > blocks of code. > > If your revision control system is so inconvenient to use that you'd > rather have large blocks of commented-out code, it's time to start > using a better RCS -- perhaps a distributed one, so you can commit to > your own local repository with abandon while trying out changes. > I'm not sure I agree, revision control is great but not the only answer. In multi-developer teams working on the trunk, it its kind of inconvenient if someone checks in broken code. It also blocks critical path development if the person responsible for the code you conflict with happens to be out on holiday. Block commenting is a clear flag to that developer that something has changed - ideally he'd notice, see sensible revision control comments, see the flag on the wiki or you would remember to tell him. But if all of that fails, if it is commented in the code it should get picked up at a code review. Personally, I prefer clear code, minimally commented with good high level descriptions of particularly complex section / algorithms. The later doesn't always fit neatly on one line. There is an argument that these should go into their own functions and be commented at the function level. Again I'm not sure I agree entirely - function comments that are auto extracted to create api docs (sorry Java background :-)) need only outline What a function does. There is a place for multiline comments to describe How that is achieved. Having said all that, I generally don't like comments, they are often maintained poorly, too numerous, too verbose (red rag :-)) - so i'm undecided whether they should be made easier for developers or discouraged except where vital. Perhaps we should make them really hard and elegant - mandate latex/mathml markup so good editors can display the equations we are implementing :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: multiline comments
Edward Elliott schrieb: > On top of that, the expressive power of nested comments seems greater > than an endless string of ^#s. Sometimes it's just easier to see what's > going on. not if you are using grep -- Gregor http://www.gregor-horvath.com -- http://mail.python.org/mailman/listinfo/python-list
Re: multiline comments
Duncan Booth wrote: > Want to comment out a block of code in C++? The only (nearly) reliable way > is to insert single-line comments down the block. You can't use a block > comment if there are any other block comments inside the code you want to > block out. As Roel said, #if 0 is the standard way. It abuses the preprocessor and doesn't show up in syntax highlighting, but other than that works very well. Honestly though, /* and */ should have nested properly since day 1. Adding it wouldn't even break existing code. > The danger of block comments is that if you forget to close the comment > you can accidentally comment out a large part of your code. No, unclosed comments should raise a syntax error. Would you accept an unclosed string literal? > Doc strings will usually work as an alternative, especially since you > have a choice of two flavours of triple quoted strings, so if you use > one for docstrings the other is always free for your temporary block > comments. That's a fair point, if a bit of a kludge. 90% there is good enough in practice. > This pig gets much more annoyed having to maintain code which has large > chunks of unneeded commented out code left over from some other programmer, > or which has completely messed up indentation. Sure they can be abused. So can a thousand other language features. My point is you can't teach good coding through syntax, and trying to causes more problems than it solves. I would argue the current system is in fact slightly worse, because people will comment out code chunks anyway (either lots of #s or triple-quotes) and are less likely to remove them when it's more work. But either way, social pressure is infinitely more effective at cleaning up code than comment syntax. -- http://mail.python.org/mailman/listinfo/python-list
Re: multiline comments
Duncan Booth schreef: > Would you care to name a few languages which support nested block > comments? There really aren't many: ML as you mentioned; Standard Pascal > doesn't permit nesting of comments but *some* implementations do allow it. > > Want to comment out a block of code in C++? The only (nearly) reliable way > is to insert single-line comments down the block. You can't use a block > comment if there are any other block comments inside the code you want to > block out. Depends, some compilers support that. But the preferred way, which works very well, is to use preprocessor directives: #if 0 ... #endif Works in both C and C++. -- If I have been able to see further, it was only because I stood on the shoulders of giants. -- Isaac Newton Roel Schroeven -- http://mail.python.org/mailman/listinfo/python-list
Re: multiline comments
Edward Elliott wrote: > Ben Finney wrote: >> Indeed. Using revision control means never needing to comment out >> blocks of code. > > Typing (* and *) on a few line will always be quicker, easier, and > less confusing than any rcs diffs/restores. Once you delete the code > you can no longer see it or add pieces back in without retrieving it > from an external store. I'm not saying nested comments solve every > problem, just that there exists a certain (perhaps small) class of > problems they solve particularly well. Would you care to name a few languages which support nested block comments? There really aren't many: ML as you mentioned; Standard Pascal doesn't permit nesting of comments but *some* implementations do allow it. Want to comment out a block of code in C++? The only (nearly) reliable way is to insert single-line comments down the block. You can't use a block comment if there are any other block comments inside the code you want to block out. The danger of block comments is that if you forget to close the comment you can accidentally comment out a large part of your code. With support from the editor (coloured highlighting of comments) this isn't so bad, but then if you have a decent editor you don't need the block comments anyway as you will be able to comment/uncomment a block in your editor. Doc strings will usually work as an alternative, especially since you have a choice of two flavours of triple quoted strings, so if you use one for docstrings the other is always free for your temporary block comments. > Forcing programmers to write clean code with syntax is like teaching a > pig to sing: it wastes your time and annoys the pig. This pig gets much more annoyed having to maintain code which has large chunks of unneeded commented out code left over from some other programmer, or which has completely messed up indentation. -- http://mail.python.org/mailman/listinfo/python-list
Re: multiline comments
In article <[EMAIL PROTECTED]>, Edward Elliott <[EMAIL PROTECTED]> wrote: >ML has a >very elegant system for nested comments with (* and *). Which, if you mistype an opening or closing comment symbol, can lead to some very mysterious syntax errors. -- http://mail.python.org/mailman/listinfo/python-list
Re: multiline comments
Ben Finney wrote: > Indeed. Using revision control means never needing to comment out > blocks of code. Typing (* and *) on a few line will always be quicker, easier, and less confusing than any rcs diffs/restores. Once you delete the code you can no longer see it or add pieces back in without retrieving it from an external store. I'm not saying nested comments solve every problem, just that there exists a certain (perhaps small) class of problems they solve particularly well. Personally, I rarely leave code commented out beyond a single coding session. But my particular coding habits aren't relevant here. -- http://mail.python.org/mailman/listinfo/python-list
Re: multiline comments
Ben Finney wrote: > And/or switch to an editor that can perform editing operations on a > range of lines. I'm not unsympathetic to this point of view, as I would feel hamstrung without my vim. It's more that I object to the paternalism of telling people they have to use such an editor. There are times when notepad is all that's available. On top of that, the expressive power of nested comments seems greater than an endless string of ^#s. Sometimes it's just easier to see what's going on. -- http://mail.python.org/mailman/listinfo/python-list
Re: multiline comments
Atanas Banov wrote: > want to comment block of code? use tripple-quotes. does not nest? ahhh, > maybe it's time to get rid of that block you commented out a month ago > "just in case the new code doesnt work". > > that gives you incentive to tidy up. don't be a code slob... don't > leave a mess forever ;-) And when the section I want to comment out contains a legit doc string in the middle, triple-quotes won't work. There are valid reasons to nest comments which have nothing to do with laziness or sloppy code. Forcing programmers to write clean code with syntax is like teaching a pig to sing: it wastes your time and annoys the pig. Good coding is a state of mind, not a parser option. -- http://mail.python.org/mailman/listinfo/python-list
Re: multiline comments
"Atanas Banov" <[EMAIL PROTECTED]> writes: > Edward Elliott wrote: > > Saying coders shouldn't use multiline comments to disable code > > misses the point. Coders will comment out code regardless of the > > existence of multiline comemnts. There has to be a better > > argument for leaving them out. > > i beg to differ: you'd be surprised how much effect can little > inconveniences have. > > want to comment block of code? use tripple-quotes. does not nest? > ahhh, maybe it's time to get rid of that block you commented out a > month ago "just in case the new code doesnt work". Indeed. Using revision control means never needing to comment out blocks of code. If your revision control system is so inconvenient to use that you'd rather have large blocks of commented-out code, it's time to start using a better RCS -- perhaps a distributed one, so you can commit to your own local repository with abandon while trying out changes. -- \"I saw a sign: 'Rest Area 25 Miles'. That's pretty big. Some | `\ people must be really tired." -- Steven Wright | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: multiline comments
Edward Elliott wrote: > At the risk of flogging a dead horse, I'm wondering why Python doesn't have > any multiline comments. One can abuse triple-quotes for that purpose, but > that's obviously not what it's for and doesn't nest properly. ... > Saying coders shouldn't use multiline comments to disable code misses the > point. Coders will comment out code regardless of the existence of > multiline comemnts. There has to be a better argument for leaving them out. i beg to differ: you'd be surprised how much effect can little inconveniences have. want to comment block of code? use tripple-quotes. does not nest? ahhh, maybe it's time to get rid of that block you commented out a month ago "just in case the new code doesnt work". that gives you incentive to tidy up. don't be a code slob... don't leave a mess forever ;-) -- http://mail.python.org/mailman/listinfo/python-list
Re: multiline comments
James Stroud <[EMAIL PROTECTED]> writes: > Edward Elliott wrote: > > At the risk of flogging a dead horse, I'm wondering why Python > > doesn't have any multiline comments. [...] > > > > Using an editor to throw #s in front of every line has > > limitations. Your editor has to support it and you have to know > > how to use that feature. Not exactly intuitive or easy for > > novices to pick up. Also a pain if your preferred editor is > > python/perl/sh-agnostic. > > I think the absence of multiline comments is like the requirement > for indentation. It enforces good habits. Better is to make your > multiple lines a function and comment out the function call. And/or switch to an editor that can perform editing operations on a range of lines. -- \ Q: "I've heard that Linux causes cancer..." Torvalds: "That's | `\ a filthy lie. Besides, it was only in rats and has not been | _o__)reproduced in humans." -- Linus Torvalds | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: multiline comments
Edward Elliott wrote: > At the risk of flogging a dead horse, I'm wondering why Python doesn't > have any multiline comments. One can abuse triple-quotes for that > purpose, but that's obviously not what it's for and doesn't nest > properly. ML has a very elegant system for nested comments with (* and *). > > Using an editor to throw #s in front of every line has limitations. > Your editor has to support it and you have to know how to use that > feature. Not exactly intuitive or easy for novices to pick up. Also a > pain if your preferred editor is python/perl/sh-agnostic. > > Saying coders shouldn't use multiline comments to disable code misses > the point. Coders will comment out code regardless of the existence of > multiline comemnts. There has to be a better argument for leaving them > out. > > Keeping the language small and simple is desirable, but it's not an > absolute. A little syntactic sugar like 'for x in s' makes code easier > to read than 'for i in len(s): x = s[i]'. So what are the tradeoffs > involved with nested multiline comments? I'd like to understand the > reasoning behind keeping them out. I think the absence of multiline comments is like the requirement for indentation. It enforces good habits. Better is to make your multiple lines a function and comment out the function call. James -- James Stroud UCLA-DOE Institute for Genomics and Proteomics Box 951570 Los Angeles, CA 90095 http://www.jamesstroud.com/ -- http://mail.python.org/mailman/listinfo/python-list
multiline comments
At the risk of flogging a dead horse, I'm wondering why Python doesn't have any multiline comments. One can abuse triple-quotes for that purpose, but that's obviously not what it's for and doesn't nest properly. ML has a very elegant system for nested comments with (* and *). Using an editor to throw #s in front of every line has limitations. Your editor has to support it and you have to know how to use that feature. Not exactly intuitive or easy for novices to pick up. Also a pain if your preferred editor is python/perl/sh-agnostic. Saying coders shouldn't use multiline comments to disable code misses the point. Coders will comment out code regardless of the existence of multiline comemnts. There has to be a better argument for leaving them out. Keeping the language small and simple is desirable, but it's not an absolute. A little syntactic sugar like 'for x in s' makes code easier to read than 'for i in len(s): x = s[i]'. So what are the tradeoffs involved with nested multiline comments? I'd like to understand the reasoning behind keeping them out. -- http://mail.python.org/mailman/listinfo/python-list
Re: Case Sensitive, Multiline Comments
> > > You haven't looked very well though: there are actually quite a lot > > > of extra spaces. Still, it's nicely done indeed. > > Hmm. I only saw doubled spaces after commas and periods. > Doubled spaces after commas are definitely not standard usage. I guess the fact that *all* comments on my post only referred to my formatting, tell us something about how distracted we can get by purely "typographic" aspects of text. I think that might strengthen my case. Text that visually looks different than we are used to, distracts us from the content. Another interpretation would be that the content of my previous post was a bit thin, since I was to caught up with form... I guess that *also* suggests that we should use standard Python formatting and concentrate on content... Of course, if you're used to typing If in other languages, Python might initially feel annoying, just as C++ feels stupid when it forces me to put a silly ; in the end of each line. On the other hand, there are other things beyond syntactic details that differ more between languages, and it's pretty easy to get used to Python. I think the thing that bothered me most initially was the differnt shape of the code, since there were no explicit block end markers in Python. I was really used to code looking like this: xxx xx xxx xxx xxx xx xx And now it looked: xxx xxx xxx xxx It somehow felt very abrupt, and I missed the visual cues that we were going back to a previous block level. After some time I got used to it, and I very rarely hear anyone contest that code written in Python usually is easier to read than code written in other languages. The lack of block end markers, is one of several Python features that promote clarity and a high signal/ noise ratio in the source code. -- http://mail.python.org/mailman/listinfo/python-list
Re: Case Sensitive, Multiline Comments
Benji York wrote: > Roel Schroeven wrote: > > You haven't looked very well though: there are actually quite a lot > > of extra spaces. Still, it's nicely done indeed. > > Hmm. I only saw doubled spaces after commas and periods. That's > fairly standard practice, for the periods at least. I don't know > if people regularly put two spaces after commas though. I know I > don't. I did spot a couple of extra quotation marks, but I guess > I can give him those. :) Doubled spaces after commas are definitely not standard usage. Doubled spaces after periods are fairly common (a holdover from fixed-pitch typewriters, as I recall, where the period itself takes up a full character width and so needs doubled space after it to make the sentence breaks more noticeable). Inconsistent use of doubled spaces after periods, however, is a sign of a smart justification algorithm. -Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Case Sensitive, Multiline Comments
Roel Schroeven wrote: > You haven't looked very well though: there are actually quite a lot > of extra spaces. Still, it's nicely done indeed. Hmm. I only saw doubled spaces after commas and periods. That's fairly standard practice, for the periods at least. I don't know if people regularly put two spaces after commas though. I know I don't. I did spot a couple of extra quotation marks, but I guess I can give him those. :) -- Benji York -- http://mail.python.org/mailman/listinfo/python-list
Re: Case Sensitive, Multiline Comments
On Mon, 30 May 2005 14:24:54 -0400, "Terry Reedy" <[EMAIL PROTECTED]>
wrote:
>
>"D H" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
>> Elliot Temple wrote:
>>> Hi I have two questions. Could someone explain to me why Python is
>>> case sensitive? I find that annoying.
>>
>> I do too.
>
>I don't.
>
>> As you've found, the only reason is because it is,
>
>False. As someone else already pointed out in this thread, and as some
>said years ago when Guido brought up the subject, standard math notation
>*is* case sensitive and some people like Python because they can directly
>translate math expressions into Python expressions.
False.
In the sense that it is the way it is only because Guido kept it the
way it is, but he did so without acknowledging that your argument or
anyone else's argument was in the least bit pursuasive to him.
>I am annoyed by the disinformation and slander ('anti-newbie') repeated
>indefinitely by some case-folding advocates. Difference annoyances for
>different folks, I guess.
I am annoyed that Guido skated while those of us vocally annoyed that
Guido could be influenced into this substanceless "newbie" issue, and
influence so many others to contemplate it with such solemnity - did
not skate as well.
Art
--
http://mail.python.org/mailman/listinfo/python-list
Re: Case Sensitive, Multiline Comments
On Mon, 30 May 2005 20:56:22 +, Roel Schroeven wrote: > You haven't looked very well though: there are actually quite a lot of > extra spaces. Still, it's nicely done indeed. C-u M-q ? -- http://mail.python.org/mailman/listinfo/python-list
Re: Case Sensitive, Multiline Comments
Benji York wrote: > What I want to know is how Mangus wrote an entire message fully > justified. I looked for extra spaces and other cheats but only > found a couple of superfluous exclamation marks. Well done! He > must be a justification wizard. I wish I could do that too. :) I hadn't even seen it at first, since I use a proportional font for reading my mail. You haven't looked very well though: there are actually quite a lot of extra spaces. Still, it's nicely done indeed. -- If I have been able to see further, it was only because I stood on the shoulders of giants. -- Isaac Newton Roel Schroeven -- http://mail.python.org/mailman/listinfo/python-list
Re: Case Sensitive, Multiline Comments
What I want to know is how Mangus wrote an entire message fully justified. I looked for extra spaces and other cheats but only found a couple of superfluous exclamation marks. Well done! He must be a justification wizard. I wish I could do that too. :) -- Benji York -- http://mail.python.org/mailman/listinfo/python-list
Re: Case Sensitive, Multiline Comments
Terry Reedy wrote: > Difference annoyances for different folks, I guess. IN MY EXPERIENCE, MANY PEOPLE ON THE INTERNET ARE ANNOYED BY PEOPLE WHO DON'T USE CASE THE WAY THEY ARE EXPECTED. IT ALSO SEEMS TO ME THAT LOWER CASE TEXT IS OFTEN MORE EASY TO READ, AND ALSO THAT IT IS EASIER TO SCAN TEXTS IF CASE IS CONSISTENT. WE DO AFTER ALL SEE IMAGES ON THE SCREEN. EVEN IF WE RELATE "IF" WITH "if", THEY DON'T LOOK THE SAME. MY SON POINTED AT THE WORD "TOYOTA" IN A MAGAZINE AND EXCLAIMED "TOTOTA" WHEN HE WAS ONLY THREE. HE WAS CLEARLY TOO YOUNG TO READ, BUT HE RECOGNIZED THE IMAGE OF THE LOGO HE HAD SEEN ON OLD TOYOTAS. IN GENERAL, PYTHON "TRIES" TO FORCE A PARTICULAR STYLE OF CODING ON PROGRAMMERS. WE HAVE TO INDENT IN A PARTICULAR WAY. THE STYLE OF PROGRAMMING HAS BEEN CODIFIED IN PEP 008, AND COWBOY PROGRAMMING ISN'T REALLY APPRECIATED. YOU ARE NOT "SUPPOSED" TO PROGRAM PYTHON "YOUR WAY". YOU ARE SUPPOSED TO PROGRAM THE RIGHT WAY. IF YOU DON'T LIKE THAT, IT IS PROBABLY BETTER TO USE ANOTHER LANGUAGE. PERL IS MORE OF A COWBOY LANUGAGE. THE FUNNY THING IS THAT EVEN PERL IS CASE SENSITIVE! EXPLAIN THAT!!! IMO IT'S A STRENGTH OF PYTHON THAT PYTHON CODE IS ALWAYS CONSISTENT IN CASE. IT IS PROBABLY A MINOR FEATURE COMPARED TO THE BLOCK STRUCTURES ETC, BUT I THINK IT ADDS TO THE EASE OF READING CODE WHICH HAS BEEN WRITTEN BY OTHERS. I DO ALSO DISLIKE THE ALTERNATIVES. NEITHER CODE WITH INCONSISTENT USE OF CASE NOR THE STUPID "CASE CORRECTING" FEATURES IN E.G. THE VISUAL BASIC IDE SEEMS TO BE ANYTHING TO STRIVE FOR. IF YOU THOUGHT IT WAS ANNOYING TO READ THIS, THEN YOU CAN AT LEAST APPRECIATE THAT PYTHON CODE NEVER LOOKS LIKE SUCH A COMPACT BLOB! Who am I kidding with this? Everybody knows that case doesn't matter, right? The text below isn't a bit easier to read than the text above, right? In my experience, many people on the internet are annoyed by people who don't use case the way they are expected. It also seems to me that lower case text is often more easy to read, and also that it is easier to scan texts if case is consistent. We do after all see images on the screen. Even if we relate "IF" with "if", they don't look the same. My son pointed at the word "TOYOTA" in a magazine and exclaimed "Totota" when he was only three. He was clearly too young to read, but he recognized the image of the logo he had seen on old toyotas. In general, Python "tries" to force a particular style of coding on programmers. We have to indent in a particular way. The style of programming has been codified in PEP 008, and cowboy programming isn't really appreciated. You are not "supposed" to program Python "your way". You are supposed to program the right way. If you don't like that, it is probably better to use another language. Perl is more of a cowboy lanugage. The funny thing is that even Perl is case sensitive! Explain that!!! IMO it's a strength of Python that Python code is always consistent in case. It is probably a minor feature compared to the block structures etc, but I think it adds to the ease of reading code which has been written by others. I do also dislike the alternatives. Neither code with inconsistent use of case nor the stupid "case correcting" features in e.g. the Visual Basic IDE seems to be anything to strive for. If you thought it was annoying to read this, then you can at least appreciate that Python code never looks like such a compact blob! oF cOuRsE, wE sHoUlDn'T aSsUmE tHaT pEoPlE wIlL aBuSe ThE fReEdOm ThEy GeT, bUt I'm RaThEr SaFe ThAn SoRrY! ;^) I'm ReAlLy hApPy ThAt I'lL nEvEr HaVe To SeE aLl-CaPs PyThOn PrOgRaMs! -- http://mail.python.org/mailman/listinfo/python-list
Re: Case Sensitive, Multiline Comments
"D H" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
> Elliot Temple wrote:
>> Hi I have two questions. Could someone explain to me why Python is
>> case sensitive? I find that annoying.
>
> I do too.
I don't.
> As you've found, the only reason is because it is,
False. As someone else already pointed out in this thread, and as some
said years ago when Guido brought up the subject, standard math notation
*is* case sensitive and some people like Python because they can directly
translate math expressions into Python expressions.
I am annoyed by the disinformation and slander ('anti-newbie') repeated
indefinitely by some case-folding advocates. Difference annoyances for
different folks, I guess.
Terry J. Reedy
--
http://mail.python.org/mailman/listinfo/python-list
Re: Case Sensitive, Multiline Comments
Roy Smith wrote: > In article <[EMAIL PROTECTED]>, D H <[EMAIL PROTECTED]> wrote: > > >>Elliot Temple wrote: >> >>>Hi I have two questions. Could someone explain to me why Python is >>>case sensitive? I find that annoying. >> >>I do too. As you've found, the only reason is because it is, and it is >>too late to change (it was even too late back in 1999 when it was >>considered by Guido). I guess the most popular case-insensitive >>language nowadays is visual basic (and VB.NET). >> >> > Also, why aren't there >> >>>multiline comments? Would adding them cause a problem of some sort? >> >>Again, just because there aren't and never were. There is no technical >>reason (like for example a parsing conflict) why they wouldn't work in >>python. That's why most python editors have added a comment section >>command that prepends # to consecutive lines for you. > > > If it really bothers you that there's no multi-line comments, you could > always use triple-quoted strings. Where did I say that? > I actually don't like multi-line comments. They're really just syntactic > sugar, and when abused, they can make code very difficult to understand. > Just wait until the day you're trying to figure out why some C++ function > is behaving the way it is and you don't notice that a 50-line stretch of > code is commented out with /* at the top and */ at the bottom. Same with triple quotes, btw. -- http://mail.python.org/mailman/listinfo/python-list
Re: Case Sensitive, Multiline Comments
Roy Smith wrote: > Just wait until the day you're trying to figure out why some C++ function > is behaving the way it is and you don't notice that a 50-line stretch of > code is commented out with /* at the top and */ at the bottom. The same thing's happened to me in Python when I accidentally included a function's code in its docstring (don't ask me how I managed to do that -- I don't know). But my editor's syntax highlighting helped me to find the error very quickly. -- http://mail.python.org/mailman/listinfo/python-list
Re: Case Sensitive, Multiline Comments
On Thu, 26 May 2005 16:24:39 -0500, Mike Meyer <[EMAIL PROTECTED]> wrote: >"Elliot Temple" <[EMAIL PROTECTED]> writes: > >> Hi I have two questions. Could someone explain to me why Python is >> case sensitive? I find that annoying. > >Because it comes from a language background of case sensitive >languages (C, shell, etc.). But read what the BDFL has to say about >it: http://mail.python.org/pipermail/python-list/2001-July/054788.html > As Guido's statement on his position on case sensitivity/insensitivity cited above was in response to a post/provocation of mine, its gives me, and I shall indulge myself in, an opportunity to partake of a favorite pasttime - venting, I will make it short: It gauls the hell out of me that that the Python community mass "head" was in such a strange place at that moment that I had to take the pose of maniacal extremist to have a sensible converstaion. Or that's the history I am writing, in any case. Art -- http://mail.python.org/mailman/listinfo/python-list
Re: Case Sensitive, Multiline Comments
In article <[EMAIL PROTECTED]>, D H <[EMAIL PROTECTED]> wrote: > Elliot Temple wrote: > > Hi I have two questions. Could someone explain to me why Python is > > case sensitive? I find that annoying. > > I do too. As you've found, the only reason is because it is, and it is > too late to change (it was even too late back in 1999 when it was > considered by Guido). I guess the most popular case-insensitive > language nowadays is visual basic (and VB.NET). > > > Also, why aren't there > > multiline comments? Would adding them cause a problem of some sort? > > Again, just because there aren't and never were. There is no technical > reason (like for example a parsing conflict) why they wouldn't work in > python. That's why most python editors have added a comment section > command that prepends # to consecutive lines for you. If it really bothers you that there's no multi-line comments, you could always use triple-quoted strings. I actually don't like multi-line comments. They're really just syntactic sugar, and when abused, they can make code very difficult to understand. Just wait until the day you're trying to figure out why some C++ function is behaving the way it is and you don't notice that a 50-line stretch of code is commented out with /* at the top and */ at the bottom. -- http://mail.python.org/mailman/listinfo/python-list
Re: Case Sensitive, Multiline Comments
Elliot Temple wrote: > Hi I have two questions. Could someone explain to me why Python is > case sensitive? I find that annoying. I do too. As you've found, the only reason is because it is, and it is too late to change (it was even too late back in 1999 when it was considered by Guido). I guess the most popular case-insensitive language nowadays is visual basic (and VB.NET). > Also, why aren't there > multiline comments? Would adding them cause a problem of some sort? Again, just because there aren't and never were. There is no technical reason (like for example a parsing conflict) why they wouldn't work in python. That's why most python editors have added a comment section command that prepends # to consecutive lines for you. -- http://mail.python.org/mailman/listinfo/python-list
Re: Case Sensitive, Multiline Comments
On May 29, 2005, at 11:44 AM, Arthur wrote: > On 26 May 2005 17:33:33 -0700, "Elliot Temple" <[EMAIL PROTECTED]> > wrote: > > >> Thanks for the link on case sensitivity. I'm curious about the >> person >> who found case sensitivity useful though: what is it useful for? >> > > I am curious about why you find case sensitivity annoying. But just > mildly curious. I'm glad you asked ;-) Case insensitivity gives you more choice about how to type keywords that you have no control over. if or If. for or For. i don't think being inconsistent within a single program is a good idea, but having your choice of which to do is nice. I personally think all lowercase is good, but some languages have capitalised keywords, so apparently other people prefer that. I don't think the "case sensitivity hurts beginners" argument is persuasive. Anyone who seriously wants to program can look up the correct capitalisation of everything. *If* having to look up or keep track of capitalisation is annoying, *then* that argument applies to experienced programmers (who are devoting memory to the issue) just as much as beginners. -- Elliot Temple http://www.curi.us/ --- [This E-mail scanned for viruses by Declude Virus] -- http://mail.python.org/mailman/listinfo/python-list
Re: Case Sensitive, Multiline Comments
On 26 May 2005 17:33:33 -0700, "Elliot Temple" <[EMAIL PROTECTED]> wrote: >Thanks for the link on case sensitivity. I'm curious about the person >who found case sensitivity useful though: what is it useful for? I am curious about why you find case sensitivity annoying. But just mildly curious. Martelli can tell you why Guido keeping case sensitivity in Python was him bowing to the stupidity of the masses. I have been neutral on the subject except to the extent the impetous for going case insensitive would be to statisfy the needs - as Guido uses the word - "non-programmers". a) its probably better to design a programming language around the needs of programmers than around those of non-porgrammers. that much always seemed quite obvious to me. b) it would only help non-programmers who were more comfortable with case insensitivity but hurt non-progammers more comfortable with case sensitivity. That Martelli so strongly favors case insensitivity for his own use, is one of many indications that this is not an issue that cuts along the lines of quantity of programming experience.. That much also seemed pretty obvious, but it didn't seem to stop the folks who wanted case insensitivity from making the non-programmer accessibility issue paramount. and on the flimiest of evidence. Those who prefer sensitivity were anti-accessbility elitists. Damn near Republicans. Classic politics. Thankfully Guido seemed to have lost patience for the whole thing. I think the position is pretty much that Python will be case sensitive becasue it has been case sensitive. Art -- http://mail.python.org/mailman/listinfo/python-list
Re: Case Sensitive, Multiline Comments
Dennis Lee Bieber <[EMAIL PROTECTED]> writes: > On 26 May 2005 17:33:33 -0700, "Elliot Temple" <[EMAIL PROTECTED]> > declaimed the following in comp.lang.python: > >> Thanks for the link on case sensitivity. I'm curious about the person >> who found case sensitivity useful though: what is it useful for? >> > Making a language run faster on slow machines since the syntax > parsing doesn't have to do the equivalent of upper or lower casing > anything that is not a string literal before checking for keywords or > identifiers. > > Consider the time spent by languages like Ada and Fortran when > they have to do case normalization every time you compile. Hopefully, this should be minimal. You canonicalize them all as soon as you realize you can. With proper language design, this may be as soon as you recognize that they aren't in a string. This brings to mind the reason I quit using Microsoft products. I was writing z80 assembler, and habitually wrote everything in lower case, including all the op codes. The assembler refused to recognize the indexed instruction opcodes that were present on the z80 but not the 8080. I double-checked the op codes, did the "delete and retype" thing, and in general went crazy trying to figure out what was wrong. I eventually called Microsoft and asked. The answer was "Those have to be in upper case." That told me enough about the insides of MS software that I swore off it, and have never purchased an MS product since. http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Case Sensitive, Multiline Comments
John Roth wrote: > "Elliot Temple" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > >> One other interesting thing about case sensitivity I don't think >> anyone has mentioned: in Python keywords are all lowercase already >> (the way I want to type them). In some other languages, they aren't... > > Not quite. None, True and False are upper case. But those aren't keywords. (Well, None is a pseudo-keyword in Python 2.4, but...) -- http://mail.python.org/mailman/listinfo/python-list
Re: Case Sensitive, Multiline Comments
"Elliot Temple" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > One other interesting thing about case sensitivity I don't think anyone > has mentioned: in Python keywords are all lowercase already (the way I > want to type them). In some other languages, they aren't... Not quite. None, True and False are upper case. John Roth > > -- Elliot Temple > http://www.curi.us/ > > > --- > [This E-mail scanned for viruses by Declude Virus] > -- http://mail.python.org/mailman/listinfo/python-list
Re: Case Sensitive, Multiline Comments
One other interesting thing about case sensitivity I don't think anyone has mentioned: in Python keywords are all lowercase already (the way I want to type them). In some other languages, they aren't... -- Elliot Temple http://www.curi.us/ --- [This E-mail scanned for viruses by Declude Virus] -- http://mail.python.org/mailman/listinfo/python-list
Re: Case Sensitive, Multiline Comments
John Roth wrote: > Doing case translations in Unicode following all of > the rules for all of the world's languages is, for want of a better > world, a real bitch. > Fair point, although that is true for anything, not just case translations. Fortunately, unlike Ecmascript, Python doesn't allow arbitrary unicode characters in identifiers. -- http://mail.python.org/mailman/listinfo/python-list
Re: Case Sensitive, Multiline Comments
"Duncan Booth" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Dennis Lee Bieber wrote: > >> On 26 May 2005 17:33:33 -0700, "Elliot Temple" <[EMAIL PROTECTED]> >> declaimed the following in comp.lang.python: >> >>> Thanks for the link on case sensitivity. I'm curious about the person >>> who found case sensitivity useful though: what is it useful for? >>> >> Making a language run faster on slow machines since the syntax >> parsing doesn't have to do the equivalent of upper or lower casing >> anything that is not a string literal before checking for keywords or >> identifiers. >> >> Consider the time spent by languages like Ada and Fortran when >> they have to do case normalization every time you compile. >> > That isn't a good argument for case sensitivity. You really aren't going > to > be able to measure a slowdown in compilation speed just because the > compiler has to lowercase all the identifiers before using them. Actually it is, but you have to get out of ASCII into the wider world of all of the real languages out there. Something I heard from one of the people who invented XML is that it originally started out as case insensitive, and they had quite an extensive discussion about it. When they made it case sensitive, one of the basic tools sped up by a factor of three. Doing case translations in Unicode following all of the rules for all of the world's languages is, for want of a better world, a real bitch. John Roth -- http://mail.python.org/mailman/listinfo/python-list
Re: Case Sensitive, Multiline Comments
Duncan Booth said unto the world upon 2005-05-27 04:24: > There are arguments that, especially for beginners, case sensitivity > introduces an extra level of complexity, but the cost of losing this > complexity would be to make Python a poor relation amongst programming > languages. Well, this is just one man's anecdote, but Python was my first language since some BASIC many moons ago, and the case sensitivity neither got in my way, nor felt complex. Perhaps Python beginners with background in case insensitive languages do experience it differently. At any rate, since the sequence of characters 'somename' and 'SomeName' are different sequences, treating them as different names strikes me as the obviously right thing to do. Best to all, Brian vdB -- http://mail.python.org/mailman/listinfo/python-list
Re: Case Sensitive, Multiline Comments
i found case sensitivity very useful 1. variables can be stored in a dict (think about __dict__, globals()) and dict type should be case sensitive 2. It's necessary when i write short scripts and i use one letter names. (eg. when i playing with linear algebra i always use a,b,c for vectors and A,B,C for matrices). I dont want to think about "more than one letter" names when i run that script only once. And usually this is the case with python (at least when i use it in interpreted mode). 3. i write sometimes: class Foo: ... foo = Foo() and i think it's readable and makes sense. 4. actually i never wanted to use 'foo', 'Foo' and 'FOO' for the same variable and i can't imagine a situation when it's useful. it makes the code less readable so i think the language should force the programmer not to use different names for the same variable. nsz -- http://mail.python.org/mailman/listinfo/python-list
Re: Case Sensitive, Multiline Comments
Dennis Lee Bieber wrote: > On 26 May 2005 17:33:33 -0700, "Elliot Temple" <[EMAIL PROTECTED]> > declaimed the following in comp.lang.python: > >> Thanks for the link on case sensitivity. I'm curious about the person >> who found case sensitivity useful though: what is it useful for? >> > Making a language run faster on slow machines since the syntax > parsing doesn't have to do the equivalent of upper or lower casing > anything that is not a string literal before checking for keywords or > identifiers. > > Consider the time spent by languages like Ada and Fortran when > they have to do case normalization every time you compile. > That isn't a good argument for case sensitivity. You really aren't going to be able to measure a slowdown in compilation speed just because the compiler has to lowercase all the identifiers before using them. What I consider good arguments for case sensitivity are: Consistency. I've used non-case sensitive languages where the same variable was spelled sometimes with capitals and sometimes without. Forcing you to choose one case and stick to it is, IMHO a good thing. Worse, I've used Visual Basic where the editor will gratuitously change the case of a variable you just typed in because there is another occurrence of the same name somewhere else in a different case. Conventions such as capitalising class names, or camelCasing can be useful. Again this only applies if they are used consistently. Interoperability. Like it or not, there are other case sensitive systems out there. I once had the misfortune to use a Microsoft Access database (where lookups on indexed fields are case insensitive) to store records indexed by a case sensitive medical coding system. Codes in that system do exist which differ from other completely unrelated conditions only by the case of the code. The only way to handle this in a case insensitive system is to somehow escape each case sensitive code. That particular example wouldn't necessarily apply to a case insensitive programming language, but plenty of others would: e.g. using a remote procedure call system to call a (case sensitive) function on another system. In all such cases, the case insensitive system is the 'poor relation', it is the one where you have to introduce workrounds in order to communicate with the case sensitive system. Going in the other direction (calling a case insensitive function from a case sensitive system) you simply have to invent a convention (e.g. lowercase everything) and stick by it. There are arguments that, especially for beginners, case sensitivity introduces an extra level of complexity, but the cost of losing this complexity would be to make Python a poor relation amongst programming languages. -- http://mail.python.org/mailman/listinfo/python-list
Re: Case Sensitive, Multiline Comments
Elliot Temple wrote: > Thanks for the link on case sensitivity. I'm curious about the person > who found case sensitivity useful though: what is it useful for? I wasn't that person, but I do find case sensitivity very useful. Mainly it's useful in that it allows me not to spend any time at all worrying that I just might have a collision in my naming of various entities that are conceptually in different spaces but which -- due to the nature of the language I'm using -- happen to co-exist in the same namespace. For example, although this contrived example suggests poor imagination in picking names, I think it demonstrates the point. INVENTORYCODE = 5 # in effect one item in a constant "enum" class InventoryCode: '''Might represent something to do with inventory codes... duh''' def myfunc(): inventoryCode = someOtherFunction() In other words, I have a CONSTANT, a Class, and an instance, and if the set of code involved were large enough, these three things might be defined far enough apart that the potential collision wouldn't be as obvious as it is here. More to the point, there might not be any relationship between these things in my mind as I'm programming, and having to deal with an error message from a compiler or, worse, a run time error resulting from this collision would really annoy me. Case sensitivity might not be something we should be deliberately exercising on a daily basis, but there's no good reason (in my opinion) for not having it available to allow one freedom in naming (assuming one is sane and uses consistent convention for the case of things like constants, classes, and instances) without the worry of pesky collisions. -Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Case Sensitive, Multiline Comments
"Elliot Temple" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Hi I have two questions. ... > Also, why aren't there > multiline comments? Would adding them cause a problem of some sort? As a matter of fact, yes. First, consider that as soon as you have multi-line comments, someone is going to request nested multi-line comments. (In other words, the compiler should check that the embedded comment is still correct.) That rapidly leads to madness. Second, multi-line comments aren't really necessary; as someone in the thread commented, a decent editor or IDE will allow adding or removing comments from a block of code easily. Python's philosophy is to only add features when there is a use case that will improve the language significantly, and commenting out a block of code for testing isn't it. (It's also not the world's best practice, but that's another subject.) John Roth > > Thanks, > Elliot > -- http://mail.python.org/mailman/listinfo/python-list
Re: Case Sensitive, Multiline Comments
Thanks for the link on case sensitivity. I'm curious about the person who found case sensitivity useful though: what is it useful for? The way I find multi-line comments useful is to quickly comment out a block of code while debugging. A good development environment can (mostly) solve that one though. -- http://mail.python.org/mailman/listinfo/python-list
Re: Case Sensitive, Multiline Comments
Mike Meyer wrote: > Personally, I think anyone who has two variables whose names differ > only in case should be shot. No, let me extend that - anyone who has > two variables whose names would be pronounced the same should be > shot. I've had to debug such code, and it ain't fun. Here's a pair of targets for you: From "Software Engineering with Modula-2 and Ada", by Wiener & Sincovec, page 84: WITH w^ DO ... Col := column; Row := row; It turns out that 'Row' & 'Col' are module-global variables holding the current cursor position, and 'row' & 'column' are elements of the record to which 'w' points. Here's another corollary for Meyer's Law: Anyone who has two variables the name of one of which is, or could reasonably be understood to be, an abbreviation of the name of the other should be shot. Cheers, John -- http://mail.python.org/mailman/listinfo/python-list
Re: Case Sensitive, Multiline Comments
Mike Meyer wrote: > "Elliot Temple" <[EMAIL PROTECTED]> writes: >> Also, why aren't there >>multiline comments? Would adding them cause a problem of some sort? > > Because no one every really asked for them. After all, there are two > formats for multi-line strings, which the interpreter will build and > then discard. There are tools that recognize multi-line strings after > function/method definitions and treat them as function documentation. > > Adding multiline comments probably wouldn't be a problem - you'd just > have to come up with an introductory character sequence that can't > occur in the language (not that that stopped C). But you'd have to get > someone to write the code, then someone with commit privs to decide it > was useful enough to commit. That seems to be a lot of work for very > little gain. Don't we already have multi-line comments in the form of string literals? -- Paul McNett http://paulmcnett.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Case Sensitive, Multiline Comments
"Elliot Temple" <[EMAIL PROTECTED]> writes: > Hi I have two questions. Could someone explain to me why Python is > case sensitive? I find that annoying. Because it comes from a language background of case sensitive languages (C, shell, etc.). But read what the BDFL has to say about it: http://mail.python.org/pipermail/python-list/2001-July/054788.html > Personally, I think anyone who has two variables whose names differ only in case should be shot. No, let me extend that - anyone who has two variables whose names would be pronounced the same should be shot. I've had to debug such code, and it ain't fun. Variables whose name differs from the class they are instance of only in case is the only allowable exception. And should be used with care. On the same note, anyone who spells a variable name with different cases because the languge is case-insensitive should be shot. I want to be able to use various source analysis tools without having to worry about dealing with two different ascii strings being names for a single variable. Add those two together, and you'll see that *I don't care*. I consider taking advantage of a language being case-sensitive or case-insensitive to be a bad idea, so it doesn't matter what the language does. > Also, why aren't there > multiline comments? Would adding them cause a problem of some sort? Because no one every really asked for them. After all, there are two formats for multi-line strings, which the interpreter will build and then discard. There are tools that recognize multi-line strings after function/method definitions and treat them as function documentation. Adding multiline comments probably wouldn't be a problem - you'd just have to come up with an introductory character sequence that can't occur in the language (not that that stopped C). But you'd have to get someone to write the code, then someone with commit privs to decide it was useful enough to commit. That seems to be a lot of work for very little gain. http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Case Sensitive, Multiline Comments
Hi, A1: because some people find it very useful ? I know I do A2: they exist: """ Regards, Philippe Elliot Temple wrote: > Hi I have two questions. Could someone explain to me why Python is > case sensitive? I find that annoying. Also, why aren't there > multiline comments? Would adding them cause a problem of some sort? > > Thanks, > Elliot -- http://mail.python.org/mailman/listinfo/python-list
Case Sensitive, Multiline Comments
Hi I have two questions. Could someone explain to me why Python is case sensitive? I find that annoying. Also, why aren't there multiline comments? Would adding them cause a problem of some sort? Thanks, Elliot -- http://mail.python.org/mailman/listinfo/python-list
