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/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4