[Image-SIG] Proper application of the buffer interface

Fred L. Drake, Jr. Fred L. Drake, Jr." <fdrake@cnri.reston.va.us
Thu, 5 Aug 1999 11:07:39 -0400 (EDT)

Mark Hammond writes:
 > The good news is that it is most common for extension modules to spell
 > "give me a string with the raw binary data" as "PyArg_ParseTyple("s#",
 > ...);".  PyArg_ParseTuple has been upgraded to use the buffer interfaces,

  This is really cool.  Buffers are probably what I want, then; the
question is starting to become whether to use a buffer object or to
create a new object that implements the buffer interface.  I think I
can handle that!  (And it's looking like implementing a new C type,
for those following t1python.)

 > The problem remains, of course, for extensions that use the
 > PyString_Check(), PyString_AsString() etc functions.  If they were upgraded
 > to use the buffer interfaces, then the transition would be complete.

  Understandable; this is the price of using the lowest-level concrete 
object interfaces.

 > strings for this purpose, but clearly indicate the data is not really a
 > string!  This appears to be more a matter of style, and also paves the road
 > to Unicode - eg, it makes sense to convert any Python string object to
 > Unicode, but not necessarily a binary buffer.

  This is a compelling argument for the buffer type/interface in my
book.  I won't be happy until Unicode strings are in the core!  (No,
I'm not holding out for Unicode strings to replace the current string
type, just that they be in the core and well-supported.)

 > Probably Greg and Guido are the only 2 with the real insight, as they
 > threashed out the details.  But Im pretty happy with my understanding (as
 > detailed above) of the issues.

  Your elucidation on the topic is excellent; if you'd like to write a 
section for the "Extending & Embedding" manual regarding when to
implement the buffer interface and when to use it, I'd certainly be
glad to mark it up and integrate it.  ;-)
  (Greg: No, this wouldn't get you off the hook for reference material!)


Fred L. Drake, Jr. <fdrake@cnri.reston.va.us>
Corporation for National Research Initiatives