[Python-Dev] Generalised String Coercion
James Y Knight
foom at fuhm.net
Tue Aug 9 02:56:51 CEST 2005
On Aug 8, 2005, at 12:14 PM, Guido van Rossum wrote:
> Ouch. Too much discussion to respond to it all. Please remember that
> in Jythin and IronPython, str and unicode are already synonyms. That's
> how Python 3.0 will do it, except unicode will disappear as being
> redundant. I like the bytes/frozenbytes pair idea. Streams could grow
> a getpos()/setpos() API pair that can be used for stateful encodings
> (although it sounds like seek()/tell() would be okay to use in most
> cases as long as you read in units of whole lines). For sockets,
> send()/recv() would deal in bytes, and makefile() would get an
> encoding parameter. I'm not going to change my mind on text() unless
> someone explains what's so attractive about it.
Files no more have an encoding than sockets do. Reading/writing them
should ideally (by default) result in bytes. codecs.open and
codecs.StreamReaderWriter provide the character-converting wrapper
around file-like objects.
I agree that getpos/setpos may be a useful addition to the API, but
only because it would allow StreamReaderWriter to override it to do
something useful. For normal files it could simply be an alias for
tell/seek. Of course, someone would have to actually implement the
ability to save and restore state for every codec...
Hum, actually, it somewhat makes sense for the "open" builtin to
become what is now "codecs.open", for convenience's sake, although it
does blur the distinction between a byte stream and a character
stream somewhat. If that happens, I suppose it does actually make
sense to give "makefile" the same signature.
More information about the Python-Dev