[spambayes-dev] Bug in timcv.py

[Mark Hammond]

> > I noticed another curiosity in the traceback:  I ran the test from
> > inside directory "C:\src\python\spambayes_exp", which contains my
> > modified version of SpamBayes.  When the traceback gets to
> > classifier.py, however, you can see that classifier.py was
> loaded from
> > "C:\src\python\spambayes" instead, which is where I have my original
> > CVS version of SpamBayes.  I don't have any PYTHONPATH environment
> > variable set, and I don't know what else might cause it to
> jump paths
> > like that. Can one of you more experienced python'ers explain this?
>
> Run Python with -v to get a report of how every import got
> satisfied.  Then stare until your eyes bleed <0.9 wink>.

I guess that both the spambayes directory itself, *and* the spambayes
parent, are on sys.path (and probably the different versions of each).  Thus
'import Options' may be resolved as either 'spambayes.Options' or simply
'Options'.

But as Tim said, you can confirm it yourself if for some strange reason you
really care <wink>

> I notice that a lot of the scripts
> these days muck around with sys.path directly, thus changing
> Python's search
> path dynamically, at runtime.  That's *usually* a Bad Idea.

Yeah, I'd like to fix these, as I am responsible for some.  IMO, the
"package-ness" of SpamBayes isn't that well defined - mainly as the concept
was created after the core code.  The Outlook2000 directory isn't a package,
but arguably should be.

Another reason is that for Outlook, I have never insisted that a user do a
"setup.py install" before using the addin.  I attempt to use the code
directly from the source-tree, including the core spambayes package.  If we
do move towards forcing source-code users to use distutils to install the
package, we may be able to drop even more.

Is this a good thing?  Tim - I assume you tend to use SpamBayes directly
from the CVS tree - is that correct?  If so, you manage sys.path manually?

> If I were you,
> I'd take a critical look at the fix_sys_path() function in
> sb_test_support.py.  I don't know how this got so convoluted,
> but gobs of
> dynamic code trying to "fix" what should be statically known
> (or at worst
> fiddled once in a config file) is a pretty sure recipe for confusion.

Well, sb_test_support just got created *today*, so poor Kenny would not have
seen it when he sent the mail <wink>.  Also, this file is used *only* by the
'unit test style tests' rather than the 'validation style tests' that timcv
exists in.  The hacks in sb_test_support were a small step towards reducing
the sys.path hacking, but only for that single directory.

Mark.