typing: lock in correct changes from pytype 2023.04.11 -> 2023.06.16
There were a handful of other changes to the pyi files generated when updating
pytype locally (and jumping from python 3.8.0 to python 3.10.11), but they were
not as clear (e.g. the embedded type in a list changing from `nothing` to `Any`
or similar). These looked obviously correct, and agreed with PyCharm's thoughts
on the signatures.
Oddly, even though pytype starting inferring `obsutil._getfilteredreason()` as
returning bytes, it (correctly) complained about the None path when it was typed
that way. Instead, raise a ProgrammingError if an unhandled fate is calculated.
(Currently, all possibilities are handled, so this isn't reachable unless
another fate is added in the future.)
monotone: replace %s interpolation with appropriate numeric specifiers
The length is an int, and the version is a float. Neither work with bytes on
py3. This was noticed when looking at nearby code after updating pytype changed
some signatures.
shelve: raise an error when loading a corrupt state file in an impossible case
The old return statement was flagged by pytype 2023.06.16 running under python
3.10.11. No idea why it isn't caught in CI running the same pytype with py3.7.
This function is only called by `unshelvecmd()` (which first checks that either
`--abort` or `--continue` is specified), and `hgabortunshelve()` and
`hgcontinueunshelve()`, which locally apply `--abort` or `--continue`
respectively. Therefore, there is no other way to call this, and this error
should never be seen, but pytype can't figure that out on its own. Given that
the abort case clears the state, it seems reasonable to defensively code this
and not make that a blanket `else` case, on the off chance a 3rd way of calling
this appears in the future.
contrib: print the version of pytype used to do the type checking
This will help with CI. I don't see a way to print the version of python that's
running it. When I tried `head -n 1 $(which pytype)`, the CI run printed:
#!/usr/bin/env bash
Locally, that gives the path to the python interpreter in the venv, so IDK
what's different.
typing: create an @overload of `phasecache` ctor to handle the copy case
In `phasecache.copy()`, it calls `self.__class__(None, None, _load=False)`, but
the constuctor is typed to take a non-None repository. For the `_load=False`
case, all args are ignored (and the copy function itself populates the attrs on
the new object), so this isn't an error. For the default `_load=True` case, it
needs a non-None repository. This is the simplest way to handle that duality.
The reason this wasn't being detected is because pytype is confused by the
interface decorators on the `localrepository` class, and is inferring the whole
class as `Any`. (See
3e9a660b074a or
c1d7ac70980b) Therefore, the type hint of
`localrepo.localrepository` here was also effectively `Any`, which disabled the
type checking entirely.
This is the first foray into using `typing_extensions` to unlock future typing
features. I think this is safe and reasonable because 1) it is only imported in
the type checking phase (so no need to vendor our own copy), and 2) pytype has
its own copy of `typing_extensions` bundled with it, so no need to alter the
test environment. When run with a version of python that supports the symbol(s)
natively, `typing_extensions` simply re-exports from `typing`, so there
shouldn't be any future headaches with this.
typing: declare the `_phasesets` member of `phasecache` to be `Optional`
Something in this area got flagged while making the repository class visible to
pytype (instead of being typed as `Any`). A None assignment to something not
optional is wrong, and when I tried setting it to `{}` to keep it non-Optional,
some tests failed. There are checks for the attr being None elsewhere, so this
seems to have just been an oversight.