I saw in several places this pattern:

class ContinuousFeature(BaseFeature):
    def __init__(self, key=None, preprocessor=None, imputer=None, scaler=None, log=False,
                 log_auto_scale=True):
        self.key = key
        self.preprocessor = preprocessor
        self.imputer = (imputer or SimpleImputer()) if imputer != False else None
        self.scaler = (scaler or StandardScaler()) if scaler != False else None
        self.log = log
        self.log_auto_scale = log_auto_scale

Lets focus on '''scaler''' for instance.
Reading the code, what I'm guessing is that what you want to offer to the developer using the lib, the following choices:

• leave parameter with default value None, which internally will invoke a StandardScaler
• provide her own scaler
• use no scaler at all, by providing False value on that parameter

Those seems too many options, not straightforward to think about, to use, or to code (onfire code is twisted for accomplishing this matter).
Not only that, but the code is also breaking the expectations. If the user writes ContinuousFeature(scaler=None) but instead get an instance with an StandardScaler, sounds like a bug to me (although you may say it's a feature).

Posible better UX:

• default is None, and it's used as it is (which means, no scaler). And the usual python applies. False, 0, etc, are interpreted as None as well.