Python MSI not installing, log file showing name of a Viatnemese communist revolutionary

[Steven D'Aprano]

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
> line?  

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 
something like:

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')
=> #<File:/tmp/io.txt>
irb(main):002:0> f.read()
=> "hello"
irb(main):003:0> f.read()
=> ""


[steve at ando ~]$ lua
Lua 5.1.4  Copyright (C) 1994-2008 Lua.org, PUC-Rio
> fp = io.open('/tmp/io.txt', 'r')
> print(fp:read("*all"))
hello
> print(fp:read("*all"))

>


Similarly, Rust returns None:
http://static.rust-lang.org/doc/0.9/std/io/trait.Reader.html#tymethod.read

And Java's java.io.BufferedReader is also similar, returning null.




-- 
Steven D'Aprano
http://import-that.dreamwidth.org/