[Python-Dev] str object going in Py3K (original) (raw)

Guido van Rossum guido at python.org
Tue Feb 14 20:07:09 CET 2006

On 2/14/06, Fuzzyman <fuzzyman at voidspace.org.uk> wrote:

In Python 3K, when the string data-type has gone,

Technically it won't be gone; str will mean what it already means in Jython and IronPython (for which CPython uses unicode in 2.x).

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.

Will the object returned have a decode method, to coerce to a unicode string ?

No, the object returned will be a (unicode) string.

But a bytes object (returned by a binary open operation) will have a decode() method.

Also, what datatype will u'some string'.encode('ascii') return ?

It will be a syntax error (u"..." will be illegal).

The str.encode() method will return a bytes object (if the design goes as planned -- none of this is set in stone yet).

I assume that when the bytes datatype is implemented, we will be able to do open(filename, 'wb').write(bytes(somedata)) ? Hmmm... I probably ought to read the bytes PEP and the Py3k one...

Sort of (except perhaps we'd be using openbinary(filename, 'w")). Perhaps write(somedata) should automatically coerce the data to bytes?

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list