| msg62144 - (view) |
Author: Zdeněk Pavlas (zde) |
Date: 2008-02-07 12:21 |
| Please consider setting the default file mode to O_BINARY. O_TEXT breaks many unix programs and Windows has stopped to use CRLF files for anything of use since the introduction of Win95's registry anyway. Days when majority of "C" codebase actually DID process text files AND CRLF files were used are long over and since Python is NOT "C" it should reflect that. |
|
|
| msg62146 - (view) |
Author: Facundo Batista (facundobatista) *  |
Date: 2008-02-07 12:37 |
| O_TEXT is not obsolete, as the behaviour is different even in a win2k. >>> a = open("ubuntu-6.06.1-server-i386.iso") >>> len(a.read()) 46424 >>> a = open("ubuntu-6.06.1-server-i386.iso", "rb") >>> len(a.read()) 453132288 I agree that the default should be Binary. Note that this would break too much in Py2, so if happens it will need to be done in Py3. BTW, I don't know if this was already discussed, approved, rejected, etc. |
|
|
| msg62148 - (view) |
Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * |
Date: 2008-02-07 13:01 |
| > Windows has stopped to use CRLF files No, there are some places where a text file must be CRLF. To name a few: - Notepad - Visual Studio .sln files. > Days when majority of "C" codebase actually DID process text files > AND CRLF files were used are long over and since Python is NOT > "C" it should reflect that. Actually, python 3.0 goes even further from "C": - Python mostly deals with text files - text files will return (unicode) text data, decoded with a specified encoding (by default: 7bit ascii) Many unix programs will break anyway: if they want binary data, they will have to open files in binary mode. After that, they will run on Windows with no modification. |
|
|
| msg62150 - (view) |
Author: Zdeněk Pavlas (zde) |
Date: 2008-02-07 13:56 |
| > if they want binary data, they will have to open files in binary mode. There were binary files. *THEN* dos and mac came with text files. To keep the *ORIGINAL* semantics we have to add *NEW* flags to open/fopen. Looks we'll run out of O_ bitfields and letters quite soon. 64bit words and unicode alphabet finally start to make sense... :) |
|
|
| msg62151 - (view) |
Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * |
Date: 2008-02-07 14:12 |
| Exactly. First computer files were filled with numbers, then with English words, then with accented letters now with kanjis. Imagine that "binary" is a kind of language. And not spoken by many people anymore ;-) |
|
|
| msg62183 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2008-02-07 21:27 |
| I'll close this issue as rejected. As discussed, changing it in 2.x would be incompatible. To change the default for open in 3.x to return bytes instead of character string (i.e. open files in binary) would require convincing Guido van Rossum, which is unlikely to happen. |
|
|
| msg103122 - (view) |
Author: anatoly techtonik (techtonik) |
Date: 2010-04-14 12:43 |
| Why Guido can't speak for py3k here in personal? I've just wasted two days debugging this O_BINARY flag when HgGit stopped to work on windows. https://bugs.edge.launchpad.net/dulwich/+bug/557585 We need at least document this for os.open() properly. |
|
|