scmutil: explicitly subclass the `Status` protocol...
scmutil: explicitly subclass the `Status` protocol
We shouldn't have to explicitly subclass, but PyCharm has a nifty feature that
puts a jump point in the gutter to navigate back and forth between the base
class and subclasses (and override functions and base class functions) when
there's an explicit subclassing. Additionally, PyCharm will immediately flag
signature mismatches without a 40m pytype run.
It was also hoped that with explicit subclassing, we would get interface
checking for free. Unfortunately when I tried adding methods and fields to the
Protocol class to test this theory, pytype happily accepted an assignment of the
concrete class without the new field and methods, to a variable annotated with
the Protocol class with them. It appears that this is what happens when
explicit subclassing is used, since dropping that caused pytype to complain.
By making the methods abstract here like the `mercurial.wireprototypes` classes
in fd200f5bcaea, pytype will complain in that case outlined that a subclass with
abstract methods (not replaced by the subclass itself) cannot be instantiated.
That doesn't help with the fields. Making an `abstractproperty` likely isn't
appropriate in general, because that effectively becomes a read-only property.
This seems like a pretty gaping hole, but I think the benefits of explicit
subclassing are worth the risk. (Though I guess it shouldn't be surprising,
because a class can be both a Protocol and an implementation, so subclassing
something with an empty body method doesn't really signal that it is a
requirement for the subclass to implement.)
