[Python-Dev] str object going in Py3K

[Guido van Rossum]

On 2/14/06, Just van Rossum <just at letterror.com> wrote:
> Guido van Rossum wrote:
> > [...] 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.

It's still backwards because the current open function defaults to
text on Windows (the only platform where it matters any more).

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

And then, on 2/14/06, Alex Martelli <aleaxit at gmail.com> wrote:
> What about shorter names, such as 'text' instead of 'opentext' and
> 'data' instead of 'openbinary'?  By eschewing the 'open' prefix we
> might make it easy to eventually migrate off it. Maybe text and data
> could be two subclasses of file, with file remaining initially as it
> is (and perhaps becoming an abstract-only baseclass at the time 'open'
> is deprecated).

Plain 'text' and 'data' don't convey the fact that we're talking about
opening I/O objects here. If you want, we could say textfile() and
datafile(). (I'm fine with data instead of binary.)

But somehow I still like the 'open' verb. It has a long and rich
tradition. And it also nicely conveys that it is a factory function
which may return objects of different types (though similar in API)
based upon either additional arguments (e.g. buffering) or the
environment (e.g. encodings) or even inspection of the file being
opened.

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