<div dir="ltr"><div class="gmail_default" style="font-size:small">I really don't think Py2.x should be our concern anymore.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The kind of spaghetti code you mention is somewhat the nature</div><div class="gmail_default" style="font-size:small">of supporting multiple versions of a dependency library. We do have</div><div class="gmail_default" style="font-size:small">similar code in our code base which deals with different versions of our</div><div class="gmail_default" style="font-size:small">own dependencies.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 4, 2019 at 11:06 AM Trevor Stephens <<a href="mailto:trev.stephens@gmail.com">trev.stephens@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">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.<div><br></div><div>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. </div><div><br></div><div>Might be a bit more prickly for projects still trying to support Py2.x though?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 4, 2019 at 8:53 PM Joel Nothman <<a href="mailto:joel.nothman@gmail.com" target="_blank">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>
_______________________________________________<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>