Thanks for an interesting discussion. I would also urge people to limit the use of such sentinels for cases where it is *really* important to distinguish between, say, f(None) and f(). In most cases using def f(arg=None) is fine, and often it is even a virtue that passing None or omitting an argument has exactly the same meaning. (I do know there a cases where this doesn't apply -- I just think they ought to be fairly unusual.)
On Fri, Jul 6, 2018 at 8:21 AM Flavio Curella <[email protected]> wrote: > @Nathaniel Smith: > > > I think the name "symbol" here is pretty confusing. It comes originally > from Lisp > > The thing you're talking about is what Python devs call a "sentinel" > object. > > Thank you for clarifying. I don't know much about Lisp, and I definitely > appreciate the historical context that you provided :) > > I will refer to the new proposed type as `sentinel` from now on. > > @Michael Foord > > > unittest.mock includes a sentinel object, with nice repr. > > Thank you! I didn't think of looking in the mock library. > > This is one step closer, but it still have a few considerations: > 1. It doesn't follow the same behaviour as the JS spec. But honestly, we > don't have to. > 2. It's kinda weird to have to import `unittest.<something>` in code > that's not tests. But I think it's just because I'm not used to see it. > > @Giampaolo Rodola' > > Historically this has always been achieved by using [...] which does > its job just fine. > > The main issue with that approach is that you won't get a nice repr > > > adding more complexity to the language for no practical benefit > > I'm not following. The Python language won't be modified. I'm proposing > adding the new type _purely_ for practical benefit. > > I think this thread can be resolved as 'used unittest.mock.sentinel'. It > doesn't have 'global sentinels', but I'm not convinced they are actually > necessary, since `mock.sentinel` objects with the same name compare as > equal. Thanks to Nathaniel, I now understand that JS has global symbols for > historical reasons that we don't have, and I'm not convinced of their > usefulness. > > Thank you everybody for you valuable feedback! I really appreciate your > time helping me thinking this through :) > > _______________________________________________ > Python-ideas mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido)
_______________________________________________ Python-ideas mailing list [email protected] https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
