Matt Harbison <matt_harbison@yahoo.com> [Sun, 22 Sep 2024 17:15:20 -0400] rev 51916
keepalive: fix a signature mismatch for a http.client.HTTPResponse subclass
Also flagged by PyCharm. This is checked by pytype too, so I'm not sure why it
misses this. I verified in py36 that this argument is documented for the
function, so maybe this is py2 legacy.
Matt Harbison <matt_harbison@yahoo.com> [Sun, 22 Sep 2024 17:11:10 -0400] rev 51915
cbor: drop a duplicate dictionary initialization entry
Flagged by PyCharm.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 04 Sep 2024 17:08:58 +0200] rev 51914
profiling: document the py-spy value for `profiling.type`
The feature was not visible otherwise.
Matt Harbison <matt_harbison@yahoo.com> [Thu, 19 Sep 2024 18:49:04 -0400] rev 51913
tests: enable pytype checking on `mercurial/unionrepo.py`
Matt Harbison <matt_harbison@yahoo.com> [Thu, 19 Sep 2024 18:48:07 -0400] rev 51912
unionrepo: fix mismatches with revlog classes
This is a subset of cfd30df0f8e4, applied to `unionrepository`. There are none
of the `write()` method overrides here, like `bundlerepository`.
With these changes, pytype flags the `unionrevlog` constructor:
File "/mnt/c/Users/Matt/hg/mercurial/unionrepo.py", line 55, in __init__:
No attribute '_revlog' on mercurial.changelog.changelog [attribute-error]
Called from (traceback):
line 207, in __init__
File "/mnt/c/Users/Matt/hg/mercurial/unionrepo.py", line 55, in __init__:
No attribute '_revlog' on mercurial.revlog.revlog [attribute-error]
Called from (traceback):
line 232, in __init__
But it turns out that both `changelog.changelog` and `revlog.revlog` do have a
`target` attribute, so they wouldn't trip over this. It seems weird that the
second caller to be flagged is passing the private `_revlog`, but maybe that's
how it needs to be.
Matt Harbison <matt_harbison@yahoo.com> [Thu, 19 Sep 2024 16:19:29 -0400] rev 51911
typing: make `unionrepository` subclass `localrepository` while type checking
This is the same change as 9d4ad05bc91c made for `bundlerepository`, for the
same reasons.
Also, add a comment here to suppress the PyCharm warning that the superclass
constructor is not called, that is new now that there's a simulated superclass.
That lack of a call is by design- `makeunionrepository()` does magic that
PyCharm isn't aware of. But PyCharm has been better at catching problems than
pytype in a lot of cases, so I'd like to reduce the bogus things it flags, to
make the real issues stand out.
Matt Harbison <matt_harbison@yahoo.com> [Wed, 18 Sep 2024 21:00:20 -0400] rev 51910
tests: enable pytype checking on `mercurial/bundlerepo.py`
Matt Harbison <matt_harbison@yahoo.com> [Wed, 18 Sep 2024 17:46:46 -0400] rev 51909
revlog: make `clearcaches()` signature consistent with ManifestRevlog
I'm not sure if this a newly added bug, because of using a different version of
pytype, or if the recent work around avoiding the zope interface types in the
type checking phase (see 5eb98ea78fd7 and friends)... but pytype 2023.11.21
started flagging this series since it was last pushed ~6 weeks ago:
File "/mnt/c/Users/Matt/hg/mercurial/bundlerepo.py", line 204, in <module>:
Overriding method signature mismatch [signature-mismatch]
Base signature: 'def mercurial.manifest.ManifestRevlog.clearcaches(self, clear_persisted_data: Any = ...) -> None'.
Subclass signature: 'def mercurial.revlog.revlog.clearcaches(self) -> None'.
Not enough positional parameters in overriding method.
Maybe the multiple inheritance in `bundlerepo.bundlemanifest` is bad, but it
seems like a `ManifestRevlog` is-a `revlog`, even though the class hierarchy
isn't coded that way. Additionally, it looks like `revlog.clearcaches()` is
dealing with some persistent data, so maybe this is useful to have there anyway.
Also sprinkle some trivial type hints on the method, because there are other
`clearcaches()` definitions in the codebase with these hints, and I don't feel
like waiting for another pytype run to see if it cares that specifically about
the signature matching.
Matt Harbison <matt_harbison@yahoo.com> [Sat, 03 Aug 2024 01:33:13 -0400] rev 51908
bundlerepo: fix mismatches with repository and revlog classes
Both pytype and PyCharm complained that `write()` and `_write()` in the
bundlephasecache class aren't proper overrides- indeed they seem to be missing
an argument that the base class has.
PyCharm and pytype also complained that the `revlog.revlog` class doesn't have a
`_chunk()` method. That looks like it was moved from revlog to `_InnerRevlog`
back in e8ad6d8de8b8, and wasn't caught because this module wasn't type checked.
However, I couldn't figure out a syntax with `revlog.revlog._inner._chunk(self, rev)`,
as it complained about passing too many args. `bundlerevlog._rawtext()` uses
this `super(...)` style to call the super class, so hopefully that works, even
with the wonky dynamic subclassing. The revlog class needed the `_InnerRevlog`
field typed because it isn't set in the constructor.
Finally, the vfs type hints look broken. This initially failed with:
File "/mnt/c/Users/Matt/hg/mercurial/bundlerepo.py", line 65, in __init__: Function readonlyvfs.__init__ was called with the wrong arguments [wrong-arg-types]
Expected: (self, vfs: mercurial.vfs.vfs)
Actually passed: (self, vfs: Callable)
Called from (traceback):
line 232, in dirlog
line 214, in __init__
I don't see a raw Callable, but I tried changing some of the vfs args to be typed
as `vfsmod.abstractvfs`, but that class doesn't have `options`, so it failed
elsewhere. `readonlyvfs` isn't a subclass of `vfs` (it's a subclass of
`abstractvfs`), so I'm not sure how to handle that. It would be a shame to have
to make a union of vfs subclasses (but not all of them have `options` either).
Matt Harbison <matt_harbison@yahoo.com> [Wed, 18 Sep 2024 17:50:57 -0400] rev 51907
typing: make `bundlerepository` subclass `localrepository` while type checking
Currently, `mercurial/bundlerepo.py` is excluded from pytype, mostly because it
complains that various `ui` and `vfs` fields in `localrepository` are missing.
(`bundlerepository` dynamically subclasses `localrepository` when it is
instantiated, so it works at runtime.) This makes that class hierarchy known to
pytype.
Having a protocol for `Repository` is probably the right thing to do, but that
will be a lot of work and this still reflects the class at runtime. Subclassing
also has the benefit of making sure any method overrides have a matching
signature, so maybe this is a situation where we do both of these things. (I'm
not sure how clear the diagnostics are if a class *almost* implements a
protocol, but is missing a method argument or similar.) The subclassing is not
done outside of type checking runs to avoid any side effects on already complex
code.