Fri, 20 Sep 2024 00:20:24 -0400 util: avoid a leaked file descriptor in `util.makelock()` exceptional case
Matt Harbison <matt_harbison@yahoo.com> [Fri, 20 Sep 2024 00:20:24 -0400] rev 51888
util: avoid a leaked file descriptor in `util.makelock()` exceptional case
Fri, 20 Sep 2024 00:04:09 -0400 typing: add type annotations to the `mercurial.util.filestat` class
Matt Harbison <matt_harbison@yahoo.com> [Fri, 20 Sep 2024 00:04:09 -0400] rev 51887
typing: add type annotations to the `mercurial.util.filestat` class It's referenced in the `vfs` classes, so get this out of the way to help there. The `TypeVar` definition and its usage was copied from the existing `util.pyi` file.
Fri, 20 Sep 2024 12:15:08 -0400 vfs: do minor copyediting on comments and doc strings
Matt Harbison <matt_harbison@yahoo.com> [Fri, 20 Sep 2024 12:15:08 -0400] rev 51886
vfs: do minor copyediting on comments and doc strings These were flagged by PyCharm, so clear them from the gutter.
Fri, 20 Sep 2024 01:16:16 -0400 vfs: simplify the `abstractvfs.rename()` implementation
Matt Harbison <matt_harbison@yahoo.com> [Fri, 20 Sep 2024 01:16:16 -0400] rev 51885
vfs: simplify the `abstractvfs.rename()` implementation PyCharm was yapping about `util.rename()` not returning anything, because it is typed to return `None`, but the value was captured and returned after calling `_avoidambig()`. Instead, drop all of that, unconditionally rename, and then call `_avoidambig()` if appropriate. While we're here, convert the ersatz ternary operator into a modern one to help pytype. When a variable is initialized the old way, pytype tends to assign the type of the LHS of the `and`. In this case, that's a bool, and it will get confused that bool doesn't have a `stat` attribute once this method gets more type annotations. (Currently it thinks the `checkambig` arg is `Any`, so it doesn't care.)
Fri, 20 Sep 2024 00:07:39 -0400 vfs: use @abstractmethod instead of homebrewing abstract methods
Matt Harbison <matt_harbison@yahoo.com> [Fri, 20 Sep 2024 00:07:39 -0400] rev 51884
vfs: use @abstractmethod instead of homebrewing abstract methods The latter confuses PyCharm after adding more type annotations when, for example, `abstractvfs.rename()` calls `_auditpath()`- the latter unconditionally raised an error, so PyCharm thought the code that came after is unreachable. It also tricked pytype into marking the return type as `Never`, which isn't available until Python 3.11 (outside of `typing_extensions`). This also avoid PyCharm warnings that the call to the superclass constructor was missed (it couldn't be called because it raised an error to prevent instantiation). The statichttprepo module needed to be given an override for one of the abstract methods, so that it can be instantiated. In `abstractvfs`, this method is only called by `rename()`, so I think we can leave this empty. We raise an error in case somebody accidentally calls it in the future- it would have raised this same error prior to this change. I couldn't wrangle `import-checker.py` into accepting importing `ABC` and `abstractmethod`- for each subsequent import, it reports something like: stdlib import "contextlib" follows local import: abc I suspect the problem is that near the `if fullname != '__future__'` check, if the module doesn't fall into the error case, `seenlocal` gets set to the module name. That causes it to be treated like a local module on the next iteration, even though it is in `stdlib_modules`.
Thu, 19 Sep 2024 21:03:10 -0400 vfs: modernize the detection of the main thread
Matt Harbison <matt_harbison@yahoo.com> [Thu, 19 Sep 2024 21:03:10 -0400] rev 51883
vfs: modernize the detection of the main thread There weren't a lot of good choices when py27 was supported, but starting with py34, `threading.main_thread()` is available. This gets us away from an undocumented, internal symbol, and drops a pytype suppression statement. It is also apparently no longer reliable after a process fork.[1][2] [1] https://stackoverflow.com/a/23207116 [2] https://github.com/python/cpython/blob/v3.6.3/Lib/threading.py#L1334
Sun, 22 Sep 2024 17:06:31 -0400 store: fix a signature mismatch for a vfs subclass
Matt Harbison <matt_harbison@yahoo.com> [Sun, 22 Sep 2024 17:06:31 -0400] rev 51882
store: fix a signature mismatch for a vfs subclass This was flagged by PyCharm. I'm not sure why pytype doesn't catch this- it's not excluded from the modules that are currently checked.
Sun, 22 Sep 2024 17:02:42 -0400 lfs: fix various signature mismatches for vfs subclasses
Matt Harbison <matt_harbison@yahoo.com> [Sun, 22 Sep 2024 17:02:42 -0400] rev 51881
lfs: fix various signature mismatches for vfs subclasses These were flagged by PyCharm. I'm not sure why pytype doesn't catch these- only `hgext/lfs/__init__.py` in the lfs extension is excluded from being checked. I'm not sure if the `*insidef` arg to `join()` was meant as an internal convencience, because I see another class that gets flagged for the same signature problem (to be fixed next). But I don't feel bold enough to make this an internal function, and provide a simplified public `join()` on the `vfs` classes. That can still be done later, if desired. For now, process the additional args and pass them along, even though there don't appear to be any current callers that provide extra args to these classes. We need all of the subclasses to agree on the signature, or they won't be considered to implement the `Vfs` protocol being developed. While we're copy/pasting from the base class, bring the type annotations along for the ride.
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -8 +8 +10 +30 +100 +300 tip