[Python-Dev] PEP 298, final (?) version

[Scott Gilbert]

--- Aahz <aahz@pythoncraft.com> wrote:
>
> <whew!>  I finally read all these threads today, cleaning out much of my
> OSCON backlog.  Now, maybe I'm stupid, but I'm not understanding the
> relationship between the new buffer protocol (PEP 298) and the new bytes
> object (PEP 296).  Should this be something documented in one or both
> PEPs?
>

In the course of examining PEP 296 (the one I'm working on), Thomas Heller
thought it would be a good idea to make some additions to PyBufferProcs and
abstract.h so that he, and others, could treat a wider class of objects
with one API.  I was only proposing the bytes object, where as he wanted to
be able to write code that works with bytes, string, mmap, array, and any
other buffer-like object uniformly (since they all make promises about the
lifetime of the pointer).

I liked his idea but was concerned that making additional changes to the
Python baseline might get received poorly.  In other words, I'm an
overconservative worrywort, and wanted to make sure I didn't sink PEP 296
with features of PEP 298.  As such, I encouraged him to submit a separate
PEP so that if the protocol part got sunk, the bytes object part could
remain.  He was probably sick of arguing with me at that point, so PEP 298
got created.

Guido apparently likes both PEPs, so it looks like both will get in if our
implementations are timely and don't suck.  If I could have channeled Guido
a week ago, there might be only one PEP.  However, with the way this played
out, it has the benefit (to me at least) that now Thomas Heller is on the
hook for part of the implementation.  :-)


As for documenting this, my next draft of PEP 296 (later tonight) will
refer to PEP 298 to indicate that the bytes objects will support the
"fixed/locked buffer protocol".

Cheers,
    -Scott





__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com