[Python-Dev] Silent Deprecation Candidate -- buffer()

[Tim Peters]

[Tim]
>> Guido's last essay on the buffer interface is still worth reading:
>>
>>   http://mail.python.org/pipermail/python-dev/2000-October/009974.html
>>
>> No progress on the issues discussed has been made since, and, to the
>> contrary, recent changes go in directions Guido didn't want to go.

[Raymond Hettinger]
> He sent me to you guys for direction.

That's only because he forgot he wrote the essay -- it's my job to remember
what he did <wink>.

> The change was based on the advice I got.

Wasn't that an empty set?

> The point is moot because a) it's not too late to change course
> to returning all buffer objects, b) because almost nobody uses it
> anyway, and c) it all should probably be deprecated.

In effect, it's been "silently deprecated" since before Guido wrote the
above.

> ...
> Perhaps full deprecation (of the Python API not the C API) is in order.

Someone will whine if that's done.  Everyone's sick of fighting these
battles.  The buffer object is broken, won't get fixed (if it hasn't been by
now ...), and nobody seems to have a real use for it; but, *because* it's
virtually unused, "don't ask, don't tell" remains a path of small
resistance.

> It's just one fewer item in the Python concept space.  Besides mmap()
> and iterators have already addressed some of the original need.

I don't know what the original need was, but suspect it was never addressed.
IIRC, the real expressed need had something to do with running code objects
directly out of mmap'ed files, presumably on memory-starved platforms.  As
Guido said in his essay, "the reason" for the buffer object's existence
isn't clear, so whether the original need has been met, or could be met in
other ways now, isn't clear either.  Since it remains unused, if there is a
need for it, it's a peculiar meaning for "need".