[Python-Dev] PEP 298

[Thomas Heller]

martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) writes:

> 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.
> 

But the PEP it continues to say:

    The object must be unlocked again by releasing the buffer if it's
    no longer used by calling another function in the locked buffer
    interface.

Also, an easy solution to keep the string object alive forever
would be to Py_INCREF() in the acquirebuffer() function, and
Py_DECREF() in releasebuffer() again.

> > >   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).

That's what I have done, since I need it *now*, and in 2.2.

I just did not want the PEP to collect too much dust: it should
either be implemented or just die.

Once again: the whole point of the PEP is to avoid the flaws of the
'old' buffer interface.

Thomas