[Python-Dev] Guarantee the success of some object creation C API functions

Terry Reedy tjreedy at udel.edu
Mon May 1 16:52:49 EDT 2017


On 5/1/2017 5:50 AM, Serhiy Storchaka wrote:
> I want to add promises to public C API functions that create trivial
> instances of immutable basic types (integers 0 and 1, empty tuple,
> string and bytes object) -- PyLong_FromLong(0), PyLong_FromLong(1),
> PyTuple_New(0), PyUnicode_FromStringAndSize(NULL, 0),
> PyUnicode_FromString(""), PyBytes_FromStringAndSize(NULL, 0),
> PyBytes_FromString("") -- that they always succeed and never return
> NULL. Currently they always or almost always succeed, but this is an
> implementation detail. I want to make this promise official and more
> strong, so that it is true even at very early stage of the interpreter
> intitalization and at very late stage of the finalization. Also I want
> to add private references to singletons that represent these values
> (_PyLong_Zero, _PyTuple_Empty, etc) similar to Py_None and Py_True.
> This could make some code clearer. For example see [1] and [2].
> 
> These promises add limitations for future changes of the interpreter,
> but the official promise decreases the probability of unintentional
> changes that break implicit properties.

The promise makes it clear that breaking the property is a bug to be 
fixed.  It only decreases the probability for someone who has read the 
promise.  Unfortunately, 'never fail' is hard to test ;-).

> Do I have the right to give such promises?

By yourself, I would think not.  With a couple of coredev concurrences, 
and none against, maybe.  But I think the following does need to be 
asked publicly, here, so implementors of CPython alternatives have a 
chance to respond.

 > Are there any reasons that might prevent their implementation?
If the answer is no, I think the simplifications in the following are a 
good argument for the change.  On the other hand, I have to wonder why 
there were not made previously.

> [1] https://bugs.python.org/issue29878
> [2] https://bugs.python.org/issue30162

-- 
Terry Jan Reedy



More information about the Python-Dev mailing list