> > void PyObject_ReleaseFixedBuffer(PyObject *obj); > > > > Would it be useful to allow bf_releasefixedbuffer to return an int > indicating an exception? For instance, it could raise an exception if the > extension errantly releases more times than it has acquired (a negative > lock count). Just a thought. OTOH, it means that the caller would have to check for errors. It may make more sense to make this a fatal error, since it's purely the (or at least *a*) caller's fault. > > Python strings, unicode strings, mmap objects, and array objects > > would expose the fixed buffer interface. > > > > mmap and array objects would actually enter a locked state while > > the buffer is active, this is not needed for strings and unicode > > objects. Resizing locked array objects is not allowed and will > > raise an exception. Whether closing a locked mmap object is an > > error or will only be deferred until the lock count reaches zero > > is an implementation detail. > > The mmap object is a good candidate for this, but I'm a little worried > about adding it to array. I'm not saying it shouldn't be done, but I can > imagine a surprized user who: > > - has an existing application using the array module > - starts making use of a new extension that uses the fixed/locked > buffer interface > - gets an exception in code that never raised that exception before Hm. As long as it's not too hard to point out the cause (using the new extension) I don't think this would be a problem. --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