[RFC][PERFORMANCE][PYREX][TIRED OF THESE YET?] *fast* walkdirs.

Martin Pool mbp at canonical.com
Mon Jun 19 05:09:13 BST 2006


On 16 Jun 2006, Robert Collins <robertc at robertcollins.net> wrote:
> On Fri, 2006-06-16 at 10:57 +1000, Martin Pool wrote:
> > > Why not do it this way: for some feature foo with an optional C
> > > implementation, have a foo.py that simply consists of:
> > >
> > >      try:
> > >           from _c_foo import *
> > >      except ImportError:
> > >           from _py_foo import *
> > >
> > > Where _c_foo would be the "foo" module in C, and _py_foo would be
> > > the pure python fallback.  Tests for "foo" can directly access
> > > both _c_foo  and _py_foo modules to make sure they both pass.
> > > Callers of foo get the C  version if available, and automatically
> > > get the python version if not.
> > 
> > I prefer something like spiv's approach, or something along those  
> > lines.  It doesn't seem that much harder and does mean that you can  
> > at least name the two modules, if we want to add tests that exercise  
> > both in the future.
> 
> Sure, we can do that. I dont understand your comment about adding tests
> later though: we can always start with a .so and .py with the same name
> and use our rename-supporting-VCS later to rename them to _c_ and _py_
> forms when we decide to add those tests. 

Yes, we can.

> Until we are writing those tests I would call the glue file a case of
> YAGNI.

I think I said earlier that I don't mind merging it in its present form
if you want to.  The discussion that followed was more about where we
want to go in the future.

I think it's desirable that, when possible, all the relevant code should
be tested from one invocation of the test suite.  When there are two
providers of a particular interface the test suite should arrange for
them both to be run.  If you give the modules different true names as
shown above then you can get at them both to test them.

Running the whole suite twice from the Makefile is OK but not ideal,
because it duplicates some tests where the results won't vary, depends
on people having Make, futzes with the build directory, etc.

So I'm totally OK to say YAGNI until someone decides we *do* need it,
but just aware of the way that in the past I've said that about
improving testability and paid a larger price.  But I know you have good
judgement on that, so add it if/when you want.

-- 
Martin




More information about the bazaar mailing list