[Python-Dev] strop vs. string

M.-A. Lemburg mal@lemburg.com
Thu, 24 May 2001 12:18:50 +0200


Greg Stein wrote:
> 
> 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.

I suppose that in 2.2 we'll be able to build a class/type
hierarchy which then provides these possibilities. I haven't
followed Guido's latest checkins closely though -- could be that
types don't support multiple inheritence.

BTW, wouldn't it suffice to add these methods to buffer objects ?
Then you could write: buffer(ob).find('.').

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/