I haven't read the PEP yet, so this should not be read as either support of or opposition to the design, just commenting on one aspect. On Sat, Sep 10, 2022 at 01:42:38PM -0700, Christopher Barker wrote:
The current design is that sentinels with the same name from the same module will always be identical. So for example `Sentinel("name") is Sentinel("name")` will be true.
Hmm -- so it's a semi-singleton -- i.e. behaves like a singlton, but only in a particular module namespace. [...] It would be nice if they could be true singletons, but that would require a python-global registry of some sort, which is, well, impossible.
Easy peasey. Add a second, optional, parameter to the Sentinel callable (class?) to specify the namespace, defaulting to "the current module", then register the object to `builtins`. Of course, interpreter-global state should be discouraged, except for the interpreter itself :-) so we probably shouldn't do that. But a namespace parameter will have another advantage: it will allow packages to refactor their initialisation code to a sub-module: ``` # package/__init__.py from package.setup import * # package/setup.py import package import sentinel MySentinel = sentinel.Sentinel("name", namespace=package) ``` Yes, that's a circular import, but I think it is a safe one.
I would like to see a handful of common sentinels defined. Is there a plan to put a few that are useful for the stdlib in the `sentinel` module?
We already have None. What other "common sentinels" do you expect to be useful across the stdlib?
Maybe that doesn't belong in the PEP, but I like the idea of
a) every similar use in the stdlib uses the same one
Do you have examples of such stdlib "similar use" of sentinels? Apart from None of course. -- Steve