[Python-Dev] str object going in Py3K
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