Guido van Rossum wrote: > > what will > > ``open(filename).read()`` return ? > > Since you didn't specify an open mode, it'll open it as a text file > using some default encoding (or perhaps it can guess the encoding from > file metadata -- this is all OS specific). So it'll return a string. > > If you open the file in binary mode, however, read() will return a > bytes object. I'm currently considering whether we should have a > single open() function which returns different types of objects > depending on a string parameter's value, or whether it makes more > sense to have different functions, e.g. open() for text files and > openbinary() for binary files. I believe Fredrik Lundh wants open() to > use binary mode and opentext() for text files, but that seems > backwards -- surely text files are more commonly used, and surely the > most common operation should have the shorter name -- call it the > Huffman Principle.
+1 for two functions. My choice would be open() for binary and opentext() for text. I don't find that backwards at all: the text function is going to be more different from the current open() function then the binary function would be since in many ways the str type is closer to bytes than to unicode. Maybe it's even better to use opentext() AND openbinary(), and deprecate plain open(). We could even introduce them at the same time as bytes() (and leave the open() deprecation for 3.0). Just _______________________________________________ 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/archive%40mail-archive.com
