[Spambayes] Maybe change X-Spam-Disposition to something else...

I actually like Neale's X-Spam-Disposition header, I just wonder if maybe we
should choose something with a different prefix than "X-Spam-" so that
people don't confuse it with SpamAssassin, all of whose headers begin with
that prefix.
Also, some sort of version information would be useful.  Perhaps the CVS
version number for the classifier module could be tacked on.
Skip

>>> Skip Montanaro wrote
>
> I actually like Neale's X-Spam-Disposition header, I just wonder if maybe we
> should choose something with a different prefix than "X-Spam-" so that
> people don't confuse it with SpamAssassin, all of whose headers begin with
> that prefix.
I think it's fine, in general, just so long as no-one checks in anything
that puts it into my test corpus.
Or alternately, whatever is chosen should be ignored by the tokenizer.
I know my mail host (interlink) runs SA, but I also run it, with my own
set of rules and scores. I don't want my spam-filter to be getting messed
up by an upstream spam filter.

Guido> Therefore I propose to nuke GBayes.py, after adding a -u feature.
Guido> Anyone against?  (I imagine that Skip or Barry might have a stake
Guido> in GBayes.py; Tim seems to have moved all code he's working to
Guido> other modules.)
No argument here.
Skip

If the frequency of my laptop's disk chirps are any indication, I'd say
hammie is about 3-5x faster than SpamAssassin.
Skip

So then, Tim Peters <tim.one@comcast.net> is all like:
> I'm not sure what you're doing, but suspect you're storing individual
> WordInfo pickles.  If so, most of the administrative pickle bloat is
> due to that, and doesn't happen if you pickle an entire classifier
> instance directly.
Yeah, that's exactly what I was doing--I didn't realize I was incurring
administrative pickle bloat this way.  I'm specifically trying to make
things faster and smaller, so I'm storing individual WordInfo pickles
into an anydbm dict (keyed by token).  The result is that it's almost 50
times faster to score messages one per run our of procmail (.408s vs
18.851s).
However, it *does* say all over the place that the goal of this project
isn't to make the fastest or the smallest implementation, so I guess
I'll hold off doing any further performance tuning until the goal starts
to point more in that direction.  .4 seconds is probably fast enough for
people to use it in their procmailrc, which is what I was after.
> If you're desparate to save memory, write a subclass?
That's probably what I'll do if I get too antsy :)
Trying to think of ways to sneak "administrative pickle boat" into
casual conversation,
Neale