Re: [scikit-learn] Vote on SLEP010: n_features_in_ attribute

According to our governance model, this vote is now closed and accepted, and the implementation shall take the concerns mentioned here into account. Thanks everybody for the attention and the discussion. On Sat, Dec 21, 2019 at 6:36 PM Thomas J Fan wrote: > I am +1. I aggree with Joel that

Re: [scikit-learn] Vote on SLEP010: n_features_in_ attribute

I am +1. I aggree with Joel that we should look into making these methods (or maybe functions) usable by external developers. Thomas > On Monday, Dec 16, 2019 at 4:20 PM, Alexandre Gramfort > mailto:alexandre.gramf...@inria.fr)> wrote: > +1 on SLEP + adding an estimator tag if it does not

Re: [scikit-learn] Vote on SLEP010: n_features_in_ attribute

+1 on SLEP + adding an estimator tag if it does not apply eg Text vectorizers etc. Alex ___ scikit-learn mailing list scikit-learn@python.org https://mail.python.org/mailman/listinfo/scikit-learn

Re: [scikit-learn] Vote on SLEP010: n_features_in_ attribute

I am +1 as well. I think that what proposed by @Joel Nothman should be considered. It seems that we have cases that we know that it is not meant to have the parameters (e.g., Vectorizer). I think that it would make sense to have an estimator tag. Thus, the FutureWarning for a third-party library

Re: [scikit-learn] Vote on SLEP010: n_features_in_ attribute

+1 for me. Best, Bertrand On 03/12/2019 23:09, Nicolas Hug wrote: As per our Governance document, changes to API principles are to be established through an Enhancement Proposal (SLEP) from which any core developer can call for a vote on its

Re: [scikit-learn] Vote on SLEP010: n_features_in_ attribute

On 04/12/2019 20:44, Joel Nothman wrote: I am +1 for this, but I think we should look at how to make these new validation methods usable by external developers +1 for the SLEP and for finding a way to make this method usable by external developers maybe as part of the developer API.

Re: [scikit-learn] Vote on SLEP010: n_features_in_ attribute

I am +1 for this, but I think we should look at how to make these new validation methods usable by external developers ideally supporting multiple Scikit-learn versions (i.e. we need something in stable public or protected API). A simple solution is to make default implementations of

Re: [scikit-learn] Vote on SLEP010: n_features_in_ attribute

On 12/4/19 5:05 AM, Trevor Stephens wrote: 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. Indeed, and as Joel said, we'll have n_features_out_ added soon. Having both is quite helpful in many

Re: [scikit-learn] Vote on SLEP010: n_features_in_ attribute

I agree / recall that that was what we settled on. So a) but even more conservative ;) On 12/4/19 5:03 AM, Joel Nothman wrote: Oh... I remember what we landed up on, actually... we've made _validate_data private so downstream estimators can't technically expect to use it reliably across any

Re: [scikit-learn] Vote on SLEP010: n_features_in_ attribute

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 own dependencies. On Wed, Dec 4,

Re: [scikit-learn] Vote on SLEP010: n_features_in_ attribute

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

Re: [scikit-learn] Vote on SLEP010: n_features_in_ attribute

Oh... I remember what we landed up on, actually... we've made _validate_data private so downstream estimators can't technically expect to use it reliably across any versions... ___ scikit-learn mailing list scikit-learn@python.org

Re: [scikit-learn] Vote on SLEP010: n_features_in_ attribute

As far as I remember, one idea is to have a deprecation cycle with a FutureWarning on check estimator to give third party developers implement the new API. On Wed, Dec 4, 2019 at 10:52 AM Joel Nothman wrote: > We are looking to have n_features_out_ for transformers. This naming makes > the

Re: [scikit-learn] Vote on SLEP010: n_features_in_ attribute

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

Re: [scikit-learn] Vote on SLEP010: n_features_in_ attribute

Perhaps because some skl objects have R *n_features_in*, but then S *n_features_out*, where S!=R. Andrew <~~~> J. Andrew Howe, PhD LinkedIn Profile ResearchGate Profile Open Researcher

Re: [scikit-learn] Vote on SLEP010: n_features_in_ attribute

Not a core contributor, but what's with the "_in" bit? Just go with a public n_features which I think a bunch of estimators already have? Feels clumsy On Wed, Dec 4, 2019 at 8:22 PM Andrew Howe wrote: > Excellent idea. > > > <~~~> > J. Andrew Howe, PhD > LinkedIn Profile

Re: [scikit-learn] Vote on SLEP010: n_features_in_ attribute

Excellent idea. <~~~> J. Andrew Howe, PhD LinkedIn Profile ResearchGate Profile Open Researcher and Contributor ID (ORCID) Github Profile

Re: [scikit-learn] Vote on SLEP010: n_features_in_ attribute

+1 (seems that users are unhappy because we vote in the mailing list?) Hanmin Qin - Original Message - From: Gael Varoquaux To: Scikit-learn mailing list Subject: Re: [scikit-learn] Vote on SLEP010: n_features_in_ attribute Date: 2019-12-04 12:34 +1. Great job! Gaël On Tue, Dec 03

Re: [scikit-learn] Vote on SLEP010: n_features_in_ attribute

+1. Great job! Gaël On Tue, Dec 03, 2019 at 05:58:44PM -0500, Nicolas Hug wrote: > +1 > On 12/3/19 5:40 PM, Adrin wrote: > +1 > On Tue., Dec. 3, 2019, 23:28 Andreas Mueller, wrote: > +1 > On 12/3/19 5:09 PM, Nicolas Hug wrote: > As per our Governance

Re: [scikit-learn] Vote on SLEP010: n_features_in_ attribute

+1 On 12/3/19 5:40 PM, Adrin wrote: +1 On Tue., Dec. 3, 2019, 23:28 Andreas Mueller, > wrote: +1 On 12/3/19 5:09 PM, Nicolas Hug wrote: As per our Governance document, changes to API principles

Re: [scikit-learn] Vote on SLEP010: n_features_in_ attribute

STOP. I DON'T WANT TO BE MAILED AGAIN Le mar. 3 déc. 2019 à 23:41, Adrin a écrit : > +1 > > On Tue., Dec. 3, 2019, 23:28 Andreas Mueller, wrote: > >> +1 >> >> On 12/3/19 5:09 PM, Nicolas Hug wrote: >> >> As per our Governance >> document,

Re: [scikit-learn] Vote on SLEP010: n_features_in_ attribute

+1 On Tue., Dec. 3, 2019, 23:28 Andreas Mueller, wrote: > +1 > > On 12/3/19 5:09 PM, Nicolas Hug wrote: > > As per our Governance > document, changes to API principles are to be established through an > Enhancement Proposal (SLEP) from which any

Re: [scikit-learn] Vote on SLEP010: n_features_in_ attribute

+1 On 12/3/19 5:09 PM, Nicolas Hug wrote: As per our Governance document, changes to API principles are to be established through an Enhancement Proposal (SLEP) from which any core developer can call for a vote on its acceptance. * *

[scikit-learn] Vote on SLEP010: n_features_in_ attribute

As per our Governance document, changes to API principles are to be established through an Enhancement Proposal (SLEP) from which any core developer can call for a vote on its acceptance. * * *SLEP010: n_features_in attribute *is up for a vote.