[Python-Dev] buffer object

[Finn Bock]

[Greg Stein]

>IMO, extensions should be using the buffer object for raw bytes. I know
>that Mark has been updating some of the Win32 extensions to do this.
>Python programs could use the objects if the buffer() builtin is tweaked
>to allow a bit more flexibility in the arguments.

Forgive me for rewinding this to the very beginning. But what is a
buffer object usefull for? I'm trying think about buffer object in terms
of jpython, so my primary interest is the user experience of buffer
objects.

Please correct my misunderstandings.

- There is not a buffer protocol exposed to python object (in the way
  the sequence protocol __getitem__ & friends are exposed).
- A buffer object typically gives access to the raw bytes which
  under lays the backing object. Regardless of the structure of the
  bytes.
- It is only intended for object which have a natural byte storage to
  implement the buffer interface.
- Of the builtin object only string, unicode and array supports the
  buffer interface.
- When slicing a buffer object, the result is always a string regardless
  of the buffer object base.


In jpython, only byte arrays like jarrays.array('b', [0,1,2]) can be
said to have some natural byte storage. The jpython string type doesn't.
It would take some awful bit shifting to present a jpython string as an
array of bytes.

Would it make any sense to have a buffer object which only accept a byte
array as base? So that jpython would say:

>>> buffer("abc")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: buffer object expected


Would it make sense to tell python users that they cannot depend on the
portability of using strings (both 8bit and 16bit) as buffer object
base?


Because it is so difficult to look at java storage as a sequence of
bytes, I think I'm all for keeping the buffer() builtin and buffer
object as obscure and unknown as possible <wink>.

regards,
finn