_fmode = O_TEXT is obsolete

[zde]

BPO	2028
Nosy	@loewis, @facundobatista, @amauryfa

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2008-02-07.21:27:08.738>
created_at = <Date 2008-02-07.12:21:44.237>
labels = ['type-bug', 'OS-windows']
title = '_fmode = O_TEXT is obsolete'
updated_at = <Date 2010-04-14.12:43:30.870>
user = 'https://bugs.python.org/zde'

bugs.python.org fields:

activity = <Date 2010-04-14.12:43:30.870>
actor = 'techtonik'
assignee = 'none'
closed = True
closed_date = <Date 2008-02-07.21:27:08.738>
closer = 'loewis'
components = ['Windows']
creation = <Date 2008-02-07.12:21:44.237>
creator = 'zde'
dependencies = []
files = []
hgrepos = []
issue_num = 2028
keywords = []
message_count = 7.0
messages = ['62144', '62146', '62148', '62150', '62151', '62183', '103122']
nosy_count = 5.0
nosy_names = ['loewis', 'facundobatista', 'amaury.forgeotdarc', 'techtonik', 'zde']
pr_nums = []
priority = 'normal'
resolution = 'rejected'
stage = None
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue2028'
versions = ['Python 3.0', 'Python 3.1', 'Python 3.2', 'Python 3.3']

[zde]

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.

[facundobatista]

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.

[amauryfa]

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.

[zde]

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... :)

[amauryfa]

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 ;-)

[loewis]

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.

[techtonik]

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.