(changing the title to disassociate it from a particular solution)

>> * make sure the original test case does not get used (#16835),
>
> PEP 399 dictates that the base class does not inherit from
> unittest.TestCase, so why would it be used?

Sorry for any confusion.  In this list I was enumerating what you have to do to accommodate PEP 399, rather than any new behavior.  Hopefully I wasn't too far off. :)  I'd expect that any solution to reduce boilerplate here (like the decorator) would address these responsibilities.

>> * use the relevant names as class attributes rather than globals (e.g.
>> self.OrderedDict vs. OrderedDict),
>
> Wouldn't it be better to suggest this in PEP 399? Otherwise, the proposed
> decarator kind-of goes against it.

PEP 399 already espouses the approach of using a class attribute to hold the module under test, though it doesn't require it.  You're right that the decorator obviates the need to make that change when accommodating PEP 399.

>> * hack around modules that do their own imports (#16817),
> Can you clarify how this helps? I though the decorator doesn't (yet?)
> handle the problem with pickle.

If a boilerplate solution can make it so that we don't have to hack around these situations whenever they come up, I think it'd be a win.  The decorator currently doesn't do this, but I'd expect that any solution we accepted would.

That said, if there is a risk of something like the decorator causing other problems then the status quo is certainly better even if it's more work.  :)

>> * relatedly, the solution is more magic/obfuscated that the current
>> boilerplate.
>>
>> ...
>
> I agree that it can be made clearer, but you are unlikely to lose the
> metaprogramming magic.

Yeah, if the right balance can't be struck then I definitely agree that we're better of with the way things are.

> Is it possible to just rewrite the tests to use collections.OrderedDict?
> IMHO this extra 'names' argument adds a lot of magic to the decorator, and
> if it's just there for a problem that's easy to avoid...

That's a good idea.

Thanks for the feedback, Eli.