Thomas Heller <theller@python.net> writes: > > - 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. This is flawed. According to the PEP, an object which has acquirelockedbuffer called will live forever: # Retrieving a buffer from an object puts this object in a locked # state during which the buffer may not be freed, resized, or # reallocated. But now you are saying that the object can be released even in locked state. > > 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. I see. I didn't know that. However, having to copy a string to an array to obtain its address is not obvious; putting it into the buffer objects seems more logical - especially if the buffer claims to be *locked*. > 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. If it is just the interface, I'm -1. You don't need a PEP to define an interface in Python - just establish an interface in the types you care about. If you really mean to implement it primarily for some type of yours, just do so (it' can't be *exactly* this interface, but you can have the same operations, just in a different place). Regards, Martin
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