[Python-Dev] marshal (was:Buffer interface in abstract.c? )

M.-A. Lemburg mal@lemburg.com
Sat, 14 Aug 1999 01:15:39 +0200


Greg Stein wrote:
> 
> On Tue, 10 Aug 1999, Fredrik Lundh wrote:
> > maybe the unicode class shouldn't implement the
> > buffer interface at all?  sure looks like the best way
> 
> It is needed for fp.write(unicodeobj) ...
> 
> It is also very handy for C functions to deal with Unicode strings.

Wouldn't a special C API be (even) more convenient ?

> > to avoid trivial mistakes (the current behaviour of
> > fp.write(unicodeobj) is even more serious than the
> > marshal glitch...)
> 
> What's wrong with fp.write(unicodeobj)? It should write the unicode value
> to the file. Are you suggesting that it will need to be done differently?
> Icky.

Would this also write some kind of Unicode encoding header ?
[Sorry, this is my Unicode ignorance shining through... I only
 remember lots of talk about these things on the string-sig.]

Since fp.write() uses "s#" this would use the getreadbuffer
slot in 1.5.2... I think what it *should* do is use the
getcharbuffer slot instead (see my other post), since dumping
the raw unicode data would loose too much information. Again,
such things should be handled by extra methods, e.g. fp.rawwrite().

Hmm, I guess the philosophy behind the interface is not
really clear. Binary data is fetched via getreadbuffer and then
interpreted as character data... I always thought that the
getcharbuffer should be used for such an interpretation.

Or maybe, we should dump the getcharbufer slot again and
use the getreadbuffer information just as we would a
void* pointer in C: with no explicit or implicit type information.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Y2000:                                                   140 days left
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/