<div dir="ltr"><div class="gmail_default" style="font-size:small">As far as I remember, one idea is to have a deprecation cycle with a FutureWarning on check estimator</div><div class="gmail_default" style="font-size:small">to give third party developers implement the new API.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 4, 2019 at 10:52 AM Joel Nothman <<a href="mailto:joel.nothman@gmail.com">joel.nothman@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">We are looking to have n_features_out_ for transformers. This naming makes the difference explicit.<div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>Is it to</div><div>(a) not use _validate_data until the minimal dependency is reached?</div><div>(b) implement a patched BaseEstimator in the library which inherits from Scikit-learn's BaseEstimator and adds _validate_data?</div><div>(c) something else?</div><div><br></div><div><br>Joel</div></div>
_______________________________________________<br>
scikit-learn mailing list<br>
<a href="mailto:scikit-learn@python.org" target="_blank">scikit-learn@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/scikit-learn" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/scikit-learn</a><br>
</blockquote></div>