[Python-Dev] strop vs. string (original) (raw)

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