Robert Bradshaw <rober...@math.washington.edu> writes: > On Tue, Nov 27, 2012 at 10:51 AM, Jason Grout > <jason-s...@creativetrax.com> wrote: >> On 11/24/12 7:41 PM, Robert Bradshaw wrote: >> >>> Cool. (The doable part, not the unholy mess part :-). If that's the >>> case, how about we simply ignore the issue at the moment, remove it >>> all in the git conversion, and document + enforce a no-whitespace >>> policy as as part of the new development workflow. If there are no >>> objections, I'll write this up in #11956 as a new official policy. >> >> >> What if the line is entirely whitespace? I think it's rather nice to have >> the empty line below be padded with 4 spaces so I can just move my cursor to >> the empty line and start typing and things are automatically on the right >> indentation level: >> >> for i in range(10): >> some long calculation >> >> some other long calculation > > I'd say this is not worth an exception--it's much easier to disallow > all whitespace (and to use tools that strip all whitespace). Any sane > editor will tab to the right place.
+1, I don't think this is worth an exception either. Semi-relevant anecdote: many years ago I used to use whitespace in C-like languages the same way Jason does. (Actually I used tab characters because they "more semantically indicated scope", I thought.) I could never understand why people wanted to have blank lines within an inner scope not have the same indentation as other lines within the inner scope, and instead have the same indentation as the outermost scope (i.e. no trailing whitespace on the line). I changed my mind when someone explained it this way (paraphrased): "Don't think of text the way it appears on a page. Think of text as a stream of characters which is separated into 'lines' by the newline character at the end of each line; and furthermore think of groups of 'lines' as being separated into 'paragraphs' by the zero-length line at the end of each paragraph. This is similar to binary formats for storing variable-width data, in which you might delimit each field by a null byte, and each record by a double null byte." (Mercurial's bundle format does exactly this, by the way! [1] [2]) Now, if you discard the paragraph information and look only at the lines, empty lines disappear entirely from your program (because they're just delimiters between paragraphs), and the indentation level smoothly moves up and down as you expect. But if you have "empty" lines that still contain some whitespace, they are considered as meaningful lines within a paragraph, rather than as paragraph delimiters, which is probably not what you want. Of course, this is all purely subjective, but I found it an appealing intuition as to why "indent empty lines" was not the prevailing practice, after which I stopped doing it :) [1] http://mercurial.selenic.com/wiki/WireProtocol#Changegroup_Format [2] http://trac.sagemath.org/sage_trac/attachment/ticket/3052/trac_3052-textify.patch >> Here's an example of code that changes behavior when there is >> trailing whitespace: >> >> print 1 + \ >> 2 >> >> If there is a space after the \, it's a syntax error. If there is no space, >> it prints 3. >> >> I'm not interpreting how this is good or bad, but just pointing out that >> deleting whitespace can change code behavior, particularly in the case of >> continuation characters. > > Interesting example. I don't think trailing whitespace is ever required > though. Yes, definitely an interesting example, and a good reason why you should always use implicit line continuation and not explicit line continuation in Python, as detailed in PEP 8 :) [3] By the way, Python never requires trailing whitespace, but the Markdown language popular on Github, Reddit, etc. for comment formatting does [4]:: The implication of the “one or more consecutive lines of text” rule is that Markdown supports “hard-wrapped” text paragraphs. This differs significantly from most other text-to-HTML formatters (including Movable Type’s “Convert Line Breaks” option) which translate every line break character in a paragraph into a <br /> tag. When you do want to insert a <br /> break tag using Markdown, you end a line with two or more spaces, then type return. So :: a b becomes "a<br>b", while :: a b becomes "a b". Two or more trailing spaces on a line are converted into a "<br>" tag, and one or zero are not. Ridiculous, isn't it? :) I'm glad we use reStructuredText! (To GitHub's credit, they've removed this obtuse language construct and just always convert line breaks into <br> tags.) [3] http://www.python.org/dev/peps/pep-0008/#indentation [4] http://daringfireball.net/projects/markdown/syntax#p -Keshav -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
