Vote on SLEP010: n_features_in_ attribute
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/... * * * *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/.
+1 On 12/3/19 5:09 PM, 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/... * * * *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 list scikit-learn@python.org https://mail.python.org/mailman/listinfo/scikit-learn
+1 On Tue., Dec. 3, 2019, 23:28 Andreas Mueller, <t3kcit@gmail.com> wrote:
+1
On 12/3/19 5:09 PM, 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/...
*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
STOP. I DON'T WANT TO BE MAILED AGAIN Le mar. 3 déc. 2019 à 23:41, Adrin <adrin.jalali@gmail.com> a écrit :
+1
On Tue., Dec. 3, 2019, 23:28 Andreas Mueller, <t3kcit@gmail.com> wrote:
+1
On 12/3/19 5:09 PM, 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/...
*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
_______________________________________________ scikit-learn mailing list scikit-learn@python.org https://mail.python.org/mailman/listinfo/scikit-learn
+1 On 12/3/19 5:40 PM, Adrin wrote:
+1
On Tue., Dec. 3, 2019, 23:28 Andreas Mueller, <t3kcit@gmail.com <mailto:t3kcit@gmail.com>> wrote:
+1
On 12/3/19 5:09 PM, 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/... * * * *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 list scikit-learn@python.org <mailto:scikit-learn@python.org> https://mail.python.org/mailman/listinfo/scikit-learn
_______________________________________________ scikit-learn mailing list scikit-learn@python.org <mailto:scikit-learn@python.org> https://mail.python.org/mailman/listinfo/scikit-learn
_______________________________________________ scikit-learn mailing list scikit-learn@python.org https://mail.python.org/mailman/listinfo/scikit-learn
+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, <t3kcit@gmail.com> 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 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 list scikit-learn@python.org https://mail.python.org/mailman/listinfo/scikit-learn
_______________________________________________ scikit-learn mailing list scikit-learn@python.org https://mail.python.org/mailman/listinfo/scikit-learn
_______________________________________________ scikit-learn mailing list scikit-learn@python.org https://mail.python.org/mailman/listinfo/scikit-learn
_______________________________________________ scikit-learn mailing list scikit-learn@python.org https://mail.python.org/mailman/listinfo/scikit-learn
-- Gael Varoquaux Research Director, INRIA Visiting professor, McGill http://gael-varoquaux.info http://twitter.com/GaelVaroquaux
Excellent idea. <~~~~~~~~~~~~~~~~~~~~~~~~~~~> J. Andrew Howe, PhD LinkedIn Profile <http://www.linkedin.com/in/ahowe42> ResearchGate Profile <http://www.researchgate.net/profile/John_Howe12/> Open Researcher and Contributor ID (ORCID) <http://orcid.org/0000-0002-3553-1990> Github Profile <http://github.com/ahowe42> Personal Website <http://www.andrewhowe.com> I live to learn, so I can learn to live. - me <~~~~~~~~~~~~~~~~~~~~~~~~~~~> On Tue, Dec 3, 2019 at 10:14 PM Nicolas Hug <niourf@gmail.com> 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/...
*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 list scikit-learn@python.org https://mail.python.org/mailman/listinfo/scikit-learn
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 <ahowe42@gmail.com> wrote:
Excellent idea.
<~~~~~~~~~~~~~~~~~~~~~~~~~~~> J. Andrew Howe, PhD LinkedIn Profile <http://www.linkedin.com/in/ahowe42> ResearchGate Profile <http://www.researchgate.net/profile/John_Howe12/> Open Researcher and Contributor ID (ORCID) <http://orcid.org/0000-0002-3553-1990> Github Profile <http://github.com/ahowe42> Personal Website <http://www.andrewhowe.com> I live to learn, so I can learn to live. - me <~~~~~~~~~~~~~~~~~~~~~~~~~~~>
On Tue, Dec 3, 2019 at 10:14 PM Nicolas Hug <niourf@gmail.com> 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/...
*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 list scikit-learn@python.org https://mail.python.org/mailman/listinfo/scikit-learn
_______________________________________________ scikit-learn mailing list scikit-learn@python.org https://mail.python.org/mailman/listinfo/scikit-learn
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 <http://www.linkedin.com/in/ahowe42> ResearchGate Profile <http://www.researchgate.net/profile/John_Howe12/> Open Researcher and Contributor ID (ORCID) <http://orcid.org/0000-0002-3553-1990> Github Profile <http://github.com/ahowe42> Personal Website <http://www.andrewhowe.com> I live to learn, so I can learn to live. - me <~~~~~~~~~~~~~~~~~~~~~~~~~~~> On Wed, Dec 4, 2019 at 9:43 AM Trevor Stephens <trev.stephens@gmail.com> wrote:
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 <ahowe42@gmail.com> wrote:
Excellent idea.
<~~~~~~~~~~~~~~~~~~~~~~~~~~~> J. Andrew Howe, PhD LinkedIn Profile <http://www.linkedin.com/in/ahowe42> ResearchGate Profile <http://www.researchgate.net/profile/John_Howe12/> Open Researcher and Contributor ID (ORCID) <http://orcid.org/0000-0002-3553-1990> Github Profile <http://github.com/ahowe42> Personal Website <http://www.andrewhowe.com> I live to learn, so I can learn to live. - me <~~~~~~~~~~~~~~~~~~~~~~~~~~~>
On Tue, Dec 3, 2019 at 10:14 PM Nicolas Hug <niourf@gmail.com> 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/...
*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 list scikit-learn@python.org https://mail.python.org/mailman/listinfo/scikit-learn
_______________________________________________ scikit-learn mailing list scikit-learn@python.org https://mail.python.org/mailman/listinfo/scikit-learn
_______________________________________________ scikit-learn mailing list scikit-learn@python.org https://mail.python.org/mailman/listinfo/scikit-learn
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
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 <joel.nothman@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@python.org https://mail.python.org/mailman/listinfo/scikit-learn
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...
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 versions...
_______________________________________________ scikit-learn mailing list scikit-learn@python.org https://mail.python.org/mailman/listinfo/scikit-learn
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@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@python.org https://mail.python.org/mailman/listinfo/scikit-learn
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, 2019 at 11:06 AM Trevor Stephens <trev.stephens@gmail.com> 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.
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@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@python.org https://mail.python.org/mailman/listinfo/scikit-learn
_______________________________________________ scikit-learn mailing list scikit-learn@python.org https://mail.python.org/mailman/listinfo/scikit-learn
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 situations. The naming is also meant to be analogous to future "feature_names_in_" and "feature_names_out_ attribute. Right now we have "get_feature_names()", which actually refers to the output features. That's a whole lot of new attributes, but after quite a lot of deliberation that's the solution we came up with, as there were major flaws in all other proposals. The SLEP for that is being rewritten right now. There's some conversation in https://github.com/scikit-learn/enhancement_proposals/pull/18 but the document doesn't reflect the current consensus. Andy
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@gmail.com <mailto:joel.nothman@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@python.org <mailto:scikit-learn@python.org> https://mail.python.org/mailman/listinfo/scikit-learn
_______________________________________________ scikit-learn mailing list scikit-learn@python.org https://mail.python.org/mailman/listinfo/scikit-learn
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 validate_data available as public helpers.
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.
+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/... * * * *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 list scikit-learn@python.org https://mail.python.org/mailman/listinfo/scikit-learn
I am +1 as well. I think that what proposed by @Joel Nothman <joel.nothman@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.thirion@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/...
*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/
+1 on SLEP + adding an estimator tag if it does not apply eg Text vectorizers etc. Alex
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 <alexandre.gramfort@inria.fr (mailto:alexandre.gramfort@inria.fr)> wrote: +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
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 <thomasjpfan@gmail.com> wrote:
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 < alexandre.gramfort@inria.fr> wrote: +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
_______________________________________________ scikit-learn mailing list scikit-learn@python.org https://mail.python.org/mailman/listinfo/scikit-learn
participants (13)
-
Adrin -
Alexandre Gramfort -
Andreas Mueller -
Andrew Howe -
bthirion -
Compte.validation -
Gael Varoquaux -
Guillaume Lemaître -
Joel Nothman -
Nicolas Hug -
Roman Yurchak -
Thomas J Fan -
Trevor Stephens