[Python-Dev] buffer interface considered harmful

[Jim Fulton]

David Ascher wrote:
> 
> On Mon, 16 Aug 1999, Jim Fulton wrote:
> 
> > > Second, there's the extension the the buffer interface as of 1.5.2. This is
> > > again only available in C, and it allows C programmers to get an object _as an
> > > ASCII string_. This is meant for things like regexp modules, to access any
> > > "textual" object as an ASCII string. This is the getcharbuffer interface, and
> > > bound to the "t#" specifier in PyArg_ParseTuple.
> >
> > Hm. So this is making a little more sense. So, there is a notion that
> > there are "textual" objects that want to provide a method for getting
> > their "text". How does this text differ from what you get from __str__
> > or __repr__?
> 
> I'll let others give a well thought out rationale. 

I eagerly await this. :)

> Here are some examples
> of use which I think worthwile:
> 
> * Consider an mmap()'ed file, twelve gigabytes long.  Making mmapfile
>   objects fit this aspect of the buffer interface allows you to do regexp
>   searches on it w/o ever building a twelve gigabyte PyString.

This seems reasonable, if a bit exotic. :)

> * Consider a non-contiguous NumPy array.  If the array type supported the
>   multi-segment buffer interface, extension module writers could
>   manipulate the data within this array w/o having to worry about the
>   non-contiguous nature of the data.  They'd still have to worry about
>   the multi-byte nature of the data, but it's still a win.  In other
>   words, I think that the buffer interface could be useful even w/
>   non-textual data.

Why is this a good thing? Why should extension module writes 
worry abot the non-contiguous nature of the data now?  Does the NumPy
C API somehow expose this now?  Will multi-segment buffers make it
go away somehow?
 
> * If NumPy was modified to have arrays with data stored in buffer objects
>   as opposed to the current "char *", and if PIL was modified to have
>   images stored in buffer objects as opposed to whatever it uses, one
>   could have arrays and images which shared data.

Uh, and this would be a good thing? Maybe PIL should just be modified
to use NumPy arrays.
 
> I think all of these provide examples of motivations which are appealing
> to at least some Python users.

Perhaps, although Guido knows how they'd find out about them. ;)

Jim

--
Jim Fulton           mailto:jim@digicool.com   Python Powered!        
Technical Director   (888) 344-4332            http://www.python.org  
Digital Creations    http://www.digicool.com   http://www.zope.org    

Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email
address may not be added to any commercial mail list with out my
permission.  Violation of my privacy with advertising or SPAM will
result in a suit for a MINIMUM of $500 damages/incident, $1500 for
repeats.