homepage

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