On Mon, 1 May 2017 at 21:19 Nick Coghlan <ncogh...@gmail.com> wrote: > On 2 May 2017 at 07:52, Chris Angelico <ros...@gmail.com> wrote: > > On Tue, May 2, 2017 at 6:52 AM, Terry Reedy <tjre...@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.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
