[Python-Dev] str object going in Py3K (original) (raw)
Guido van Rossum guido at python.org
Wed Feb 15 19:29:30 CET 2006
- Previous message: [Python-Dev] str object going in Py3K
- Next message: [Python-Dev] str object going in Py3K
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 2/15/06, M.-A. Lemburg <mal at egenix.com> wrote:
Barry Warsaw wrote: > On Wed, 2006-02-15 at 18:29 +0100, M.-A. Lemburg wrote: > >> Maybe a weird idea, but why not use static methods on the >> bytes and str type objects for this ?! >> >> E.g. bytes.openfile(...) and unicode.openfile(...) (in 3.0 >> renamed to str.openfile()) > > That's also not a bad idea, but I'd leave off one or the other of the > redudant "open" and "file" parts. E.g. bytes.open() and unicode.open() > seem fine to me (we all know what 'open' means, right? :).
Thinking about it, I like your idea better (file.bytes() and file.text()).
This is better than making it a static/class method on file (which has the problem that it might return something that's not a file at all -- file is a particular stream implementation, there may be others) but I don't like the tight coupling it creates between a data type and an I/O library. I still think that having global (i.e. built-in) factory functions for creating various stream types makes the most sense.
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
- Previous message: [Python-Dev] str object going in Py3K
- Next message: [Python-Dev] str object going in Py3K
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]