[spambayes-dev] Nuke experimental_ham_spam_imbalance_adjustment?

[Tony Meyer]

[Skip]
> I don't really care what hoops we as programmers have to jump through, 
> but I'd like users to be able to use either x- or X-.  I agree, the 
> docstrings should match required usage.  In any case, it appears Tim 
> (or someone else) has fixed things).

What happens at the moment is that ConfigParser lowercases all the option
names (but not section names; I don't know whether that's deliberate or not)
when it reads them from a file.  So users can happily use "X-" or "x-" and
by the time OptionsClass deals with them it'll be "x-".  I changed the
comments so that they all use "x-", but haven't added anything about this.

Us programmers *must* use "x-" when referring to the options at the moment.

[Tim]
> I'd call that a bug in OptionsClass.py, then.  ConfigParser 
> is modeled on RFC 822 header fields, and supplies 
> case-insensitive option names *because* 822 mandates 
> case-insensitive semantics.

So should get/set in our OptionsClass also be case insensitive in situations
other than reading in the config files?  At the moment options["Sect",
"Opt"] != options["Sect", "opt"], but it would be a simple enough change
(and we certainly don't have any options with the same name but differing
case).

> Tony checked in a bunch of changes, but I suspect it's still 
> case-sensitive.

I made the mistake of checking things in before I really had figured out
what was happening in ConfigParser, so half the check-ins are repairing the
other half.  It's case-sensitive *apart* from reading in the file.

=Tony Meyer