On Mon, May 25, 2020 at 08:54:52PM -0700, Christopher Barker wrote:
On Mon, May 25, 2020 at 6:37 PM Steven D'Aprano
wrote: A NOT_SPECIFIED singleton in builtins would be pretty clear.
Guido's time machine strikes again! We already have that "not specified" singleton in the builtins, with a nice repr. It's spelled "None".
well, yes and no. this conversation was in the context of "None" works fine most of the time.
Um, yes? I know what the context is, I'm pretty sure I already pointed out that None works fine most of the time. So we already have the feature you wanted: a sentinel value that implies "no value was passed". That's one of the purposes of None. If you want a *second* such sentinel value, we run into the problem I go on to describe.
The problem is that this is an infinite regression. No matter how many levels of "Not Specified" singletons you have, there's always going to be some context where they are all legitimate values so you need one more. Think about a function like `dir()` or `vars()`, which can operate on any object, or none at all
well, those are pretty special cases -- they are about introspection -- most functions do not act on the objects themselves in such a generic ways.
It's not just introspection. What should `len(Undef)` do? If Undef or Missing or whatever you call it is supposed to represent a missing argument, one not given at all, then we ought to get: >>> len(Undef) TypeError: len() takes exactly one argument (0 given) since len takes no default values. But if Undef is considered to be an actual object, like any other object, we ought to get this: TypeError: object of type 'UndefType' has no len() So take your choice: either - we give fake error messages with misleading descriptions; - or we sometimes have to treat this "missing" sentinel as not missing at all, but just a plain old value like every other value. But that's what happens with None, so the same thing will happen with Undef, so we can add a third level of "the sentinel you use to represent a missing value when both None and Undef are regular values" except the exact same thing will happen to this third-level sentinel. And so on and so on. We cannot escape this so long as None/Undef/Missing etc are actual first class objects, like None and other builtins. But doing otherwise, having Undef be *not an object* but a kinda ghost in the interpreter, is a huge language change and I doubt it would be worth it. -- Steven