This is totally unrelated, but many times have I been using a construction of the form:

for x1 in x1s:
  ...
  for xn in xns:
      with self.subTest(x1=x1, ..., xn=xn):
          do_test(...)

I'm wondering if it makes sense to have a helper that would be equivalent to the above:

for x1, ..., xn in self.cases(x1=x1s, ..., xn=xns):
	do_test(...)

I'm pretty sure we can use this kind of pattern in the test directory quite a lot, and it can also be useful for other libs, but how about we add this kind of helper to test.support at least? (maybe, let's make it first a mixin class before implementing it on unittest.TestCase)

Hmm, that could be interesting. What happens when x1s and xns aren't the same length?

Hum, it doesn't matter? we're computing a product not a zip().

Maybe I'm misunderstanding it. Is:

for a, b in self.cases(a=iter_a, b=iter_b)`:
    print(a, b)

supposed to be equivalent to:

for a in iter_a:
    for b in iter_b:
        print(a, b)

Yes. The rationale behind my suggestion is as follows:

for a in A:
	for b in B:
		with self.subTest(a=a, b=b):
			pass

We're already having 3 levels of indentation. Counting the class indentation and method indentation we're just having 20 whitespaces before wer start writing real code...:

class A:
	def f(self):
		for a in A:
			for b in B:
				with self.subTest(a=a, b=b):
					pass

In addition, if we're pretty short on the keywords passed to subTest() if we want to keep everything under 80 chars (so it's a product() + subTest() combo)

Oh, I get it--the a doesn't change with each iteration of cases. I think that could be an interesting addition, but we might also run into PEP-20:

There should be one-- and preferably only one --obvious way to do it.

One obvious way, probably but this obvious way makes the code really harder to read IMO. Anyway, this is a bit off-topic and I don't know how much we can use it (but I've personally needed more than once to be able to use products for testing cases).

Note that importlib's tests already has some "parametrize" decorator as in Pytest, so we could also move it up to test.support instead.

Are we using two blank lines to separate classes in this file?

It doesn't look like there are any other classes here.

Ah yes, most of the file is using 1-blank line. Up to you then.

Maybe it is better to use atomics here? AFAIU volatile have different behavior for msvc for different platforms.

Could be, but regardless, that should be done in a different PR.