test_pep263.py is "-kb" in CVS
As subject. Is this deliberate? It breaks test_compiler, though that's possibly a bug because test_compiler should be using universal newlines modes when opening the file, but still... Cheers, mwh -- The word "Fascism" has now no meaning except in so far as it signifies 'something not desirable'. -- George Orwell in "Politics and the English Language"
[Michael Hudson]
As subject. Is this deliberate?
Don't know, but guess so: it contains bytes outside the set ANSI C says can be used portably in text files.
It breaks test_compiler,
That must be platform-specific damage, but you haven't identified your platform.
though that's possibly a bug because test_compiler should be using universal newlines modes when opening the file,
Probably, yes.
but still...
So stop whining and fix it <wink>.
Tim Peters
[Michael Hudson]
As subject. Is this deliberate?
Don't know, but guess so: it contains bytes outside the set ANSI C says can be used portably in text files.
It breaks test_compiler,
That must be platform-specific damage, but you haven't identified your platform.
Well, yes, but this information isn't especially relavent. It's obviously a different platform from whoever edited the file last... I'm on linux, though.
though that's possibly a bug because test_compiler should be using universal newlines modes when opening the file,
Probably, yes.
but still...
So stop whining and fix it <wink>.
I have done and am waiting for test_compiler to finish ... that allows for a lot of whining :) Cheers, mwh -- There are two kinds of large software systems: those that evolved from small systems and those that don't work. -- Seen on slashdot.org, then quoted by amk
Tim Peters wrote:
[Michael Hudson]
As subject. Is this deliberate?
Don't know, but guess so: it contains bytes outside the set ANSI C says can be used portably in text files.
However, this is not necessarily enough reason to use -kb. The only things -kb does are LF -> CRLF / LF -> CR mapping, not using diff for updates, and not expanding $ keywords. None of those matter in this file.
It breaks test_compiler,
That must be platform-specific damage, but you haven't identified your platform.
though that's possibly a bug because test_compiler should be using universal newlines modes when opening the file,
Probably, yes.
but still...
So stop whining and fix it <wink>. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/sjoerd%40acm.org
--
Sjoerd Mullender
Sjoerd Mullender wrote:
Don't know, but guess so: it contains bytes outside the set ANSI C says can be used portably in text files.
However, this is not necessarily enough reason to use -kb. The only things -kb does are LF -> CRLF / LF -> CR mapping, not using diff for updates, and not expanding $ keywords.
That is not true. On Apple computers, it also avoids conversion from Latin-1 to Mac-Roman, which Mac CVS does by default for text files. Making the files binary is the only way to avoid this conversion, and that is precisely the reason why the file is binary. You may argue that this is a bug in Mac CVS, and I would agree. However, that specific bug has -kb as a known work-around, and the issue reported here points to a bug in the compiler packages which should be fixed rather than worked-around. Regards, Martin
Martin v. Löwis wrote:
Sjoerd Mullender wrote:
Don't know, but guess so: it contains bytes outside the set ANSI C says can be used portably in text files.
However, this is not necessarily enough reason to use -kb. The only things -kb does are LF -> CRLF / LF -> CR mapping, not using diff for updates, and not expanding $ keywords.
That is not true. On Apple computers, it also avoids conversion from Latin-1 to Mac-Roman, which Mac CVS does by default for text files. Making the files binary is the only way to avoid this conversion, and that is precisely the reason why the file is binary.
I didn't know this.
You may argue that this is a bug in Mac CVS, and I would agree. However, that specific bug has -kb as a known work-around, and the issue reported here points to a bug in the compiler packages which should be fixed rather than worked-around.
I agree that this sounds very much like a MacCVS bug, but it also sounds
like an excellent reason to leave this file alone. And the compiler
issue should be (and has been, I saw) fixed.
--
Sjoerd Mullender
Sjoerd Mullender wrote:
However, this is not necessarily enough reason to use -kb. The only things -kb does are LF -> CRLF / LF -> CR mapping, not using diff for updates, and not expanding $ keywords.
That is not true. On Apple computers, it also avoids conversion from Latin-1 to Mac-Roman, which Mac CVS does by default for text files. Making the files binary is the only way to avoid this conversion, and that is precisely the reason why the file is binary.
I didn't know this.
You may argue that this is a bug in Mac CVS, and I would agree. However, that specific bug has -kb as a known work-around, and the issue reported here points to a bug in the compiler packages which should be fixed rather than worked-around.
I agree that this sounds very much like a MacCVS bug, but it also sounds like an excellent reason to leave this file alone. And the compiler issue should be (and has been, I saw) fixed.
On the other hand, I hardly know anyone who uses MacCVS anymore. Before OSX you _had_ to use some Mac port of CVS (there were/are many), but on OSX most people simply use cvs on the command line, which is the standard unix version. Still, you can configure MacCVS to not convert the encoding. In other words: I wouldn't worry about MacCVS anymore, at all. Just
Just van Rossum writes:
On the other hand, I hardly know anyone who uses MacCVS anymore. Before OSX you _had_ to use some Mac port of CVS (there were/are many), but on OSX most people simply use cvs on the command line, which is the standard unix version. Still, you can configure MacCVS to not convert the encoding. In other words: I wouldn't worry about MacCVS anymore, at all.
Agreed. Bill
participants (6)
-
"Martin v. Löwis" -
Bill Janssen -
Just van Rossum -
Michael Hudson -
Sjoerd Mullender -
Tim Peters