[spambayes-dev] Re: Pickle vs DB inconsistencies
Greg Ward
gward at python.net
Sun Jul 13 22:09:34 EDT 2003
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.
More information about the spambayes-dev
mailing list