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/