Python MSI not installing, log file showing name of a Viatnemese communist revolutionary
steve+comp.lang.python at pearwood.info
Sat Mar 22 15:50:47 CET 2014
On Fri, 21 Mar 2014 22:58:37 -0500, Mark H Harris wrote:
> I notice (since moving my stuff to Thunderbird two weeks back) the
> double spacing you keep squawking about, but I don't find it the big
> nuisance you're talking about; ok, so we have to scroll a bit further.
It's not the scrolling that interferes
with readability, it's the interruption
to the flow of text by having excess
blank lines within a paragraph of text.
> I am honestly convinced that this might even be a python problem. More
> likely than not, gg is written in python, and this is the goofy line-end
> character problem we have to deal with when we read lines in python.
Well, that's certainly a novel idea. Why you think that Google Groups is
written in Python? Does every post from GG end with "Powered By Python"?
> Why do we suck in the new-line character as though it were part of the
Because it is the only sensible way to handle it. If you don't, then
there is no way to distinguish between a file that ends with a newline
and one which doesn't.
> This is asinine behavior. The new-line is a "file" delimiter
> character and NOT intended to be part of the line.
Line endings are terminators: they end the line. Whether you consider the
terminator part of the line or not is a matter of opinion (is the cover
of a book part of the book?) but consider this:
If you say that the end of lines are *not* part of the line, then
that implies that some parts of the file are not inside any line
at all. And that would be just weird.
> Thinking this through a bit
Yes, that helps :-)
> I've noticed that a blank line comes back
> with a '\n' which differentiates it from file end which comes back
> "without" the new-line. So, it appears that python is using the
> new-line character (or lack there-of) to have meaning which the new=line
> in a unix file was never suppose to carry.
I don't understand what meaning you are referring to here. Blank lines
comes back as a \n because a blank line *is* a \n with nothing before it.
Python isn't doing anything funny here, at least not on Linux. If you
open a text editor, and type:
spam ENTER ENTER ENTER ENTER eggs ENTER
(where ENTER means to hit the Enter key, not the letters E N T E R) and
then save, your editor will show the words "spam" and "eggs" separated by
three blank lines. If you open that file in a hex editor, you will see
73 70 61 6d 0a 0a 0a 0a 65 67 67 73 0a
Notice the four 0a bytes in a row? That gives you three blank lines.
Python is no adding any extra newlines or putting them where they aren't,
so I don't really understand what point you're trying to make here.
> If python would just return EOF like every other language at file end,
> and a test line without '\n' tacked to the end of it, this little snag
> with gg would probably go away. What say you?
There is no evidence that Google Group's difficulty is because of Python.
More likely it is related to the translation between "rich text"
formatted using HTML, and plain text.
By the way, Python *does* return EOF at the end of the file. It is just
that EOF in Python is spelled "the empty string" instead of some other
special value. Both Ruby and Lua behave like Python, returning the empty
string on end of file:
steve at orac:~$ irb
irb(main):001:0> f = File.open('/tmp/io.txt')
[steve at ando ~]$ lua
Lua 5.1.4 Copyright (C) 1994-2008 Lua.org, PUC-Rio
> fp = io.open('/tmp/io.txt', 'r')
Similarly, Rust returns None:
And Java's java.io.BufferedReader is also similar, returning null.
More information about the Python-list