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

[cool-RR]

Hi everybody,

I need to install Python 3.4 final urgently, because my IDE stopped supporting Python 3.4 beta2, and I need it urgently to work.

I downloaded it, but the MSI won't install. It didn't work on both of my computers (Windows 7 64bit).

I managed to have the MSI dump data to log, file attached.

I couldn't help but notice this line in the log:

The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2726. The arguments are: HO_CHI~1|Ho_Chi_Minh

A Google search shows this: http://en.wikipedia.org/wiki/Ho_Chi_Minh

What the hell. Was python.org hacked by communists?

Please, I need to get back to work and I can't.


Thanks,
Ram.

 

[cool-RR]

Sorry, couldn't attach the file, here's the log file:

https://gist.github.com/anonymous/9697505

 

[Chris Angelico]

I downloaded it, but the MSI won't install. It didn't work on both of my computers (Windows 7 64bit).

What the hell. Was python.org hacked by communists?

First question: Where did you download from? What file did you get?

(First and a halfth question: When you say "won't install", exactly
what do you mean? Error message? Hard drive exploded in a fiery
inferno? Your boss tapped you on the shoulder and said "Kill that
process"?)

Secondly, do you have a tool for checking the MD5 hash of a file?
Compare the file you have against the official checksum:

https://www.python.org/downloads/release/python-340/

I'm slightly surprised the python.org installers have MD5s and not
something more cryptographically secure; there are GPG signatures, but
it takes a bit more fiddling to check those.

Finally, take the simple approach: Re-download the file, straight from
python.org, and see if it happens again.

ChrisA

 

[cool-RR]

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?

Now it worked! Woohoo!

I'm still curious about the bad installation file... And what Ho Chi Minh is doing in the Python MSI. (I'm guessing it's timezone-related, but it's still far-fetched, because why would an obscure time zone file appear in the MSI log?)

 

[cool-RR]

Here's the offending MSI, if anyone wants to investigate: https://dl.dropboxusercontent.com/u/1927707/python-3.4.0.amd64.msi

 

[Mark Lawrence]

On 21/03/2014 22:34, cool-RR wrote:

I'm pleased to see that you have answers. In return would you either
use the mailing list
https://mail.python.org/mailman/listinfo/python-list or read and action
this https://wiki.python.org/moin/GoogleGroupsPython to prevent us
seeing double line spacing and single line paragraphs, thanks.

 

[cool-RR]

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.

 

[cool-RR]

(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.

 

[Terry Reedy]

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?

 

[Mark H Harris]

I'm pleased to see that you have answers. In return would you either use
the mailing list https://mail.python.org/mailman/listinfo/python-list or
read and action this https://wiki.python.org/moin/GoogleGroupsPython to
prevent us seeing double line spacing and single line paragraphs, thanks.

I perceive that this is your singular pet peeve, or, you were elected by
the python community some time ago to police the line-end problem ?

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.

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.

Why do we suck in the new-line character as though it were part of the
line? This is asinine behavior. The new-line is a "file" delimiter
character and NOT intended to be part of the line.

Thinking this through a bit 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.

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?

Of course, that does not alleviate all of the rest of gg's short
comings! <sigh>

marcus

 

[Chris Angelico]

I perceive that this is your singular pet peeve, or, you were elected by the
python community some time ago to police the line-end problem ?

Communities maintain standards by policing them. If nobody cares
enough to post, the problem will remain. He happens to be one of the
most frequent commenters on this particular issue, but believe you me,
he is not the only one to wish it were solved; I used to speak up too,
but became tired of saying it (and of the blowback), and now I ignore
all double-spaced junk. If I can't figure out what's going on without
the context, I'll just move on to the next post.

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 compounds. One reply makes for double spacing... two makes
quadruple, three means we have seven wasted lines between every pair
of real lines. That gets pretty annoying. And considering that most
people who reply without cleaning up the lines also keep the entire
quoted text (and usually top-post as well), this gets big fast.

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.

No idea why you should think this; it's more likely to be based on
HTML parsing (newline -> paragraph -> double newline), especially
since the original text is usually unwrapped.

Why do we suck in the new-line character as though it were part of the line?
This is asinine behavior. The new-line is a "file" delimiter character and
NOT intended to be part of the line.

Thinking this through a bit 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.

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?

Personally, I think that iterating over the lines in a file (in the
most obvious way) should strip delimiters. There should be a
less-obvious way to iterate over the "lines complete with their line
ends", which can then be used to distinguish between the different
line endings (including the absence of one at the end of the file),
but most of the time you want to just treat a file as a series of
lines, and don't care about the distinctions. However, that ship has
sailed; it's way WAY too late to make any such change.

And changing it would not fix the Google Groups problem unless it also
broke a whole pile of other code out there.

ChrisA

 

[Mark H Harris]

It compounds. One reply makes for double spacing... two makes
quadruple, three means we have seven wasted lines between every pair
of real lines. That gets pretty annoying. And considering that most
people who reply without cleaning up the lines also keep the entire
quoted text (and usually top-post as well), this gets big fast.

Yes, I can see that readily/ I get it, it just seems that fixing it
at the source (gg) is the answer; because there will always be someone
new to the list who is using gg because its part of their suite and
because its convenient (I mean, that's why I tried to use it). I think
we need to be beating up on the gg people so they get their stuff working.

Personally, I think that iterating over the lines in a file (in the
most obvious way) should strip delimiters.
agreed.

most of the time you want to just treat a file as a series of
lines, and don't care about the distinctions. However, that ship has
sailed; it's way WAY too late to make any such change.

agreed again, on both counts.

And changing it would not fix the Google Groups problem unless it also
broke a whole pile of other code out there.

No doubt. Well, I don't mind dealing with it/ and frankly, I don't
really think its a python problem anyway at the root. All files should
have standard delimiters. What I used to call flat-text files should
have standard line-end delimiters, and standard file-end EOF markers.
All OS's should comply with the standard... for instance, there should
not be a windows x'0a' x'0d' line ending, and a unix x'0d' line ending.

Well, and now that I'm thinking about this again, since we have
unicode, maybe we should have an entire set of standard "file"
delimiters for flat-files.

But the bottom line (pun intended) is that I just want to suck the
lines in, and I only want the system to have to handle the delimiters;
I'm not asking for any changes mind you (at this point) just thinking
out-loud.

Cheers dude.

 

[Mark H Harris]

All OS's should comply with the standard... for instance, there should
not be a windows x'0a' x'0d' line ending, and a unix x'0d' line ending.

whoops... I meant unix x'0a' line ending... ;-)


'\n'

)

 

