[Python-Dev] PEP 298

Martin v. Löwis martin@v.loewis.de
12 Dec 2002 21:42:17 +0100


Thomas Heller <theller@python.net> writes:

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

This is counter-intuitive, and under-specified. What does it mean that
"it's no longer used"? My code uses the buffer until system exit, so I
never need to release the buffer. I don't release the string, either,
since that was an element of ParseTuple, of which I only acquired the
buffer.

It doesn't talk about the object "being used", just "the buffer". The
spec should not prescribe under what conditions some API must be
invoked, but instead it should describe what happens if the API is
invoked.

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

I would prefer such an implementation strategy, and I would prefer if
the spec clarifies that the caller of acquire will keep the object
alive atleast until the corresponding release is called.

That, of course, means that it is no longer an option to not implement
release.

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

Ok, so this actually *is* an interface to some existing object. Which
one?

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

Then I would suggest that you withdraw it. To me, it sounds useless
unless significantly enhanced.

Regards,
Martin