I am +1 as well. I think that what proposed by @Joel Nothman <joel.noth...@gmail.com> 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 might mention adding n_feature_in_ or adding an estimator tag if it does not apply.
On Sun, 15 Dec 2019 at 23:39, bthirion <bertrand.thir...@inria.fr> wrote: > +1 for me. > Best, > Bertrand > > On 03/12/2019 23:09, Nicolas Hug wrote: > > As per our Governance <http://scikit-learn.org/stable/governance.html> > 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. Please see > https://scikit-learn-enhancement-proposals.readthedocs.io/en/latest/slep010/proposal.html > > *This SLEP proposes the introduction of a public n_features_in_ attribute > for most estimators* > > Core developers are invited to vote on this change until 4 January 2020 by > replying to this email thread. > > All members of the community are welcome to comment on the proposal on > this mailing list, or to propose minor changes through Issues and Pull > Requests at https://github.com/scikit-learn/enhancement_proposals/. > > _______________________________________________ > scikit-learn mailing > listscikit-learn@python.orghttps://mail.python.org/mailman/listinfo/scikit-learn > > > _______________________________________________ > scikit-learn mailing list > scikit-learn@python.org > https://mail.python.org/mailman/listinfo/scikit-learn > -- Guillaume Lemaitre Scikit-learn @ Inria Foundation https://glemaitre.github.io/
_______________________________________________ scikit-learn mailing list scikit-learn@python.org https://mail.python.org/mailman/listinfo/scikit-learn
