[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 mailing list