gh-108828: Support selecting tests by labels - #108829
Conversation
|
If possible, I would prefer to land my PR #108858 before. |
2b24913 to
5ae7161
Compare
sobolevn
left a comment
There was a problem hiding this comment.
Thanks a lot for working on this, it is definetely a step in the right direction for our test suite.
I have a question about naming, though.
Some tests in Lib/test/test_regrtest.py would also be nice, or I can add them later :)
I already have several ideas on top of this PR!
| rather than looking directly in the path directories. | ||
|
|
||
|
|
||
| .. function:: mark(label, *, globals=None) |
There was a problem hiding this comment.
I would prefer to always call them "marks". The main reason is that pytest uses the same idea and pytest's marks are well-known.
| .. function:: mark(label, *, globals=None) | |
| .. function:: mark(name, *, globals=None) |
Right now mark function adds a "label". It does not sound right.
There was a problem hiding this comment.
Or we can always call it "label".
There was a problem hiding this comment.
Yes, it is similar to pytest's markers, but there are enough differences in applying them and filtering by them. I do not have preference, "label", "marker" and "tag" are all look like synonyms in this context to me.
|
|
||
| .. function:: mark(label, *, globals=None) | ||
|
|
||
| Add a label to tests. |
There was a problem hiding this comment.
| Add a label to tests. | |
| Add a mark to tests. |
| else: | ||
| self.ignore_tests = None | ||
| if ns.accept_labels: | ||
| self.accept_labels: tuple[str, ...] = tuple(ns.accept_labels) |
There was a problem hiding this comment.
For some reasons they should be immutable, as well as match_tests and ignore_tests.
In any case, I am planning to rewrite filtering by names. Instead of two tuples there will be more complex structure where order matters. And the same can be used for labels.
|
|
||
| def _id(obj): | ||
| return obj | ||
| def mark(label, *, globals=None): |
There was a problem hiding this comment.
I had a similar API in one of my OS libs, users didn't like it at all :(
I think it would be better to use mark(..., *, module=False)
This way we can:
- Simplify the API for readers (even if our users are people working on CPython)
- Use
framehack to get the neededglobals()
There was a problem hiding this comment.
I do not like to depend on such hack it tests. If it does not work, many unrelated tests will not even be able to load.
Since it is an internal API used in limited number of places, simplicity for users is less important. support.mark('gui', globals=globals()) is not much worse than support.mark('gui', module=True)
There was a problem hiding this comment.
It is now derived by default, but there are cases when we need to specify it explicitly.
|
This PR is stale because it has been open for 30 days with no activity. |
…all" This change was accidentally reverted by f0daba1 (pythongh-106693, pythonGH-149514), which only intended to revert the ob_sval change. The tests were already restored by pythonGH-149569. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
# Conflicts: # Lib/test/libregrtest/cmdline.py # Lib/test/support/__init__.py # Lib/test/support/threading_helper.py
# Conflicts: # Lib/test/support/__init__.py
mark() had two different meanings depending on whether the globals argument was passed. It is now only a decorator of a test method or class, and mark_module() marks a whole module, by default the caller's. The label and its value are positional-only: a keyword would be mistaken for the name of the label. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Documentation build overview
|
|
It now supports labels with values and separate function is now used to mark the module. Just yesterday Claude wrote a script to extract all bigmem test names from sources. With this feature it would be a one line. |
support_remote_exec_only(), added in main after this branch replaced the other uses of _id() with combine(), still returns it. The merge was clean, but importing test.support failed with a NameError. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Uh oh!
There was an error while loading. Please reload this page.