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

[Mark Hammond]

> 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.  Scott apparently
> doesn't have this problem with his own code, so his opinion doesn't
> help. :-(

There may be some breakage in the Win32 overlapped IO world.  A common
pattern is:

  buf = allocate_buffer_somehow(size)
  Perform_Async_Read(size)
  #  wait for notification of read completing
  nbytes = Wait_For_Read_Notification()
  data = buf[:nbytes]

Currently, "data" is a string.  Changing this to a buffer object will
presumably break this code once "data" is passed to some other function that
truly requires a string.

> Maybe the name 'buffer' suggests false expectations?  It's not a
> buffer, it's an alias for a memory area.

This distinction is a little gray.  In my example, it is truly a buffer -
but also an alias for a memory area.  In my example though, it is *not*
conceptually an alias for memory owned by another object.

> Maybe we should do something stronger, and deprecate the buffer type
> altogether.

Maybe.  However, as you have seen over the years, *something* from all this
mess is a real requirement.  This example of asynch IO is the only example I
have ever used, but IMO, it is a real and reasonable requirement.  My
example *could* have been done with array() (assuming the array module had a
C API exposed which it doesn't/didn't) but that too looks like a square peg
in a round hole - my requirements call for a pre-allocated byte buffer, not
an array.

All that said: if the worst came to the worst, I could ensure that the Win32
extensions are left compatible with the way they are.  All such buffers are
allocated using a function inside one of my modules.  Currently this just
returns a buffer() object, but could be changed to a private object with the
same semantics as the existing buffer() object.  So consider this more a
data point than an attempted veto.

Mark.