[Python-Dev] Guarantee the success of some object creation C API functions (original) (raw)
Nick Coghlan ncoghlan at gmail.com
Tue May 2 00🔞42 EDT 2017
- Previous message (by thread): [Python-Dev] Guarantee the success of some object creation C API functions
- Next message (by thread): [Python-Dev] Guarantee the success of some object creation C API functions
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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.
Cheers, Nick.
-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
- Previous message (by thread): [Python-Dev] Guarantee the success of some object creation C API functions
- Next message (by thread): [Python-Dev] Guarantee the success of some object creation C API functions
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]