> I see this interface as a bridge between objects offering generic buffer > oriented facilities (asynch or low level I/O for example) and objects that > want to make it possible to use these facilities on their data (text > buffers, multimedia buffers, numeric arrays) by yielding a pointer to their > otherwise internal data. > > The bridging code between the two objects is unrestricted Python code > that may cause memory to be moved around. If the buffer is relatively small, copying the data an extra time shouldn't be a problem, and you can use the old API. If the buffer is huge, you probably shouldn't want to move the buffer around in memory anyway, So I don't think your case for needing a lockable interface is very strong. --Guido van Rossum (home page: http://www.python.org/~guido/)
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