Message12190

The fact that we have only one (internal) BufferProtocol makes this tricky to solve. We cannot remove it from PyArray, or it ceases to support buffer(). And not just buffer, since an array.array is accessed as bytes in several other places in the core.

After a bit of deep thinking, I realised that the tool for this is the flags argument passed to getBuffer(). memoryview asks for a structured view (FULL) because it can understand the navigational arrays, while buffer insists on flat bytes (SIMPLE). So we make PyArray.getBuffer reject requests for structured data. However, this implies that wherever we use the buffer API to access bytes (except in PyMemoryview) we need to ask for flat bytes, or it will stop working for array.array. We haven't always done that. (I always found it difficult to decide.)

I've gone for throwing a ClassCastException from the getBuffer() where we implement BufferProtocol as far as Java is concerned, but don't *really* implement it. I though this an odd choice, but it turns out to work quite well. I tried raising a TypeError directly, but one cannot give it the right message at that point, and it is awkward to catch in Java. Clients of the buffer interface already create the right kind of message, and just need to do it as well when a ClassCastException is thrown.

We can use the same approach for disabling PyUnicode.getBuffer. (I have.) However, there are places where the buffer protocol is used to retrieve the characters of a PyUnicode on the (unconcious) assumption they are bytes, and these have to be reworked to accept PyUnicode consciously and do the right thing. I'm not sure I've found all the right places: the regression tests don't cover it very well.

All this adds up to a sprawling change set, but often the change to a file is not large.
https://hg.python.org/jython/rev/616f1bbd4ec9