[Python-Dev] strop vs. string

[Fred L. Drake, Jr.]

Paul Barrett writes:
 > From the discussion so far, it appears that the buffer object is
 > intended solely to support string-like objects.  I've seen no mention
 > of their use for binary data objects, such as multidimensional arrays
 > and matrices.  Will the buffer object also support these objects?  If
 > no, then I suggest it be renamed to one that is less generic and more
 > descriptive.

  In a development version of my bindings to a Type-1 font rasterizer,
I exposed a buffer interface to the resulting image data.
Unfortunately, that code was lost and I've not had time to work that
up again.  I *think* that sort of thing was part of the intended
application for the buffer interface, but I was not one of the "movers
& shakers" for it, so I'm not entirely sure.

 > On the otherhand, if yes, then I think the buffer C/API needs to be
 > reimplemented, because the current design/implementation falls far
 > short of what I would expect for a buffer object.  First, it is overly
 > complex: the support for multiple buffers does not appear necessary. 
 > Second, the dangling pointer issue has not been resolved.  I suggest

  I agree.  From the discussions I remember, I don't recall a clear
explanation of the need for "segmented" buffers.  But that may just be
a failing of my recollection.

 > the addition of lock flag which indicates that the data is currently
 > inaccessible, ie. that data and/or data pointer is in the process of
 > being modified.
 > 
 > I would suggest the following structure to be much more useful for
 > char and binary data:
 > 
 > typedef struct {
 >     char* rf_pointer;
 >     int   rf_length;
 >     int   rf_access;  /* read, write, etc.  */
 >     int   rf_lock;    /* data is in use  */
 >     int   rf_flags;   /* type of data; char, binary, unicode, etc.  */
 > } PyBufferProcs;

  I'm not sure about the "rf_flags" field -- I see two aspects that
you seem to be describing, and wouldn't call either use a "flag".
There's data type (characters, anonymous binary data, image data,
etc.), and element size (1 byte, 2 bytes, variable width).  Those
values may or may not be associated with the specific buffer or the
type implementing the buffer (I'd go with the specific buffer just to
allow buffer types that support different flavors).

 > If I find some time, I'll prepare a PEP to air these issues, since
 > they are very important to those of us working on and with
 > multidimensional arrays. We find the current buffer API lacking.

  PEPs are good; I'll look forward to seeing it!


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Digital Creations