Investigate whether Optional members of ops/pebble.py TypedDicts can be NotRequired instead

[james-garner-canonical]

Several TypedDicts in ops/pebble.py represent values returned from Pebble. Generally pebble will simply omit an optional field if it is not set (but we need to confirm this for each one). Due to limitations of typing on older Python versions, these TypedDicts sometimes use total=False to coarsely describe this, as well as annotating some values as Optional (i.e. can be None).

There are two components here.

1. Can we use NotRequired from typing_extensions cleanly while supporting older python versions, e.g. putting the NotRequired import behind if TYPE_CHECKING and using stringified type annotations? This would allow us to explicitly mark which keys are required and which are not instead of using total=False.
2. For public TypedDicts, is it a supported pattern for users to pass None as a synonym for the entry being missing? When a dict only comes from Pebble, we can use NotRequired[some_type], but when a dict can be constructed by a user, we may need/want to use NotRequired[Optional[some_type]] instead to let them use None for values they don't want to set.

Related: investigate the use of Optional values in Check. CheckDict has several Optional members which will simply be missing if they're not set when coming from Pebble. The Check constructor annotates these values as Optional, but sets some of them to empty strings instead if they're missing. Check.to_dict then filters out any Falsey values, including empty strings and None. This may be a good opportunity to tidy this up a little bit.

[benhoyt]

Thanks for opening this. Getting types right is hard! :-)

FWIW, I think a python label is of limited value, as it's going to be on pretty much every (non-docs) issue here, so feels like just label noise. I think type hints is fine.

[james-garner-canonical]

Worth removing the python label from the issue tracker? I see it has only been used by dependabot a few times some months ago.

[tonyandrewmeyer]

Worth removing the python label from the issue tracker? I see it has only been used by dependabot a few times some months ago.

Dependabot will (re)create the label because there's more than one language/subsystem being updated (Python and GitHub actions). We can disable that in the dependabot config if we don't want the default behaviour.

[benhoyt]

Oh, thanks -- I didn't realise that was a dependabot-created label. If we can remove and get dependabot to not recreate it easily, that's fine, but not a big deal nor worth spending much time on.

[james-garner-canonical]

I've gone with the easy solution of updating the python label description to 'dependabot PR that updates python dependencies'.

[tonyandrewmeyer]

Oh, thanks -- I didn't realise that was a dependabot-created label. If we can remove and get dependabot to not recreate it easily, that's fine, but not a big deal nor worth spending much time on.

It should be straightforward: #1407