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 <st...@pearwood.info> 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
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/LWP4JAEJOIQ5UHPVQEZ4UNGNJVSXJFEA/
Code of Conduct: http://python.org/psf/codeofconduct/
