[Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Modules stropmodule.c,2.81,2.82

Greg Stein gstein@lyra.org
Thu, 24 May 2001 01:33:49 -0700


On Mon, May 14, 2001 at 07:14:46PM -0700, Guido van Rossum wrote:
> Update of /cvsroot/python/python/dist/src/Modules
> In directory usw-pr-cvs1:/tmp/cvs-serv26415/Modules
> 
> Modified Files:
> 	stropmodule.c 
> Log Message:
> Add warnings to the strop module, for to those functions that really
> *are* obsolete; three variables and the maketrans() function are not
> (yet) obsolete.
> 
> Add a compensating warnings.filterwarnings() call to test_strop.py.
> 
> Add this to the NEWS.

Something that I ran into the other day...

>>> ob = some_object_implementing_the_buffer_interface
>>> string.find(ob, '.')
(fails because ob does not define the .find method)
>>> strop.find(ob, '.')
(succeeds)


The point is that strop uses the t# to get a ptr/len pair to do its work.
Thus, it can work on many things that export the buffer interface. Dropping
strop means we no longer have many of those functions. Instead, the
functionality must be copied to *every* object that implements the buffer
interface.

We can say ob.find() now, but we can't say find(ob) any longer. And saying
that all objects (which implement the buffer API) must now implement a bunch
of "standard" methods is awfully burdensome.

In my particular case, I was trying to do a find on a BufferObject referring
to a subset of another object. Blam. No good. Thankfully, when I did a
find() on a mmap object, it worked simply because mmaps happen to define a
.find method.

[ of course, the find method on an mmap was totally broken, but I checked in
  a fix for that (last week or so) ]


So... my question is: is there any way that we can retain a generic find()
(and similar functions from the string/strop module) that operates on any
type that implements the buffer API?

Maybe there is some way we can do a mixin for Python types? e.g. "this mixin
implements some standard methods for 8-bit character data (using the buffer
API), which can be mixed into new Python types" That would reduce the burden
for new types.

Thoughts?

Cheers,
-g

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