On Sat, Jan 26, 2013 at 9:10 AM, Eric Snow <report@bugs.python.org> wrote:

>
> Eric Snow added the comment:
>
> In my case I've been doing PEP 399 for collections.OrderedDict.  It struck
> me that the boilerplate could be stowed away in a decorator.  It's more
> than just adding a couple subclasses.  Here's what it covers:
>
> * add the test case subclasses,
> * 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?

> * 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.

> * 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.

> * "explicit is better than implicit",
> * relatedly, the solution is more magic/obfuscated that the current
> boilerplate.
>
> You could argue that the magnitude of the problem doesn't warrant a
> complex decorator, but it doesn't have to be hard to understand.  My patch
> is something I threw together late last night that could certainly be made
> more clear.  More importantly, as more modules get a dual implementation,
> the above benefits of the decorator become more pronounced.
>
>
I agree that it can be made clearer, but you are unlikely to lose the
metaprogramming magic.

> My use case was with the tests for OrderedDict.  The existing tests don't
> refer to > collections.OrderedDict, but rather to OrderedDict (looked up
from the globals).
> The names argument facilitates the replacement of OrderedDict.

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...