Actually, I mean -m test --match 'test_*_capi' where --match can also be
written -m.
It may catch false positive since the filter is also applied to test case
names and test method names.
Maybe 'test_*_capi.*' is better, I didn't try.
You may using use "ls Lib/test/test_*_capi.py > tests; ./pyth
On 30 July 2018 at 21:23, Victor Stinner wrote:
> Or maybe test__capi.py so you can more easily discover
> test_unicode_cami while working on Unicode. You can use -m "test_*_capi" to
> run all C API tests.
Missing word there: -m test "test*_capi"
I think between this approach and expanding test_
Or maybe test__capi.py so you can more easily discover
test_unicode_cami while working on Unicode. You can use -m "test_*_capi" to
run all C API tests.
Victor
Le lundi 30 juillet 2018, Victor Stinner a écrit :
> Buildbots have a timeout of 15 min per test. I suggest to use multiple
test_capi_.py
Buildbots have a timeout of 15 min per test. I suggest to use multiple
test_capi_.py files rather than a directory which behaves as a single
test. Or regrtest should be modified to implement timeout differently.
Victor
Le dimanche 29 juillet 2018, Serhiy Storchaka a
écrit :
> Currently C API is
> On Jul 30, 2018, at 12:06 AM, Serhiy Storchaka wrote:
>
> 30.07.18 09:46, Raymond Hettinger пише:
>> I prefer the current organization that keeps the various tests together with
>> the category being tested. I almost never need to run the C API tests all
>> at once, but I do need to see al
30.07.18 09:46, Raymond Hettinger пише:
I prefer the current organization that keeps the various tests together with
the category being tested. I almost never need to run the C API tests all at
once, but I do need to see all the tests for an object in one place. When
maintaining something li
> On Jul 29, 2018, at 4:53 AM, Serhiy Storchaka wrote:
>
> The benefit is that it will be easier to run all C API tests at once, and
> only them, and it will be clearer what C API is covered by tests. The
> disadvantage is that you will need to run several files for testing marshal
> for ex
On Sun, Jul 29, 2018, 06:44 Serhiy Storchaka, wrote:
> 29.07.18 15:39, Steve Dower пише:
> > On 29Jul2018 1253, Serhiy Storchaka wrote:
> >> The benefit is that it will be easier to run all C API tests at once,
> >> and only them, and it will be clearer what C API is covered by tests.
> >> The di
29.07.18 15:39, Steve Dower пише:
On 29Jul2018 1253, Serhiy Storchaka wrote:
The benefit is that it will be easier to run all C API tests at once,
and only them, and it will be clearer what C API is covered by tests.
The disadvantage is that you will need to run several files for
testing marsh
On 29Jul2018 1253, Serhiy Storchaka wrote:
The benefit is that it will be easier to run all C API tests at once,
and only them, and it will be clearer what C API is covered by tests.
The disadvantage is that you will need to run several files for testing
marshal for example.
Can we make the r
Currently C API is not completely covered by tests. Tests for particular
parts of C API are scattered through different files. There are files
completely purposed for testing C API (like test_capi.py,
test_getargs2.py), there are classes (usually having "CAPI" in the name)
in different files fo
11 matches
Mail list logo
