Matt Harbison <matt_harbison@yahoo.com> [Fri, 27 Sep 2024 12:05:48 -0400] rev 51963
git: make `dirstate.parents()` return a list like the core class
The core class returned a list, so that's how I type annotated it, and this got
flagged. I suppose we could annotate it as a `Sequence[bytes]`, but it's a
trivial difference.
Matt Harbison <matt_harbison@yahoo.com> [Fri, 27 Sep 2024 11:57:42 -0400] rev 51962
typing: add type hints for the overloads of `matchmod.readpatternfile()`
The return type is conditional on an argument passed, and it very much confused
both pytype and PyCharm inside `dirstate._ignorefileandline()` after adding
type hints for the return value there.
Matt Harbison <matt_harbison@yahoo.com> [Thu, 26 Sep 2024 18:52:46 -0400] rev 51961
dirstate: subclass the new dirstate Protocol class
Behold the chaos that ensues. We'll use the generated *.pyi files to apply type
annotations to the interface, and see how much agrees with the documentation.
Since the CamelCase name was used to try to work around pytype issues with zope
interfaces and is a new innovation this cycle (see c1d7ac70980b), drop the
CamelCase name. I think the Protocol classes *should* be CamelCase, but that
can be done later in one pass. For now, the CamelCase alias is extra noise in
the *.pyi files.
Matt Harbison <matt_harbison@yahoo.com> [Thu, 26 Sep 2024 18:51:03 -0400] rev 51960
git: correct some signature mismatches between dirstate and the Protocol class
These were flagged by PyCharm when subclassing the Protocol class. Note that
both `is_changing_xxx` were only flagged when the Protocol class used a plain
field, as mentioned in the previous commit. After converting those attrs in the
Protocol class to @property to match the regular dirstate class, it stopped
flagging these. But I don't think that makes sense- `@property` should look
like an attribute to the outside world, not a callable.
Matt Harbison <matt_harbison@yahoo.com> [Thu, 26 Sep 2024 18:15:36 -0400] rev 51959
interfaces: convert the zope `Attribute` attrs to regular fields
At this point, we should have a useful protocol class.
The file syntax requires the type to be supplied for any fields that are
declared, but we'll leave the complex ones partially unspecified for now, for
simplicity. (Also, the things documented as `Callable` are really as future
type annotating worked showed- roll with it for now, but they're marked as TODO
for fixing later.) All of the fields and all of the attrs will need type
annotations, or the type rules say they are considered to be `Any`. That can be
done in a separate pass, possibly applying the `dirstate.pyi` file generated
from the concrete class.
The first cut of this turned the `interfaceutil.Attribute` fields into plain
fields, and thus the types on them. PyCharm flagged a few things as having
incompatible signatures when the concrete dirstate class subclassed this, when
the concrete class has them declared as `@property`. So they've been changed to
`@property` here in those cases. The remaining fields that are decorated in the
concrete class have comments noting the differences. We'll see if they need to
be changed going forward, but leave them for now. We'll be in trouble if the
`@util.propertycache` is needed, because we can't import that module here at
runtime, due to circular imports.
Matt Harbison <matt_harbison@yahoo.com> [Thu, 26 Sep 2024 18:09:33 -0400] rev 51958
interfaces: add the missing `self` arg to the dirstate Protocol class
This clears all of the errors that PyCharm has been flagging in this file, since
the zope interface was declared here.
Matt Harbison <matt_harbison@yahoo.com> [Thu, 26 Sep 2024 18:04:31 -0400] rev 51957
interfaces: convert the dirstate zope interface to a Protocol class
This is a small trial run for converting the repository interfaces enmasse, in
the same series of steps. I'm not sure that this current code is valid (it has
zope attribute fields, and it's missing all of the `self` args on its functions,
but that was the previous state of things, and made PyCharm really unhappy).
But it will be easier to review the repository interface changes if this change
is separate from adding `self` and dropping the zope attributes all over.
Having an empty constructor in a protocol is weird. I'm not sure if these args
should be converted to fields that all subclasses would have, and comments
around existing attributes say some should be going away. Comment it out for
now so that it's not in the way, but also not forgotten.