[scikit-learn] Vote on SLEP010: n_features_in_ attribute

[Trevor Stephens]

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
though?

On Wed, Dec 4, 2019 at 8:53 PM Joel Nothman <joel.nothman at gmail.com> wrote:

> 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?
>
>
> Joel
> _______________________________________________
> scikit-learn mailing list
> scikit-learn at python.org
> https://mail.python.org/mailman/listinfo/scikit-learn
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-learn/attachments/20191204/a0a3d6ff/attachment-0001.html>