[Python-Dev] strop vs. string

[Greg Stein]

On Fri, May 25, 2001 at 09:21:20AM -0400, Paul Barrett wrote:
> "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.

The buffer object is intended to provide a Python-level object (with methods
and behavior) for any other object which exports the buffer API (but not
those particular methods/behavior).

It was added for Python 1.5.2, but did not keep up with the methods added to
the string object. Arguably, it is out of date rather than "[turning it
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.

"badly" is overstating the problem. It caches a pointer when it shouldn't.
This doesn't work well when using it with array objects or PIL's image
objects. Most objects, it is fine.

The buffer object is also very good for C/Python extensions and embedding
code. It provides a Python-level view on a block of memory. Using a string
object implies making a copy, and it removes the possibility for read/write
access to that memory.

And you state: "Not that I have the foggiest idea what it is now". If so,
then wtf are you making statements about the buffer object's behavior?

> 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.

You're talking about the buffer object that we have *today*.

It can refer to another object (i.e. the memory exposed via the other
object's buffer API), refer to memory, or it can allocate its own memory.
The buffer object can be marked read-only, or read-write.

> 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.

I'm not sure that I understand this paragraph.


No... what needs to happen is to have the bug in PyBufferObject fixed. Then
to refactor stringobject.c and stropmodule.c to move all of those
byte-oriented processing functions into a new file such as Python/byteops.c
(whatever; name isn't important). Ideally, stringobject.c and stropmodule.c
would be simple covers over the same functions.

Those functions can then be used by PyBufferObject to implement the rest of
the string methods on itself.


This would leave us at MAL's suggested point: via the buffer object, we can
perform all of the standard string methods/ops on any object that implements
the buffer API.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/