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

[Adrin]

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 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.gramf...@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
>
___
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

[Thomas J Fan]

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 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

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

[Alexandre Gramfort]

+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

[Guillaume Lemaître]

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 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  wrote:

> +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 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

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

[bthirion]

+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 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

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

[Roman Yurchak]

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.

___
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

[Joel Nothman]

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.
___
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

[Andreas Mueller]

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 > 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


___
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

[Andreas Mueller]

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


___
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

[Adrin]

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 
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 
> 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
>
___
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

[Trevor Stephens]

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  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

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

[Joel Nothman]

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

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

[Adrin]

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 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

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

[Joel Nothman]

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

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

[Andrew Howe]

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 and Contributor ID (ORCID)

Github Profile 
Personal Website 
I live to learn, so I can learn to live. - me
<~~~>


On Wed, Dec 4, 2019 at 9:43 AM Trevor Stephens 
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  wrote:
>
>> Excellent idea.
>>
>>
>> <~~~>
>> J. Andrew Howe, PhD
>> LinkedIn Profile 
>> ResearchGate Profile 
>> Open Researcher and Contributor ID (ORCID)
>> 
>> Github Profile 
>> Personal Website 
>> I live to learn, so I can learn to live. - me
>> <~~~>
>>
>>
>> On Tue, Dec 3, 2019 at 10:14 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

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

[Trevor Stephens]

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 
> ResearchGate Profile 
> Open Researcher and Contributor ID (ORCID)
> 
> Github Profile 
> Personal Website 
> I live to learn, so I can learn to live. - me
> <~~~>
>
>
> On Tue, Dec 3, 2019 at 10:14 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

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

[Andrew Howe]

Excellent idea.


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

Github Profile 
Personal Website 
I live to learn, so I can learn to live. - me
<~~~>


On Tue, Dec 3, 2019 at 10:14 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

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

[Hanmin Qin]

+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, 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 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.infohttp://twitter.com/GaelVaroquaux
___
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

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

[Gael Varoquaux]

+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 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.infohttp://twitter.com/GaelVaroquaux
___
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

[Nicolas Hug]

+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 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

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

[Compte.validation]

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, 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
>>
> ___
> 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

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

[Adrin]

+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 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
>
___
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

[Andreas Mueller]

+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] Vote on SLEP010: n_features_in_ attribute

[Nicolas Hug]

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