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

[Brett Cannon]

On Mon, 1 May 2017 at 21:19 Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 2 May 2017 at 07:52, Chris Angelico <rosuav at gmail.com> wrote:
> > On Tue, May 2, 2017 at 6:52 AM, Terry Reedy <tjreedy at udel.edu> wrote:
> >> 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 ;-).
> >>
> >
> > Aside from straight-up bugs, how can one of these functions fail? Is
> > memory allocation failure the only way? If so, the proposed
> > implementation (private references to pre-created singletons) ought to
> > guarantee that, to the exact extent that anything else can be
> > guaranteed.
> >
> > (Or is that your point - that "never fail" is always "modulo bugs"?)
> >
> > Incidentally, this guarantee, if implemented the obvious way, will
> > also mean that (), "", 0, etc are singletons. People talk casually
> > about the "empty tuple singleton", but I don't think it's actually
> > guaranteed anywhere.
>
> I don't think it is either, and I don't think it's a guarantee we want
> to make - even with Serhiy's proposed change, it's still
> straightforward to produce non-singleton instances of these values
> using the low level C APIs, while the true singletons (True, False,
> None, Ellipsis) go out of their way to make it difficult to create new
> instances of the corresponding types, even when mucking about at the C
> layer.
>
> The assertion Serhiy is proposing to make is much weaker, and would be
> a matter of adding something like the following to the C API
> reference:
>
> "Similar to the singleton values True, False, None, and Ellipsis,
> process global instances of the builtin values (), '', b'', 0, and 1
> are pre-allocated at interpreter startup, so APIs returning these
> values should never fail, even in low memory conditions. However,
> additional empty instances of these types may still be created through
> the C API, so they should always be compared by value rather than by
> identity."
>
> The specific "never fails as it returns a pointer to a pre-allocated
> instance" cases can then be documented on the affected public API
> functions.
>
> So +1 from me for making pre-allocation a CPython C API guarantee, -1
> for making it a language level singleton commitment.


I agree with Nick's votes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20170502/e68306b9/attachment.html>