> Arh! Crap.

transform and inverse_transform are not supposed to change the state of the object so I feel that it's really ugly to change the state of the object just to call these methods:
```python
for threshold in thresholds:
    label_binarizer.threshold = threshold
    predictions = label_binarizer.inverse_transform(dec_func)
    # compute precision-recall
```
For the option specifying the output format of inverse_transform, the user is less likely to want to call it several times with different values so I feel it more acceptable to have the option as a constructor parameter, though I don't really see the benefit.

> Nothing specifies whether these parameters can be changed or not between the fit and the transform.

From a software engineering point of view, directly changing the attribute of an object requires knowledge of how the object works internally. For fit, it's less of a problem because if you change attributes and recall fit, it's like you reinitialized the object. For transform or inverse_transform, how do you know that the attribute you just changed doesn't also affect the behavior of fit, unless you know the code? Code like this is also more likely to break in case of API change.

I do agree that constructor parameters that concern transform can be useful for grid search or pipelines, though.