[spambayes-dev] Re: Pickle vs DB inconsistencies

[Greg Ward]

On 09 July 2003, Meyer, Tony said:
> +1 to changing these so that they are consistent.  I'm not sure about
> your suggestion - I see that -p makes sense, but so many of the scripts
> use -d/-D that I wonder if that would be the better option, i.e.:
> 
>    <script> -d spambayes.db    # load a DBM store
>    <script> -D spambayes.pkl   # load a pickle store

No, that is definitely the *worse* option, because it has no mnemonic
value.  (I'm ignoring historical precedent, user expectations, and all
that.)  That's why I like -d to load a DB[M] file and -p to open a
pickle.

> (Note that TimS thinks that we should drop pickle support, which would
> *definitely* simplify the options :)

My recent experiences with bugs in the DB[M] storage -- still the
ostensible subject of this thread! -- are a good argument against this.
Tim P's words were along the lines of, "The pickle implementation is so
simple that it's obviously correct", and it's good to have a gold
standard, even if it is a memory hog and slow to startup.

> This applies to all the scripts, really (i.e. pop3proxy could be any
> POP3 proxy, and so on).  They make sense as long as they're in a
> spambayes directory, but not once outside.  The question is what to
> rename them (if they are renamed).  I suppose they could all just be
> prefixed with 'spambayes' (spambayes-dbExpImp.py,
> spambayes-pop3proxy.py, etc).

But all the scripts are listed in 'scripts' in setup.py, which means
they get installed to (eg.) /usr/local/bin or /usr/bin on a Unix system.
Installing something with a bland, generic name like 'unheader' or
'smptproxy' to /usr/bin is really not a good thing.

(I'm also not a fan of the .py extension on scripts, for reasons that I
really can't explain.  I think it's because it reveals an irrelevant
implementation detail -- the programming language used -- to users of
the script.  Damn, I guess I should have added an install-time distutils
option to strip .py from script names.  Unfortunately, my time machine
isn't as good as Guido's.)

> It still kinda is cute ;)  Plus no-one has suggested an alterative
> name...

Hey, I'm suggesting a whole alternative naming scheme: sb-<verb>, where
<verb> is "train", "score", "filter", "export", "import", etc.

> > Come to think of it, 
> > hammiesrv.py, hammiefilter.py, and hammiecli.py are almost as bad.
> 
> You think that sb-server, sb-filter and sb-client are better names?

Absolutely!

> Can the 2.3 optparse module just be dropped into a 2.2 setup?

Yes, Optik works at least as far back as Python 2.1.  Maybe 2.0, but I
haven't tested it.

> (BTW, why
> can I import optparse in 2.2.3 when the doc says it only arrives in
> 2.3?)

Good question -- I guess someone backported it when I wasn't looking!

        Greg
-- 
Greg Ward <gward at python.net>                         http://www.gerg.ca/
Yield to temptation; it may not pass your way again.