[Python-Dev] how to test behavior wrt an extension type?

Alex Martelli aleax at aleax.it
Sun Jan 16 10:38:16 CET 2005


copy.py, as recently discussed starting from a post by /F, has two 
kinds of misbehaviors since 2.3 (possibly 2.2, haven't checked), both 
connected to instance/type/metatype confusion (where do special methods 
come from? in classic classes and types, from the instance, which may 
delegate to the type/class; in newstype one, from the class/type which 
_must not_ delegate to the metaclass): type/metatype confusion, and 
misbehavior with instances of extension types.

So, as per discussion here, I have prepared a patch (to the maintenance 
branch of 2.3, to start with) which adds unit tests to highlight these 
issues, and fixes them in copy.py.  This patch should go in the 
maintenance of 2.3 and 2.4, but in 2.5 a different approach based on 
new special descriptors for special methods is envisaged (though 
keeping compatibility with classic extension types may also require 
some patching to copy.py along the lines of my patch).

Problem: to write unit tests showing that the current copy.py 
misbehaves with a classic extension type, I need a classic extension 
type which defines __copy__ and __deepcopy__ just like /F's 
cElementTree does.  So, I made one: a small trycopy.c and accompanying 
setup.py whose only purpose in life is checking that instances of a 
classic type get copied correctly, both shallowly and deeply.  But now 
-- where do I commit this extension type, so that the unit tests in 
test_copy.py can do their job...?

Right now I've finessed the issue by having a try/except ImportError in 
the two relevant unit tests (for copy and deepcopy) -- if the trycopy 
module is not available I just don't test how its instances behave 
under deep or shallow copying.  However, if I just commit or send the 
patch as-is, without putting trycopy.c and its setup.py somewhere, then 
I'm basically doing a fix without unit tests to back it up, from the 
point of view of anybody but myself.

I do not know what the recommended practice is for this kind of issues, 
so, I'm asking for guidance (and specifically asking Anthony since my 
case deals with 2.3 and 2.4 maintenance and he's release manager for 
both, but, of course, everybody's welcome to help!).  Surely this can't 
be the first case in which a bug got triggered only by a certain 
behavior in an extension type, but I couldn't find precedents.  Ideas, 
suggestions, ...?


Alex



More information about the Python-Dev mailing list