On 2 May 2017 at 07:52, Chris Angelico <rosuav@gmail.com> wrote:
> On Tue, May 2, 2017 at 6:52 AM, Terry Reedy <tjreedy@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.