[Python-Dev] str object going in Py3K (original) (raw)
Just van Rossum just at letterror.com
Tue Feb 14 21:35:50 CET 2006
- Previous message: [Python-Dev] str object going in Py3K
- Next message: [Python-Dev] PEP 332 revival in coordination with pep 349? [ Was:Re: release plan for 2.5 ?]
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [Python-Dev] str object going in Py3K
- Next message: [Python-Dev] PEP 332 revival in coordination with pep 349? [ Was:Re: release plan for 2.5 ?]
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]