[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