Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #68718 > unrolled thread

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

Back to article view | Back to comp.lang.python

Contents

  Python MSI not installing, log file showing name of a Viatnemese communist revolutionary cool-RR <ram.rachum@gmail.com> - 2014-03-21 15:05 -0700
    Re: Python MSI not installing, log file showing name of a Viatnemese communist revolutionary cool-RR <ram.rachum@gmail.com> - 2014-03-21 15:08 -0700
    Re: Python MSI not installing, log file showing name of a Viatnemese communist revolutionary Chris Angelico <rosuav@gmail.com> - 2014-03-22 09:25 +1100
      Re: Python MSI not installing, log file showing name of a Viatnemese communist revolutionary cool-RR <ram.rachum@gmail.com> - 2014-03-21 15:34 -0700
        Re: Python MSI not installing, log file showing name of a Viatnemese communist revolutionary cool-RR <ram.rachum@gmail.com> - 2014-03-21 15:34 -0700
          Re: Python MSI not installing, log file showing name of a Viatnemese communist revolutionary Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-21 22:44 +0000
            Re: Python MSI not installing, log file showing name of a Viatnemese communist revolutionary Mark H Harris <harrismh777@gmail.com> - 2014-03-21 22:58 -0500
              Re: Python MSI not installing, log file showing name of a Viatnemese communist revolutionary Chris Angelico <rosuav@gmail.com> - 2014-03-22 15:15 +1100
                Re: Python MSI not installing, log file showing name of a Viatnemese communist revolutionary Mark H Harris <harrismh777@gmail.com> - 2014-03-21 23:30 -0500
                  Re: Python MSI not installing, log file showing name of a Viatnemese communist revolutionary Mark H Harris <harrismh777@gmail.com> - 2014-03-21 23:36 -0500
                  Re: Python MSI not installing, log file showing name of a Viatnemese communist revolutionary Chris Angelico <rosuav@gmail.com> - 2014-03-22 15:46 +1100
                    Re: Python MSI not installing, log file showing name of a Viatnemese communist revolutionary Mark H Harris <harrismh777@gmail.com> - 2014-03-21 23:59 -0500
                      Re: Python MSI not installing, log file showing name of a Viatnemese communist revolutionary wxjmfauth@gmail.com - 2014-03-22 01:54 -0700
                        Re: Python MSI not installing, log file showing name of a Viatnemese communist revolutionary Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-22 10:54 +0000
                  Re: Python MSI not installing, log file showing name of a Viatnemese communist revolutionary Terry Reedy <tjreedy@udel.edu> - 2014-03-22 01:24 -0400
                    Re: Python MSI not installing, log file showing name of a Viatnemese communist revolutionary Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-22 09:50 +0000
                      Re: Python MSI not installing, log file showing name of a Viatnemese communist revolutionary Terry Reedy <tjreedy@udel.edu> - 2014-03-22 06:14 -0400
                  Re: Python MSI not installing, log file showing name of a Viatnemese communist revolutionary Chris Angelico <rosuav@gmail.com> - 2014-03-22 16:32 +1100
                  Re: Python MSI not installing, log file showing name of a Viatnemese communist revolutionary Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-03-22 11:25 -0400
              Re: Python MSI not installing, log file showing name of a Viatnemese communist revolutionary Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-22 10:51 +0000
              Re: Python MSI not installing, log file showing name of a Viatnemese communist revolutionary Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-22 14:50 +0000
                Re: Python MSI not installing, log file showing name of a Viatnemese communist revolutionary Chris Angelico <rosuav@gmail.com> - 2014-03-23 02:09 +1100
                  Re: Python MSI not installing, log file showing name of a Viatnemese communist revolutionary Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-23 01:07 +0000
        Re: Python MSI not installing, log file showing name of a Viatnemese communist revolutionary Chris Angelico <rosuav@gmail.com> - 2014-03-22 09:42 +1100
          Re: Python MSI not installing, log file showing name of a Viatnemese communist revolutionary cool-RR <ram.rachum@gmail.com> - 2014-03-21 15:50 -0700
      Re: Python MSI not installing, log file showing name of a Viatnemese communist revolutionary cool-RR <ram.rachum@gmail.com> - 2014-03-21 15:55 -0700
        Re: Python MSI not installing, log file showing name of a Viatnemese communist revolutionary Terry Reedy <tjreedy@udel.edu> - 2014-03-21 21:39 -0400
          Re: Python MSI not installing, log file showing name of a Viatnemese communist revolutionary cool-RR <ram.rachum@gmail.com> - 2014-03-22 03:57 -0700

Page 2 of 2 — ← Prev page 1 [2]

#68779

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@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@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/

[toc] | [prev] | [next] | [standalone]

#68780

On Sun, Mar 23, 2014 at 1:50 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> 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.

Not so weird IMO. A file is not a concatenation of lines; it is a
stream of bytes. Now, if you ask Python to read you 512 bytes from a
binary file, and then ask for another 512 bytes, and so on until you
reach the end, then it would indeed be VERY weird if there were parts
of the file that weren't in the returned (byte) strings. But if you
ask for a line, and then another line, and another line, then it's
quite reasonable to interpret U+000A as "line separation" rather than
"line termination", and not return it. (Both interpretations make
sense. I just wish the most obvious form of iteration gave the
cleaner/tidier version, or at very least that there be some really
obvious way to ask for lines-without-endings.) Imagine the output of
GNU find as a series of records. You can ask for those to be separated
by newlines (the default, or -print), or by NULs (with the -print0
command). In either case, the records do not *contain* that value,
they're separated by it; the records consist of file names.

