Add type hints and clean up some code for Mercurial.
Review Request #13609 — Created March 4, 2024 and submitted
This change modernizes the Mercurial backend somewhat through type hints
and general code housekeeping.
Ran unit tests.
Summary | ID |
---|---|
7da3ab1460ff3750d608449f3eedf79e83934a6d |
Description | From | Last Updated |
---|---|---|
Can we define the type (for this and any others) in an "Instance variables" on the class body? |
chipx86 | |
I made a similar comment in another change, but I'd like to keep the original form, for the same reason … |
chipx86 | |
This should be in the multi-line form. |
chipx86 | |
We're getting a generator at the end, not a tuple. Probably isn't any better than a list (maybe worse). Though, … |
chipx86 | |
please, do not remove that parameter. I added this in /r/11102 |
misery | |
Nit: These are all missing trailing periods. |
maubin | |
These comments are missing trailing periods. |
chipx86 | |
Too many blank lines in the comment. |
chipx86 | |
Double spaces should be a single space after the period. |
chipx86 | |
The single backticks must be double backticks for ReST. Also the period should be after the parens. |
chipx86 | |
We should transition to keyword-only arguments here, given the mix of kwargs for the parent and an argument here. |
chipx86 | |
"Mercurial" |
chipx86 | |
The type is already defined on the class body. |
chipx86 | |
We have a more explicit type we can list here now. |
chipx86 | |
Same here. |
chipx86 |
-
-
-
I made a similar comment in another change, but I'd like to keep the original form, for the same reason that we don't put
}
or]
on the final line for dicts/lists. It makes it easier to modify/add lines on multi-line strings without affecting previous lines.Also has a nice symmetry.
Doesn't necessarily matter in this particular case, but I'd prefer it as a general guideline.
-
-
We're getting a generator at the end, not a tuple. Probably isn't any better than a list (maybe worse).
Though, we're making an assumption here that we probably should check/handle with an exception handler. If we get too few or too many items here, we're going to crash. It's not a new problem, but worth considering.
- Commits:
-
Summary ID e5f151f16b9488c4e290cc8e6516006b23fefb7e d02a88b5b5ebeeda8f9f514a0fbf83225246320d
Checks run (2 succeeded)
- Commits:
-
Summary ID d02a88b5b5ebeeda8f9f514a0fbf83225246320d 1dbb5e675dfdeed2953fec1fbba303dabebb42b2