Hi,

Just wonder what'd happen to a is sentinel checks if a user is messing with relative/absolute imports or sentinels are spawned in different threads.

I've have had a good time years ago while debugging a similar case of sentinel = object() and is checks, which lead me to sentinel = tuple() approach.

In addition:

• In Rationale, criteria 2 and 6 can probably be merged.

Is it assumed that the sentinel function is always called at module scope? I think there may be thread safety issues with the sentinel() function.

Hey Tal,

Instead of creating a module with a single function, and since sentinel is used 468 times in 58 different python files just in the standard library, I believe it justifies adding it to the builtins.

The usage of sentinel values is vast, and almost every Python module I write or contribute to has created at least one sentinel value.

Importing the module just about everywhere sounds a bit counter-productive, as creating sentinel objects should be as simple as creating a string, a "None" object, or an integer. Plus, I do not see how the "sentinels" module grows to have more than the single "sentinel" class. No matter how it grows, it'll break the uniqueness and thus one of the requirements of a sentinel value.

Lots of love ❤️ Bar Harel.

Thank you for a nice and clean idea and a reference implementation to provide a standard way to define a sentinel.

I'd like to ask to improve reference implementation with closing ability to define any properties or extending the object.

With reference implementation I see usage of slots mechanism and making this class final. There's no reason to provide extendable implementation for sentinels as they are as a None just singletons.

if the sentinel type was simply available on the sentinel, that would be good enough for a number of cases

MyMissing = sentinel("missing", module=__name__)
assert isinstance(MyMissing, MyMissing.type

pickle could aslo be set up to just return them as the value stored in the module

I really like the proposed Sentinel class because when using an Enum for a singleton type it always annoyingly shows up in type signatures and autogenerated documentation.

However I think not supporting Literal as mentioned in Specific type signatures for each sentinel value is a big mistake, since it would mean Sentinel could not actually replace Enum if you require the ability to use the type in Literal ... which I think is a very common requirement.

Python notably does not support algebraic data types. For example in Rust you could just define:

enum Submodule {
    Specific(String),
    All,
    AllRecursively,
}

the closest you can do in Python is to use the Union type, for example Union[str, Literal[DirectSubmodules, AllSubmodules]], now instead of having to abuse Enum for this as follows:

class _ModuleSpec(Enum):
    DirectSubmodules = 'DirectSubmodules'
    AllSubmodules = 'AllSubmodules'

DirectSubmodules = _ModuleSpec.DirectSubmodules
AllSubmodules = _ModuleSpec.AllSubmodules

(which would result in _ModuleSpec showing up in IDE tooltips and autogenerated API documentation and thus potentially confuse users), it would be great if you could instead just do:

DirectSubmodules = Sentinel('DirectSubmodules')
AllSubmodules = Sentinel('AllSubmodules')

and still be able to use Literal[DirectSubmodules, AllSubmodules].

The PEP mentions that Literal support has been dropped from the PEP due to concerns voiced on the mailing list. While I cannot really comment on the challenges of special casing Literal, I think this additional complexity would definitely be worth it to make Sentinel as useful as Enum and allow it to replace it for cases where you do not actually want to introduce an enum type.

The specification currently does not specify whether or not the Sentinel class may be subclassed. The reference implementation does not use @typing.final, allowing subclasses, which I think does make sense because it allows e.g. the __str__ or __le__ methods of sentinel objects to be customized, which can be very useful.

I think it would make sense to clarify the specification to say that the Sentinel class may be subclassed.

The Specification section of PEP 661 currently says:

A new Sentinel class will be added to a new sentinels module.

Note "sentinels" in plural but goes on with a code example showing sentinel in singular:

 >>> from sentinel import Sentinel

While the latter appears to be a typo, I think singular would actually be preferable to plural to be consistent with the enum module, which is called enum instead of enums, so I think the sentinel module should also be called sentinel instead of sentinels.