[MAL]
> I guess there are three ways to "solve" this:
>
> a) mutable types don't implement the getreadbuf interface
Of the few types that implement it today, that would leave only strings
(8-bit and Unicode). Too much machinery just for that. Besides, I once
posted an example to c.l.py showing how to use regexps to search mmap'ed
files, so *that* must continue to work forever <wink>.
> b) the getreadbuf interface is complemented with a callback
> interface, so the the buffer object can be notified of
> the change
I like this best, although there's no bound on the number of buffers that
may need to be notified in case of change (i.e., the object would need to
maintain a list of buffers to be notified).
> c) calling getreadbuf on a mutable object causes this object
> to become immutable
Even easier, core dump as soon as getreadbuf is called <wink>.
[Greg Ewing]
> I think it would be safe if:
>
> 1) it kept a reference to the underlying object, and
That much it already does.
> 2) it re-fetched the pointer and length info each time it was
> needed, using the underlying object's buffer interface.
If after
b = buffer(some_object)
b.__getitem__ needed to refetch the info between
b[i]
and
b[i+1]
I expect it would be so slow even Greg wouldn't want it anymore.
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