[scikit-learn] Vote on SLEP010: n_features_in_ attribute
adrin.jalali at gmail.com
Wed Dec 4 05:38:37 EST 2019
I really don't think Py2.x should be our concern anymore.
The kind of spaghetti code you mention is somewhat the nature
of supporting multiple versions of a dependency library. We do have
similar code in our code base which deals with different versions of our
On Wed, Dec 4, 2019 at 11:06 AM Trevor Stephens <trev.stephens at gmail.com>
> Makes sense Joel, wasn't mentioned in the docs, so was a bit strange.
> Still feels a bit weird but I'm sure I'll adapt_in and thrive_out.
> Downstream projectwise, I'm happy to bounce my dependencies up whenever
> necessary. Always nice to support old versions of sklearn, but not at the
> expense of spaghetti code from my persepctive, whatever that's worth.
> Might be a bit more prickly for projects still trying to support Py2.x
> On Wed, Dec 4, 2019 at 8:53 PM Joel Nothman <joel.nothman at gmail.com>
>> We are looking to have n_features_out_ for transformers. This naming
>> makes the difference explicit.
>> I would like to see some guidance on how an estimator implementation
>> (e.g. in scikit-learn-contrib) is advised to maintain compatibility with
>> Scikit-learn pre- and post- SLEP010.
>> That is, we want to encourage developers to take advantage of
>> super()._validate_data(X, y), but we also don't want to force them to set a
>> minimal Scikit-learn >= 0.23 dependency (or do we?). What's the recommended
>> way to do implement fit and predict in such an implementation?
>> Is it to
>> (a) not use _validate_data until the minimal dependency is reached?
>> (b) implement a patched BaseEstimator in the library which inherits from
>> Scikit-learn's BaseEstimator and adds _validate_data?
>> (c) something else?
>> scikit-learn mailing list
>> scikit-learn at python.org
> scikit-learn mailing list
> scikit-learn at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the scikit-learn