On 2/14/06, Just van Rossum <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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/) _______________________________________________ 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
