[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