[Python-Dev] str object going in Py3K
Guido van Rossum
guido at python.org
Wed Feb 15 19:29:30 CET 2006
More information about the Python-Dev mailing list
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 ]
More information about the Python-Dev mailing list