ChrisA

[toc] | [prev] | [next] | [standalone]

#68798

On Sun, 23 Mar 2014 02:09:20 +1100, Chris Angelico wrote:

> On Sun, Mar 23, 2014 at 1:50 AM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> 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.
> 
> Not so weird IMO. A file is not a concatenation of lines; it is a stream
> of bytes. 

But a *text file* is a concatenation of lines. The "text file" model is 
important enough that nearly all programming languages offer a line-based 
interface to files, and some (Python at least, possibly others) make it 
the default interface so that iterating over the file gives you lines 
rather than bytes -- even in "binary" mode.


> Now, if you ask Python to read you 512 bytes from a binary
> file, and then ask for another 512 bytes, and so on until you reach the
> end, then it would indeed be VERY weird if there were parts of the file
> that weren't in the returned (byte) strings. But if you ask for a line,
> and then another line, and another line, then it's quite reasonable to
> interpret U+000A as "line separation" rather than "line termination",
> and not return it. (Both interpretations make sense. I just wish the
> most obvious form of iteration gave the cleaner/tidier version, or at
> very least that there be some really obvious way to ask for
> lines-without-endings.)

There is: call strip('\n') on the line after reading it. Perl and Ruby 
spell it chomp(). Other languages may spell it differently. I don't know 
of any language that automatically strips newlines, probably because you 
can easily strip the newline from the line, but if the language did it 
for you, you cannot reliably reverse it.


> Imagine the output of GNU find as a series of
> records. You can ask for those to be separated by newlines (the default,
> or -print), or by NULs (with the -print0 command). In either case, the
> records do not *contain* that value, they're separated by it; the
> records consist of file names.

I have no problem with that: when interpreting text as a record with 
delimiters, e.g. from a CSV file, you normally exclude the delimiter. 
Sometimes the line terminator does double-duty as a record delimiter as 
well.

Reading from a file is considered a low-level operation. Reading 
individual bytes in binary mode is the lowest level; reading lines in 
text mode is the next level, built on top of the lower binary mode. You 
build higher protocols on top of one or the other of that mode, e.g. 
"read a zip file" would be built on top of binary mode, "read a csv file" 
would be built on top of text mode.

As a low-level protocol, you ought to be able to copy a file without 
changing it by reading it in then writing it out:

for blob in infile:
    outfile.write(blob)


ought to work whether you are in text mode or binary mode, so long as the 
infile and outfile are opened in the same mode. If Python were to strip 
newlines, that would no longer be the case.

(Even high-level protocols should avoid unnecessary modifications to 
files. One of the more annoying, if not crippling, limitations to the 
configparser module is that reading an INI file in, then writing it out 
again destroys the high-level structure of the file: comments and blank 
lines are stripped, and records may be re-ordered.)



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

[toc] | [prev] | [next] | [standalone]

#68724

On Sat, Mar 22, 2014 at 9:34 AM, cool-RR <ram.rachum@gmail.com> wrote:
> I did download from python.org. I checked the md5, it was incorrect, then I downloaded again by using a proxy in Austria. (Which hopefully the communists haven't be able to infiltrate? ;)
>

I think you should follow the internet version of Hanlon's Razor here:
Damaged transmission before deliberate tampering. :) It's far more
likely something simply got misdownloaded, and your guess about
timezones is the most likely one - the Asia/Ho_Chi_Minh timezone [1],
and I believe Python Windows installers include a full zoneinfo
database.

ChrisA

[1] See https://en.wikipedia.org/wiki/Ho_Chi_Minh_City

[toc] | [prev] | [next] | [standalone]

#68726

On Saturday, March 22, 2014 12:42:56 AM UTC+2, Chris Angelico wrote:
> I think you should follow the internet version of Hanlon's Razor here:
> Damaged transmission before deliberate tampering. :) It's far more
> likely something simply got misdownloaded, and your guess about
> timezones is the most likely one - the Asia/Ho_Chi_Minh timezone [1],
> and I believe Python Windows installers include a full zoneinfo
> database.


The thing is, I then tried other versions of Python 3.4, like b2, and the 32 bit version, and they didn't work either... So damaged transmission of 3 separate files? I'm not seeing any other damaged files when surfing using this connection.

[toc] | [prev] | [next] | [standalone]

#68728

On Saturday, March 22, 2014 12:25:03 AM UTC+2, Chris Angelico wrote:
> (First and a halfth question: When you say "won't install", exactly
> what do you mean?

For completeness, I'll answer this question I forgot to answer, in case someone still wants to investigate: It just showed the first dialog (Something like "Preparing to install..."), after a few seconds it disappeared and then nothing.

[toc] | [prev] | [next] | [standalone]

#68731

On 3/21/2014 6:55 PM, cool-RR wrote:
> On Saturday, March 22, 2014 12:25:03 AM UTC+2, Chris Angelico wrote:
>> (First and a halfth question: When you say "won't install", exactly
>> what do you mean?
>
> For completeness, I'll answer this question I forgot to answer, in case someone still wants to investigate: It just showed the first dialog (Something like "Preparing to install..."), after a few seconds it disappeared and then nothing.

Does your .b2 install work? Can you delete it thru the programs list?

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#68766

On Saturday, March 22, 2014 3:39:21 AM UTC+2, Terry Reedy wrote:
> Does your .b2 install work? Can you delete it thru the programs list?

I uninstalled it before this entire adventure.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.python

csiph-web