On Fri, Nov 21, 2008 at 5:34 PM, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Benjamin Peterson wrote: >> On Fri, Nov 21, 2008 at 1:41 PM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: >>> In the past, we've always tried to provide abstract access methods to >>> C struct internals of Python objects and I wonder whether this was >>> deliberately not done for Py_buffer structs or simply not considered. >>> >>> I don't think it's a good idea to use my_Py_buffer->buf in a C >>> extension and would rather like to write: >>> >>> Py_Buffer_AS_BUFFER(my_Py_buffer) >>> Py_Buffer_GET_SIZE(my_Py_buffer) >>> Py_Buffer_GET_ITEM_SIZE(my_Py_buffer) >>> etc. >> >> I think that's a good idea, too, and we should get something like that >> in for 3.1. I rather feel like the new buffer API slipped in without >> any real review. > > The review that was done was actually quite extensive - see PEP 3118. > However: > 1. There's a reason 3118 is still at accepted rather than final - the > major foundations (and the all-important underlying protocol) are in > place, but there are finishing touches still needed. > 2. The review of the PEP focused on the power and capabilities of the > underlying protocol and less on the aesthetics of the C API.
I'm not talking necessarily about the PEP and API. I find the implementation confusing and contradictory in some places. > > The PEP was fairly explicit that the fields in the Py_buffer struct were > public and accessed directly via C syntax though, as are the current > docs (http://docs.python.org/dev/3.0/c-api/buffer.html). Well, I wrote those based on the PEP. :) -- Cheers, Benjamin Peterson "There's nothing quite as beautiful as an oboe... except a chicken stuck in a vacuum cleaner." _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
