> > I intend to work on the PEP 298 (locked buffer interface) > > implementation, with the hope that it is not too late to bring this > > into 2.3. Is there still a chance? > > Having looked at the PEP for the first time, I have a number of > comments: [Martin, I rearranged your questions] > - How will string objects implement that interface? In particular, > what prevents the refcount of the string dropping to zero? > It is required to unlock the buffer again after you don't need it any longer. You do this by calling the releaselockedbuffer() function with the pointer to the original python object. So the object haas to keep alive. > > - I think there must be a way to obtain the address of the buffer on > the Python level, see > > http://tinyurl.com/3h79 > > Using /dev/poll on Solaris requires a way to create a struct whose > address you know. Hm, the usual hacky way is to use an array object and call buffer_info() on it. > > - There must be a Python-level API to obtain a locked buffer. > That may be, but the PEP only describes the interface. Extensions may implement a 'locked buffer object', or whatever, and expose the address to Python. Dangerous, though, because then you can separate the python oobject pointer and the buffer pointer. Thomas
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