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.