[Python-Dev] Fw: Behavior of buffer()

[M.-A. Lemburg]

Tim Peters wrote:
> {Guido, to Scott Gilbert]
> 
>>It seems we're still in the same boat.  It would be saner to change
>>buffer slices to return buffer objects, except for backward
>>compatibility.  I was hoping to hear from someone who uses buffer
>>objects and knows that this would break his code.
> 
> 
> Raymond did a survey on c.l.py, asking anyone who used buffer objects at
> *all* to speak up.  IIRC, he got no replies.  On Python-Dev, apart from
> musing whether they might conceivably use them, the only person who
> eventually said they actually used them was Marc-Andre.  Fredrik pressed for
> details, but we haven't seen any concrete use cases.  In the absence of the
> latter, it's impossible to guess what would be backward compatible for MAL's
> purposes.

For my purposes, the strategy buffer slice returns a buffer
would be more appropriate because it would save the buffer type
information across the slicing operation... I mean, you don't
want to get bananas when you slice an apple in real life either ;-)

I use buffers to mean: this is a chunk of binary data. The purpose
is to recognize this type of data for pickling via xml-rpc,
soap and other rpc mechanisms etc.

Strings don't provide this information (since they can be a mix of
text and binary data). Buffers are compatible enough with most tools
working on strings that they represent a good alternative to tag data
as being binary while not losing all the nice advantages of
strings. The downside is that most of these tools return their
results as strings :-(

Now it would be nice if at least the type itself would behave in a
sane way.

>>Maybe we should do something stronger, and deprecate the buffer type
>>altogether.
> 
> 
> I told everyone you forgot the essay you wrote suggesting this the last time
> this rose above everyone's pain threshold.  It's a comfort to know that my
> channeling powers have not diminished with exponentially advancing age
> <wink>:
> 
>      http://mail.python.org/pipermail/python-dev/2000-October/009974.html

Oh yeah, that was during the Unicode implementation wars... :-)

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
_______________________________________________________________________
eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,...
Python Consulting:                               http://www.egenix.com/
Python Software:                    http://www.egenix.com/files/python/