[Python-Dev] PEP 298

[Martin v. Löwis]

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