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

[Tim Peters]

[Tim]
> 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.

[M.-A. Lemburg]
> 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.

How do you use buffers?  Do you stick to their C API?  Do you use the
Python-level buffer() function?  If the latter, what do you do in Python
code with a buffer object after you get one?  The only use I've seen made of
a buffer object in Python code is as a way to trick the interpreter into
crashing (via recycling the memory the buffer object points to).

And from where do you get a buffer?  There are darned few types in Python
that buffer() accepts as an argument.  Do your extension types implement
tp_as_buffer?  I'm blindly casting for a reason why your appreciation of the
buffer object seems unique.

> 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.

Overall, this reinforces the repeated observation that we don't know why the
buffer object exists -- it doesn't appear to do what you really want, but
you've found some way to get it to do part of what you want, up until the
point you actually use it <0.7 wink>.