On 29 October 2016 at 04:08, Mark Dickinson firstname.lastname@example.org wrote:
On Fri, Oct 28, 2016 at 9:30 AM, Nick Coghlan email@example.com wrote:
[...] the current practicises of:
- obj is not None (many different use cases)
- obj is not Ellipsis (in multi-dimensional slicing)
Can you elaborate on this one? I don't think I've ever seen an `is not Ellipsis` check in real code.
It's more often checked the other way around: "if Ellipsis is passed in, then work out the multi-dimensional slice from the underlying object"
And that reflects the problem Paul and David highlighted: in any *specific* context, there's typically either only one sentinel we want to either propagate or else replace with a calculated value, or else we want to handle different sentinel values differently, which makes the entire concept of a unifying duck-typing protocol pragmatically dubious, and hence calls into question the idea of introducing new syntax for working with it.
On the other hand, if you try to do this as an "only None is special" kind of syntax, then any of the *other* missing data sentinels (of which we have 4 in the builtins alone, and 5 when you add the decimal module) end up being on much the same level as "arbitrary sentinel objects" in the draft PEP 531, which I would consider to be an incredibly poor outcome for a change as invasive as adding new syntax: https://www.python.org/dev/peps/pep-0531/#arbitrary-sentinel-objects