[Chris Angelico]

All files should have standard delimiters. What I used to call flat-text
files should have standard line-end delimiters, and standard file-end EOF
markers. All OS's should comply with the standard... for instance, there
should not be a windows x'0a' x'0d' line ending, and a unix x'0d' line
ending.

(Side point: You have your 0d and your 0a backwards; the Unix line
ending is U+000A, and the Windows default is U+000D U+000A.)

How are you going to make people change? What are you going to make
them change to? Who controls this standard, and how do you convince
all OSes to comply with it?

ChrisA

 

[Mark H Harris]

(Side point: You have your 0d and your 0a backwards; the Unix line
ending is U+000A, and the Windows default is U+000D U+000A.)

Yeah, I know... smart apple.

How are you going to make people change? What are you going to make
them change to? Who controls this standard, and how do you convince
all OSes to comply with it?

Well, we're already doing this to some extent; baby steps. Well, we
have open document standards (evolving) and we have a really good sense
for unicode (and python is being a genuine leader there) and the
flat-file is just another open document (very simple no doubt), not
different from a standards viewpoint than rft, odt, {whatever}; txt?

My idea is that as we are morphing open document standards we need
to keep the "flat-file" in mind too. The ASCII ship has sailed too.
Unicode is in, ASCII is out (for all intents and purposes) except at
Microsoft---and its time to rethink what a "flat" unicode text file
really is. That's all.

marcus

 

[Terry Reedy]

Before Mark started asking people adjust to the foibles of gg, we used
to get such posts. I refused to read them. I have not seen one lately,
say maybe his nudging has had some positive effect.

Yes, I can see that readily/ I get it, it just seems that fixing it
at the source (gg) is the answer;

I completely agree. However, Google seems immune to suggestions,
including requests that it try to stop being a major source of spam posts.

because there will always be someone
new to the list who is using gg because its part of their suite and
because its convenient (I mean, that's why I tried to use it).

If I were in charge of the software used for this list, I would replace
Mark with a custom addition to return mis-formated posts (more blank
lines than not) with instructions on how to fix them. But I am not.

 

[Chris Angelico]

If I were in charge of the software used for this list, I would replace Mark
with a custom addition to return mis-formated posts (more blank lines than
not) with instructions on how to fix them. But I am not.

I love how this makes it sound as if Mark is part of Mailman...

ChrisA

 

[wxjmfauth]

Le samedi 22 mars 2014 05:59:34 UTC+1, Mark H. Harris a écrit :

Yeah, I know... smart apple.








Well, we're already doing this to some extent; baby steps. Well, we

have open document standards (evolving) and we have a really good sense

for unicode (and python is being a genuine leader there) and the

flat-file is just another open document (very simple no doubt), not

different from a standards viewpoint than rft, odt, {whatever}; txt?



My idea is that as we are morphing open document standards we need

to keep the "flat-file" in mind too. The ASCII ship has sailed too.

Unicode is in, ASCII is out (for all intents and purposes) except at

Microsoft---and its time to rethink what a "flat" unicode text file

really is. That's all.

No offense. A good start would be to understand "unicode"
instead of bashing MS.

jmf

 

[Steven D'Aprano]

Before Mark started asking people adjust to the foibles of gg, we used
to get such posts. I refused to read them. I have not seen one lately,

Luck you. I see them quite frequently.

say maybe his nudging has had some positive effect.


I completely agree. However, Google seems immune to suggestions,
including requests that it try to stop being a major source of spam
posts.

Remember, we are not Google's customers. We are Google's product. The
customers are the advertisers.

[...]

If I were in charge of the software used for this list, I would replace
Mark with a custom addition to return mis-formated posts (more blank
lines than not) with instructions on how to fix them. But I am not.

Wouldn't it be less obnoxious and more useful to pass the posts through a
filter that deletes the annoying blank lines?

 

[Terry Reedy]

Wouldn't it be less obnoxious and more useful to pass the posts through a
filter that deletes the annoying blank lines?

I have thought of that too, and may have suggested it. It would be
slightly harder as a decision would be required as to which to delete.