There is no way to annotate singletons like `sys.monitoring.DISABLE`

[gaogaotiantian]

Feature or enhancement

Proposal:

We have singletons like sys.monitoring.MISSING and sys.monitoring.DISABLE - and there's no way to annotate them in the function. In our own documentation we have something like

func(code: CodeType, instruction_offset: int) -> DISABLE | Any

but that's just wrong (well maybe pseudo?) - we can't do that. It's common to annotate a callback function with sys.monitoring.DISABLE, if you don't want to use Any. If you want to use it somewhere else, you might want to annotate as well.

I'm not the typing expert, but is there a way to support this? Literal[sys.monitoring.DISABLE] won't work either because it's a variable - I would accept that.

Has this already been discussed elsewhere?

No response given

Links to previous discussion of this feature:

No response

[picnixz]

Well... there is a way to annotate it using typing.Annotated[object, "sys.monitoring.DISABLE"] but that may be an overkill. Are you suggesting we create a special class just for that?

[JelleZijlstra]

This sounds like it would be solved by PEP 661 (sentinels): if DISABLE is defined as a sentinel object, it will be allowed to use it in a type annotation.

[gaogaotiantian]

Well... there is a way to annotate it using typing.Annotated[object, "sys.monitoring.DISABLE"] but that may be an overkill. Are you suggesting we create a special class just for that?

Sure but you won't get any valid type check on that. At least mypy and pyright just considered it an object.

[gaogaotiantian]

This sounds like it would be solved by PEP 661 (sentinels): if DISABLE is defined as a sentinel object, it will be allowed to use it in a type annotation.

Yes that PEP helps, but that PEP has also been there for a while without progress :)

[JelleZijlstra]

What you're asking for is a new type system feature, so it's going to take some effort to propose and standardize such a feature.

[gaogaotiantian]

Yes I understand that. That PEP can solve the sentinel issues which is helpful. I just don't know if that will get approved - and if not, are there any other ways to solve the problem?

For example, None is a special case where we allow the object itself, instead of its type, to be used for annotation. Of course that's a bit different because None has its own type which is helpful in the underlying check.

Is it possible to set some exceptions for the built-in sentinels like sys.monitoring.DISABLE and sys.monitoring.MISSING? Even making Literal[sys.monitoring.DISABLE] work could help a lot - that might be a bit less intrusive to the typing mechanism?

I'm not the expert of the typing system and I don't think this is super urgent - not a lot of people out there are using these two values. However, it would be nice if we can find a way to deal with it :)

[JelleZijlstra]

I think the PEP is likely to be approved if someone commits to championing it; the original author has not been very active.

If the PEP isn't accepted, we can talk about other solutions. I don't think it's a good idea to add a special case for a few rarely used constants like sys.monitoring.DISABLE.

[JelleZijlstra]

Closing as we generally don't track type system feature request on the CPython tracker.