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. > 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. In the specific cases of `dir` and `vars`, it is easy enough to work > around this with `*args`, but there can be functions with more complex > signatures where you cannot do so conveniently. > I've certainly had examples when I wanted to make a distinction between None and not specified, that did not have anything to do with introspecting the inputs. > For the basic cases, using None is sufficient; if it's not, rolling your > own is actually better than having a standard builtin, because: > > - it is specific to your library, you don't have to care about how > other libraries might treat it (to them, it's just an arbitrary > object, not a special sentinel); > It would mean "not specified" -- a nice way to combine keyword arguments with being able to be clear about it not being specified. *args can't do that. And sure, there *could* be other special cases, but it could be pretty useful anyway. The fact is that None is very heavily overloaded. I'd rather have a standard way to spell "non specified" than have every library roll their own and need to document it. Nothing would prevent folks from rolling their own if they did have a special case. > - and most importantly, you don't have to bike-shed the name and repr > with the entire Python-Ideas mailing list *wink* > Now THAT is a compelling argument! -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
_______________________________________________ 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/MWRVSPR2XC4OXAJOGFAHVI3ZFCHLS655/ Code of Conduct: http://python.org/psf/codeofconduct/
