- Dec 15, 2024
-
-
Georges Racinet authored
The "borrow" word had way too many uses in this context. Originally, it came from the rust-cpython version, which is based on `RefCell`. Before this change, we had untracktable stacks of borrows (first the `Bound`, then the `PySharedRefCell`). In any case, the change to `RwLock` is far from being neutral, and we may need in a future without GIL to also expose blocking methods, to account for in-Rust possible concurrency. Using `read()` and `write()` right now matches our PyO3 habits anyway, where all non-Sync objects have to be wrapped in a RwLock.
-
Georges Racinet authored
We had previously duplicated the `new` associated function on `PySharedRef` with a method on `PySharedRefCell`: in `rust-cpython`, the former was hidden by the accessor defined by the `py_class!` macro, which we did not port yet. On `PySharedRefCell` itself, replacing the `new` associated function by the `From` trait carries all the needed semantics, and has the advantage of less repetititons of the type name, which will help with further refactorings and renamings.
-
- Dec 14, 2024
-
-
Georges Racinet authored
This should bring full confidence on the conversion to PyO3. It highlights also the difference between the two bindings systems: in PyO3, the struct defined by the user is the inner Rust one. In rust-cpython, it is the wrapped one exposed to CPythob We enclose some of the boilerplate in helper functions. Perhaps we should first import the rust-cpython integration test, rework it with the same helpers, then only change the helpers.
-
- Dec 15, 2024
-
-
Georges Racinet authored
At this point, we have a full translation, with some tests. The tests are high level, demonstrating the case of iterating over `HashSet` as a doctest. The assertions are written as Python statements, in order not to be obscure and to resist later refactorings. The rust-cpython integration tests will be ported in a subsequent changeset. We find the example of iterating over `HashSet` to be more convincing than the iterating over `Vec`, the example provided in rust-cpython, because in the case of `Vec`, it would be simple enough to use `Arc<Vec>` and an index. This would of course be reimplementing the iterator, but is simple enough that it leads the reader to believe that having a reference is the problem, whereas the problem is having a reference that is itself enclosed in a type with lifetime that can be arbitrary complex. It took us some time to remember that subtlety, and hence we reworded the documentation to stress that point. We decided to put this work a separate crate, which makes running `cargo test` work for the crate, but not for the entire workspace: the `extension-module` feature gets in the way. That is why we reexpose the feature on `hg-pyo3` as default and run the tests with `--no-default-feature` in Makefile, hence in CI. An important difference with rust-cpython is that everything has to be `Sync`, hence we replace `RefCell` with `RwLock` and only speak of "interior mutability" in the documentation. Since everything happens in `hg-pyo3` behind the GIL, there is at this point no reason to use `read()` and `write()` instead of respectively `try_read()` and `try_write()`. But PyO3 is aiming to support free-threaded Python (without GIL), and `PySharedRef` should therefore allow waiting for its inner locks.
-
- Dec 17, 2024
-
-
Matt Harbison authored
-
Matt Harbison authored
I think the typing around whether `open()` returns `IO[bytes]` or `IO[str]` hinges on the content of the mode string. Converting from bytes instead of using a literal can suppress that (though PyCharm currently complains about this). Instead, we can mandate the use of a (vastly reduced) set of mode options. For now, none of the 3 callers provide this argument, so it's not a big deal. Ideally, this would always enforce binary mode. There's a little extra typing required to pull this off. The `_unclosablefile` class can't subclass `typing.BinaryIO`, because there were a bunch of test failures around writing to stdout. Strangely, pytype didn't complain that the abstract methods on `typing.BinaryIO` weren't overridden in this case. Whatever was going on, it's a simple proxy class, so we can just cast to the expected type in the one place it is used.
-
- Jan 01, 2025
-
-
Matt Harbison authored
This mirrors the function override that largefiles has, and validating input near the top of the function makes more sense.
-
- Dec 05, 2024
-
-
Matt Harbison authored
A little less complicated, and guarded by type checking.
-
- Jan 01, 2025
-
-
Matt Harbison authored
This is intertwined with the `mode`, which is also used with `open()`, so the goal is to get that to str so that the `pycompat.open()` call can be dropped. Start simple because I had issues where the generated archive in some tests had 1 different byte for some reason when making the full change, even though the content was binary equivalent when doing a Folder Compare of the archives with BeyondCompare4. The key for the `archivers` map is left alone for now. The classes that are stored are only ever called with 2 args, so this should be safe.
-
- Dec 05, 2024
-
-
Matt Harbison authored
Builtin exceptions generally use str, and this was probably a side effect of the mass-byteification a few years ago. While we're here, specify that the type needs to be bytes, since that's what's checked. Maybe this was meant to be a ProgrammingError- IDK that showing this to the user is helpful in any way.
-
- Jan 02, 2025
-
-
Pierre-Yves David authored
We no longer need this indirection, and the other users are gone.
-
Pierre-Yves David authored
Since we run the python executable from the venv, all import path should be properly set already.
-
- Jan 04, 2025
-
-
Pierre-Yves David authored
The new way works even if PYTHONPATH is not set (this series goal) and is more friendly to the virtual env we now use when installing Mercurial during tests.
-
- Jan 02, 2025
-
-
Pierre-Yves David authored
This is a first step toward stopping overriding PYTHONPATH all together. I do it step by step to ease the detection of tests that might need to be adapted.
-
Pierre-Yves David authored
This is a first step toward stopping overriding PYTHONPATH all together. I do it step by step to ease the detection of tests that might need to be adapted.
-
Pierre-Yves David authored
Since we know exactly where it is, there is not need to use `python -m heredoctest` to call it, we can just call that script. We more the script in "testlib" to reduce the test directory clutter. We might want to create a "tooling" directory in the future for this kind of utility.
-
Pierre-Yves David authored
I looked at this to directly call heredoctest.py and I could not resist the urge for some cleanup.
-
Pierre-Yves David authored
I don't think we heard anything about jython support for the past 15 years, so let's drop special support for it in run-tests.py it is most probably broken at that point.
-
- Jan 06, 2025
-
-
Pierre-Yves David authored
The virtual env is already providing use with a correct `python` and `python3` executable, so lets not add more complexity in the case were we can simply rely on them.
-
- Dec 31, 2024
-
-
Pierre-Yves David authored
The venv python should be equivalent to sys.executable and this get use closer to stop manipulation PYTHONPATH content directly.
-
- Dec 30, 2024
-
-
Pierre-Yves David authored
We move that value as an attribute to the test runner and the tests, this will allow more flexibility in later changeset, especially to make sure we use the venv in a more traditional way in the future.
-
- Jan 06, 2025
-
-
Pierre-Yves David authored
We needed to drop compatibility with Python Version < 3.8. This is now done.
-
- Dec 30, 2024
-
-
Pierre-Yves David authored
In 8 years of using that test runner, I never used that option from run-tests. I use `hg bisect` calling the test runner a lot, but not the other way around. Dropping the option simplify the code.
-
- Dec 17, 2024
-
-
Matt Harbison authored
These were unlocked by 8de9bab826bc, so lock them in.
-
- Dec 16, 2024
-
-
Matt Harbison authored
-
Matt Harbison authored
It looks like `BaseIndexObject` is meant to be a base class with common implementation across the subclasses. Both subclasses provide the class attrs typed here, as well as `_calculate_index()` that are accessed by the base class. The trick is, `revlog.RustIndexProxy` also uses it as a base class, and forwards some methods such that it doesn't want or need this method. This is kind of a workaround to keep everything happy. Likewise, it doesn't need the 3 class variables, because it overrides the methods in this class that use them. But there's no way to conditionally declare these. Their presence seems conditional on the version of Python- see 199b0e62b403. (Also, it looks like the rust class doesn't override `append()`, which would need `_extra`. Not sure if this is an oversight, or if it's more of a "protected" field instead of private.) `PersistentNodeMapIndexObject` says it's for debugging, so I'm not going to bother trying to figure out what the 3 required class attr types are right now, and risk introducing a cycle that confuses pytype.
-
- Dec 17, 2024
-
-
Matt Harbison authored
-
Matt Harbison authored
-
Matt Harbison authored
I wanted to use `util.readfiles()` here, but it looks like very little core code is imported, and I assume that's by design?
-
Matt Harbison authored
The file never got closed if the write failed, but take the opportunity to simplify the method with the corresponding util functions.
-
Matt Harbison authored
-
Matt Harbison authored
No changes here, other than running `black`.
-
Matt Harbison authored
Not sure why there's an `os.stat()` here- I'd expect any errors that it might hit to also be hit by attempting to open the file in read mode. It goes all the way back to a9343f9d7365 in 2006, and mentions making things more secure, so I'll leave it be for now.
-
Matt Harbison authored
-
Matt Harbison authored
-
Matt Harbison authored
Also put a comment here, because I initially thought opening in non-binary mode was a mistake, but 7cc913396f8c did it purposely.
-
Matt Harbison authored
I suppose the first case isn't fully fixed (i.e. if `os.fdopen()` raises an exception), but this handles the majority of the potential exceptions. Closing the second file is especially important on Windows, because `os.unlink()` can't delete an open file.
-
Matt Harbison authored
The one in `shallowutil` is especially important, because the caller may try to delete the file. That generally doesn't work on Windows when the file is open.
-
Matt Harbison authored
-
Matt Harbison authored
It only would have happened in an exception case, but there are now language contructs to tighten this up.
-