[Python-Dev] strop vs. string

Paul Barrett Barrett@stsci.edu
Fri, 25 May 2001 09:21:20 -0400


"M.-A. Lemburg" wrote:
> 
> > > BTW, wouldn't it suffice to add these methods to buffer objects ?
> > > Then you could write: buffer(ob).find('.').
> >
> > You're totally missing the point with that suggestion. It does *not*      > > suffice to add them to buffer objects. What about array objects? mmap      > > objects?  Random Joe Object who implements the buffer interface?
> 
> That's the point: you can wrap all those into a buffer object
> and then use the buffer object methods to manipulate them. In
> that sense, buffer objects provide an adaptor to the underlying
> object which implements the needed methods.

Sounds like you are trying to make the buffer object into something it
is not. Not that I have the foggiest idea what it is now, since it
hasn't much use and is badly broken.

I like your idea of sharing functions, I just don't think the buffer
object is the proper means.  I think the buffer object should be
removed from Python and something better put in its place. (I'm not
talking about the buffer C/API, though this could also use an
overhaul, since it doesn't provide enough information to the receiving
method.)

What I think we need is:

1) a malloc object which has a similar interface to the mmap object
with access protection, etc.  This object would be the fundamental way
of getting memory.  The string object would use it to allocate a chunk
of 'read-only' memory.  Other objects would then know not to modify
the contents of the memory.  If you wanted a reference or view of the
memory/buffer, you would get a reference to this object.

2) objects supporting the buffer object should provide a view method
which returns a copy of themselves (and hence all their methods) and
can be used to get a pointer to a subset of its memory.  In this way
the type of memory/buffer being accessed is known compared to the
current buffer object which only indicates the buffer is binary or
char data.  In essence information about how the buffer should be used
is lost in the current buffer C/API.

-- 
Paul Barrett, PhD      Space Telescope Science Institute
Phone: 410-338-4475    ESS/Science Software Group
FAX:   410-338-4767    Baltimore, MD 21218