I just tried a re-flow in emacs (M-q or fill-paragraph) and it didn't change my single space to two (it also changed 3 spaces after a period to 2; and it preserved my hanging indents). I have no idea what vim does. (OTOH, emacs annoyingly adds a blank line to my """ docstrings, which I remove manually.)
I'm not going to stoke the fires of debate (especially as I've worked with typographers over the years and know that the typographical sins of programmers go far beyond the double-space-after-period), except to note that if you read the thousands of words that have been written about spacing after periods, they're usually talking about *proportional* fonts; and we still tend to use monospaced fonts with programming tools. On 21 May 2016 at 00:44, Stephen J. Turnbull <step...@xemacs.org> wrote: > Bernardo Sulzbach writes: > > > On 05/20/2016 09:27 AM, Brett Cannon wrote: > > > > > > The period is a full-stop punctuation mark, but visually obscure [1]. > > > > It is small. This does not make it hard to notice, however. > > That depends on fonts, and on the ability of the user to write > correctly as well. "Syntax should not look like grit on Tim's screen" > applies to natural language as well. I read a lot of English-as-a- > second-language text, and it really does help to have the extra space, > because the period often appears where English grammar suggests it > doesn't belong. The extra effort to use the second space helps to > emphasize the author's intent, and even subjectively make the period > "more visible". > > But I agree with Guido. No Python contributors write poorly, so the > real issues are consistency with past practice (a minor consideration > in the case of comments) and tooling (since both Emacs and vim seem to > come out of the box believing in this rule, I guess it's widespread > enough to care). > > As for Brett's concern about whether this should be specified at this > level, I think tooling again is an answer. Emacs reflows whole > paragraphs. That means that text that is off-screen may be changed > according to this rule, and that is an annoyance when you only notice > it while preparing a patch for submission. I think a detail of style > that triggers unwanted (but plausible[1]) behavior in a widely-used > tool is worth standardizing. Sometimes, of course, you standardize > *despite* the tool, but then at least the tool-users know that a > decision has been taken to impose the burden on them, vs. imposing the > burden on people who prefer the other style. > > Footnotes: > [1] If the behavior is implausible, fix the tool, of course! > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/pludemann%40google.com >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
