Re: [scikit-learn] Vote on SLEP009: keyword only arguments
I'll vote +1, though there're still lots of things to decide. Hanmin Qin ----- Original Message ----- From: Alexandre Gramfort <alexandre.gramfort@inria.fr> To: Scikit-learn mailing list <scikit-learn@python.org> Subject: Re: [scikit-learn] Vote on SLEP009: keyword only arguments Date: 2019-09-12 03:43
But overall I'm + 1 on forcing kwargs for all __init__ methods. yes I think it will help for __init__ methods Alex PS : I don't shoot people (usually...)
scikit-learn mailing list scikit-learn@python.org https://mail.python.org/mailman/listinfo/scikit-learn
These there details of specific API changes to be decided: The question being put, as per the SLEP, is: do we want to utilise Python 3's force-keyword-argument syntax and to change existing APIs which support arguments positionally to use this syntax, via a deprecation period?
To the question: do we want to utilise Python 3's force-keyword-argument syntax and to change existing APIs which support arguments positionally to use this syntax, via a deprecation period? I am +1. IMO, even if the syntax might be unknown, it will remain unknown until projects from the ecosystem are not using it. To the question: which methods should be impacted? I think we should be as gentle as possible at first. I am a little concerned about breaking some codes which were working fine before. On Thu, 12 Sep 2019 at 04:43, Joel Nothman <joel.nothman@gmail.com> wrote:
These there details of specific API changes to be decided:
The question being put, as per the SLEP, is: do we want to utilise Python 3's force-keyword-argument syntax and to change existing APIs which support arguments positionally to use this syntax, via a deprecation period? _______________________________________________ scikit-learn mailing list scikit-learn@python.org https://mail.python.org/mailman/listinfo/scikit-learn
-- Guillaume Lemaitre INRIA Saclay - Parietal team Center for Data Science Paris-Saclay https://glemaitre.github.io/
I don't know what is the policy about a sklearn 1.0 w.r.t api changes. If it's meant to be a special release with possible api changes without deprecation cycles, I think this change is a good candidate for 1.0 Otherwise I'm +1 and agree with Guillaume, people will get used to it by using it. Jérémie On 12/09/2019 10:06, Guillaume Lemaître wrote:
To the question: do we want to utilise Python 3's force-keyword-argument syntax and to change existing APIs which support arguments positionally to use this syntax, via a deprecation period?
I am +1.
IMO, even if the syntax might be unknown, it will remain unknown until projects from the ecosystem are not using it.
To the question: which methods should be impacted?
I think we should be as gentle as possible at first. I am a little concerned about breaking some codes which were working fine before.
On Thu, 12 Sep 2019 at 04:43, Joel Nothman <joel.nothman@gmail.com <mailto:joel.nothman@gmail.com>> wrote:
These there details of specific API changes to be decided:
The question being put, as per the SLEP, is: do we want to utilise Python 3's force-keyword-argument syntax and to change existing APIs which support arguments positionally to use this syntax, via a deprecation period? _______________________________________________ scikit-learn mailing list scikit-learn@python.org <mailto:scikit-learn@python.org> https://mail.python.org/mailman/listinfo/scikit-learn
-- Guillaume Lemaitre INRIA Saclay - Parietal team Center for Data Science Paris-Saclay https://glemaitre.github.io/
_______________________________________________ scikit-learn mailing list scikit-learn@python.org https://mail.python.org/mailman/listinfo/scikit-learn
I am +1 for this change. I agree that users will accommodate the syntax sooner or later. On Fri., 13 Sep. 2019, 7:54 pm Jeremie du Boisberranger, < jeremie.du-boisberranger@inria.fr> wrote:
I don't know what is the policy about a sklearn 1.0 w.r.t api changes.
If it's meant to be a special release with possible api changes without deprecation cycles, I think this change is a good candidate for 1.0
Otherwise I'm +1 and agree with Guillaume, people will get used to it by using it.
Jérémie
On 12/09/2019 10:06, Guillaume Lemaître wrote:
To the question: do we want to utilise Python 3's force-keyword-argument syntax and to change existing APIs which support arguments positionally to use this syntax, via a deprecation period?
I am +1.
IMO, even if the syntax might be unknown, it will remain unknown until projects from the ecosystem are not using it.
To the question: which methods should be impacted?
I think we should be as gentle as possible at first. I am a little concerned about breaking some codes which were working fine before.
On Thu, 12 Sep 2019 at 04:43, Joel Nothman <joel.nothman@gmail.com> wrote:
These there details of specific API changes to be decided:
The question being put, as per the SLEP, is: do we want to utilise Python 3's force-keyword-argument syntax and to change existing APIs which support arguments positionally to use this syntax, via a deprecation period? _______________________________________________ scikit-learn mailing list scikit-learn@python.org https://mail.python.org/mailman/listinfo/scikit-learn
-- Guillaume Lemaitre INRIA Saclay - Parietal team Center for Data Science Paris-Saclay https://glemaitre.github.io/
_______________________________________________ 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
+1 from me On Sat, Sep 14, 2019 at 8:12 AM Joel Nothman <joel.nothman@gmail.com> wrote:
I am +1 for this change.
I agree that users will accommodate the syntax sooner or later.
On Fri., 13 Sep. 2019, 7:54 pm Jeremie du Boisberranger, < jeremie.du-boisberranger@inria.fr> wrote:
I don't know what is the policy about a sklearn 1.0 w.r.t api changes.
If it's meant to be a special release with possible api changes without deprecation cycles, I think this change is a good candidate for 1.0
Otherwise I'm +1 and agree with Guillaume, people will get used to it by using it.
Jérémie
On 12/09/2019 10:06, Guillaume Lemaître wrote:
To the question: do we want to utilise Python 3's force-keyword-argument syntax and to change existing APIs which support arguments positionally to use this syntax, via a deprecation period?
I am +1.
IMO, even if the syntax might be unknown, it will remain unknown until projects from the ecosystem are not using it.
To the question: which methods should be impacted?
I think we should be as gentle as possible at first. I am a little concerned about breaking some codes which were working fine before.
On Thu, 12 Sep 2019 at 04:43, Joel Nothman <joel.nothman@gmail.com> wrote:
These there details of specific API changes to be decided:
The question being put, as per the SLEP, is: do we want to utilise Python 3's force-keyword-argument syntax and to change existing APIs which support arguments positionally to use this syntax, via a deprecation period? _______________________________________________ scikit-learn mailing list scikit-learn@python.org https://mail.python.org/mailman/listinfo/scikit-learn
-- Guillaume Lemaitre INRIA Saclay - Parietal team Center for Data Science Paris-Saclay https://glemaitre.github.io/
_______________________________________________ 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
I vote +1 Hopefully keyword-only args become normalized and a future will come where I won't see `x.sum(0)` anymore VN On Sat, Sep 14, 2019 at 11:23 PM Thomas J Fan <thomasjpfan@gmail.com> wrote:
+1 from me
On Sat, Sep 14, 2019 at 8:12 AM Joel Nothman <joel.nothman@gmail.com> wrote:
I am +1 for this change.
I agree that users will accommodate the syntax sooner or later.
On Fri., 13 Sep. 2019, 7:54 pm Jeremie du Boisberranger, < jeremie.du-boisberranger@inria.fr> wrote:
I don't know what is the policy about a sklearn 1.0 w.r.t api changes.
If it's meant to be a special release with possible api changes without deprecation cycles, I think this change is a good candidate for 1.0
Otherwise I'm +1 and agree with Guillaume, people will get used to it by using it.
Jérémie
On 12/09/2019 10:06, Guillaume Lemaître wrote:
To the question: do we want to utilise Python 3's force-keyword-argument syntax and to change existing APIs which support arguments positionally to use this syntax, via a deprecation period?
I am +1.
IMO, even if the syntax might be unknown, it will remain unknown until projects from the ecosystem are not using it.
To the question: which methods should be impacted?
I think we should be as gentle as possible at first. I am a little concerned about breaking some codes which were working fine before.
On Thu, 12 Sep 2019 at 04:43, Joel Nothman <joel.nothman@gmail.com> wrote:
These there details of specific API changes to be decided:
The question being put, as per the SLEP, is: do we want to utilise Python 3's force-keyword-argument syntax and to change existing APIs which support arguments positionally to use this syntax, via a deprecation period? _______________________________________________ scikit-learn mailing list scikit-learn@python.org https://mail.python.org/mailman/listinfo/scikit-learn
-- Guillaume Lemaitre INRIA Saclay - Parietal team Center for Data Science Paris-Saclay https://glemaitre.github.io/
_______________________________________________ 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
+1 assuming we are careful about continuing to allow some frequently used positional arguments, even in __init__. For instance, n_components = 10 pca = PCA(n_components) is still more readable, I think, than, pca = PCA(n_components=n_components) -- Roman On 15/09/2019 00:21, Thomas J Fan wrote:
+1 from me
On Sat, Sep 14, 2019 at 8:12 AM Joel Nothman <joel.nothman@gmail.com <mailto:joel.nothman@gmail.com>> wrote:
I am +1 for this change.
I agree that users will accommodate the syntax sooner or later.
On Fri., 13 Sep. 2019, 7:54 pm Jeremie du Boisberranger, <jeremie.du-boisberranger@inria.fr <mailto:jeremie.du-boisberranger@inria.fr>> wrote:
I don't know what is the policy about a sklearn 1.0 w.r.t api changes.
If it's meant to be a special release with possible api changes without deprecation cycles, I think this change is a good candidate for 1.0
Otherwise I'm +1 and agree with Guillaume, people will get used to it by using it.
Jérémie
On 12/09/2019 10:06, Guillaume Lemaître wrote:
To the question: do we want to utilise Python 3's force-keyword-argument syntax and to change existing APIs which support arguments positionally to use this syntax, via a deprecation period?
I am +1.
IMO, even if the syntax might be unknown, it will remain unknown until projects from the ecosystem are not using it.
To the question: which methods should be impacted?
I think we should be as gentle as possible at first. I am a little concerned about breaking some codes which were working fine before.
On Thu, 12 Sep 2019 at 04:43, Joel Nothman <joel.nothman@gmail.com <mailto:joel.nothman@gmail.com>> wrote:
These there details of specific API changes to be decided:
The question being put, as per the SLEP, is: do we want to utilise Python 3's force-keyword-argument syntax and to change existing APIs which support arguments positionally to use this syntax, via a deprecation period? _______________________________________________ scikit-learn mailing list scikit-learn@python.org <mailto:scikit-learn@python.org> https://mail.python.org/mailman/listinfo/scikit-learn
-- Guillaume Lemaitre INRIA Saclay - Parietal team Center for Data Science Paris-Saclay https://glemaitre.github.io/
_______________________________________________ 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 <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
Btw, consensus is defined by 2/3 of cast votes by core devs, according to our Governance. https://scikit-learn.org/dev/about.html#authors lists 20 core devs. That is, we could consider this resolved after 14 votes in favour. So far, if I've interpreted correctly: +1 (adrin, nicolas, hanmin, joel, guillaume, jeremie, thomas, vlad, roman) = 9. I've not understood a clear position from Alex. I'm assuming Andreas is in favour given his comments elsewhere, but we've not seen comment here. On Mon, 16 Sep 2019 at 20:06, Roman Yurchak <rth.yurchak@gmail.com> wrote:
+1 assuming we are careful about continuing to allow some frequently used positional arguments, even in __init__.
For instance,
n_components = 10 pca = PCA(n_components)
is still more readable, I think, than,
pca = PCA(n_components=n_components)
-- Roman
On 15/09/2019 00:21, Thomas J Fan wrote:
+1 from me
On Sat, Sep 14, 2019 at 8:12 AM Joel Nothman <joel.nothman@gmail.com <mailto:joel.nothman@gmail.com>> wrote:
I am +1 for this change.
I agree that users will accommodate the syntax sooner or later.
On Fri., 13 Sep. 2019, 7:54 pm Jeremie du Boisberranger, <jeremie.du-boisberranger@inria.fr <mailto:jeremie.du-boisberranger@inria.fr>> wrote:
I don't know what is the policy about a sklearn 1.0 w.r.t api changes.
If it's meant to be a special release with possible api changes without deprecation cycles, I think this change is a good candidate for 1.0
Otherwise I'm +1 and agree with Guillaume, people will get used to it by using it.
Jérémie
On 12/09/2019 10:06, Guillaume Lemaître wrote:
To the question: do we want to utilise Python 3's force-keyword-argument syntax and to change existing APIs which support arguments positionally to use this syntax, via a deprecation period?
I am +1.
IMO, even if the syntax might be unknown, it will remain unknown until projects from the ecosystem are not using it.
To the question: which methods should be impacted?
I think we should be as gentle as possible at first. I am a little concerned about breaking some codes which were working fine before.
On Thu, 12 Sep 2019 at 04:43, Joel Nothman <joel.nothman@gmail.com <mailto:joel.nothman@gmail.com>> wrote:
These there details of specific API changes to be decided:
The question being put, as per the SLEP, is: do we want to utilise Python 3's force-keyword-argument
syntax
and to change existing APIs which support arguments positionally to use this syntax, via a deprecation period? _______________________________________________ scikit-learn mailing list scikit-learn@python.org <mailto:scikit-learn@python.org> https://mail.python.org/mailman/listinfo/scikit-learn
-- Guillaume Lemaitre INRIA Saclay - Parietal team Center for Data Science Paris-Saclay https://glemaitre.github.io/
_______________________________________________ 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 <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
_______________________________________________ scikit-learn mailing list scikit-learn@python.org https://mail.python.org/mailman/listinfo/scikit-learn
+1 for the geenralization of kw arguments. This is obviously relevant for __init__ methods, why good old (X,y) should remain positional. Best, Bertrand
De: "Joel Nothman" <joel.nothman@gmail.com> À: "Scikit-learn mailing list" <scikit-learn@python.org> Envoyé: Lundi 16 Septembre 2019 15:28:57 Objet: Re: [scikit-learn] Vote on SLEP009: keyword only arguments
Btw, consensus is defined by 2/3 of cast votes by core devs, according to our Governance. [ https://scikit-learn.org/dev/about.html#authors | https://scikit-learn.org/dev/about.html#authors ] lists 20 core devs. That is, we could consider this resolved after 14 votes in favour. So far, if I've interpreted correctly:
+1 (adrin, nicolas, hanmin, joel, guillaume, jeremie, thomas, vlad, roman) = 9.
I've not understood a clear position from Alex. I'm assuming Andreas is in favour given his comments elsewhere, but we've not seen comment here.
On Mon, 16 Sep 2019 at 20:06, Roman Yurchak < [ mailto:rth.yurchak@gmail.com | rth.yurchak@gmail.com ] > wrote:
+1 assuming we are careful about continuing to allow some frequently used positional arguments, even in __init__.
For instance,
n_components = 10 pca = PCA(n_components)
is still more readable, I think, than,
pca = PCA(n_components=n_components)
-- Roman
On 15/09/2019 00:21, Thomas J Fan wrote:
+1 from me
On Sat, Sep 14, 2019 at 8:12 AM Joel Nothman < [ mailto:joel.nothman@gmail.com | joel.nothman@gmail.com ] <mailto: [ mailto:joel.nothman@gmail.com | joel.nothman@gmail.com ] >> wrote:
I am +1 for this change.
I agree that users will accommodate the syntax sooner or later.
On Fri., 13 Sep. 2019, 7:54 pm Jeremie du Boisberranger, < [ mailto:jeremie.du-boisberranger@inria.fr | jeremie.du-boisberranger@inria.fr ] <mailto: [ mailto:jeremie.du-boisberranger@inria.fr | jeremie.du-boisberranger@inria.fr ] >> wrote:
I don't know what is the policy about a sklearn 1.0 w.r.t api changes.
If it's meant to be a special release with possible api changes without deprecation cycles, I think this change is a good candidate for 1.0
Otherwise I'm +1 and agree with Guillaume, people will get used to it by using it.
Jérémie
On 12/09/2019 10:06, Guillaume Lemaître wrote:
To the question: do we want to utilise Python 3's force-keyword-argument syntax and to change existing APIs which support arguments positionally to use this syntax, via a deprecation period?
I am +1.
IMO, even if the syntax might be unknown, it will remain unknown until projects from the ecosystem are not using it.
To the question: which methods should be impacted?
I think we should be as gentle as possible at first. I am a little concerned about breaking some codes which were working fine before.
On Thu, 12 Sep 2019 at 04:43, Joel Nothman < [ mailto:joel.nothman@gmail.com | joel.nothman@gmail.com ] <mailto: [ mailto:joel.nothman@gmail.com | joel.nothman@gmail.com ] >> wrote:
These there details of specific API changes to be decided:
The question being put, as per the SLEP, is: do we want to utilise Python 3's force-keyword-argument syntax and to change existing APIs which support arguments positionally to use this syntax, via a deprecation period? _______________________________________________ scikit-learn mailing list [ mailto:scikit-learn@python.org | scikit-learn@python.org ] <mailto: [ mailto:scikit-learn@python.org | scikit-learn@python.org ] > [ https://mail.python.org/mailman/listinfo/scikit-learn | https://mail.python.org/mailman/listinfo/scikit-learn ]
-- Guillaume Lemaitre INRIA Saclay - Parietal team Center for Data Science Paris-Saclay [ https://glemaitre.github.io/ | https://glemaitre.github.io/ ]
_______________________________________________ scikit-learn mailing list [ mailto:scikit-learn@python.org | scikit-learn@python.org ] <mailto: [ mailto:scikit-learn@python.org | scikit-learn@python.org ] > [ https://mail.python.org/mailman/listinfo/scikit-learn | https://mail.python.org/mailman/listinfo/scikit-learn ]
scikit-learn mailing list [ mailto:scikit-learn@python.org | scikit-learn@python.org ] <mailto: [ mailto:scikit-learn@python.org | scikit-learn@python.org ] > [ https://mail.python.org/mailman/listinfo/scikit-learn | https://mail.python.org/mailman/listinfo/scikit-learn ]
_______________________________________________ scikit-learn mailing list [ mailto:scikit-learn@python.org | scikit-learn@python.org ] <mailto: [ mailto:scikit-learn@python.org | scikit-learn@python.org ] > [ https://mail.python.org/mailman/listinfo/scikit-learn | https://mail.python.org/mailman/listinfo/scikit-learn ]
_______________________________________________ scikit-learn mailing list [ mailto:scikit-learn@python.org | scikit-learn@python.org ] [ https://mail.python.org/mailman/listinfo/scikit-learn | https://mail.python.org/mailman/listinfo/scikit-learn ]
_______________________________________________ scikit-learn mailing list [ mailto:scikit-learn@python.org | scikit-learn@python.org ] [ https://mail.python.org/mailman/listinfo/scikit-learn | 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 vote +1 Tom Le lun. 16 sept. 2019 à 06:30, Joel Nothman <joel.nothman@gmail.com> a écrit :
Btw, consensus is defined by 2/3 of cast votes by core devs, according to our Governance. https://scikit-learn.org/dev/about.html#authors lists 20 core devs.
That is, we could consider this resolved after 14 votes in favour.
So far, if I've interpreted correctly:
+1 (adrin, nicolas, hanmin, joel, guillaume, jeremie, thomas, vlad, roman) = 9.
I've not understood a clear position from Alex. I'm assuming Andreas is in favour given his comments elsewhere, but we've not seen comment here.
On Mon, 16 Sep 2019 at 20:06, Roman Yurchak <rth.yurchak@gmail.com> wrote:
+1 assuming we are careful about continuing to allow some frequently used positional arguments, even in __init__.
For instance,
n_components = 10 pca = PCA(n_components)
is still more readable, I think, than,
pca = PCA(n_components=n_components)
-- Roman
On 15/09/2019 00:21, Thomas J Fan wrote:
+1 from me
On Sat, Sep 14, 2019 at 8:12 AM Joel Nothman <joel.nothman@gmail.com <mailto:joel.nothman@gmail.com>> wrote:
I am +1 for this change.
I agree that users will accommodate the syntax sooner or later.
On Fri., 13 Sep. 2019, 7:54 pm Jeremie du Boisberranger, <jeremie.du-boisberranger@inria.fr <mailto:jeremie.du-boisberranger@inria.fr>> wrote:
I don't know what is the policy about a sklearn 1.0 w.r.t api changes.
If it's meant to be a special release with possible api changes without deprecation cycles, I think this change is a good candidate for 1.0
Otherwise I'm +1 and agree with Guillaume, people will get used to it by using it.
Jérémie
On 12/09/2019 10:06, Guillaume Lemaître wrote:
To the question: do we want to utilise Python 3's force-keyword-argument syntax and to change existing APIs which support arguments positionally to use this syntax, via a deprecation period?
I am +1.
IMO, even if the syntax might be unknown, it will remain unknown until projects from the ecosystem are not using it.
To the question: which methods should be impacted?
I think we should be as gentle as possible at first. I am a little concerned about breaking some codes which were working fine before.
On Thu, 12 Sep 2019 at 04:43, Joel Nothman <joel.nothman@gmail.com <mailto:joel.nothman@gmail.com>>
wrote:
These there details of specific API changes to be decided:
The question being put, as per the SLEP, is: do we want to utilise Python 3's force-keyword-argument
syntax
and to change existing APIs which support arguments positionally to use this syntax, via a deprecation period? _______________________________________________ scikit-learn mailing list scikit-learn@python.org <mailto:scikit-learn@python.org> https://mail.python.org/mailman/listinfo/scikit-learn
-- Guillaume Lemaitre INRIA Saclay - Parietal team Center for Data Science Paris-Saclay https://glemaitre.github.io/
_______________________________________________ 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 <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
_______________________________________________ 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 Mon, Sep 16, 2019 at 11:28:57PM +1000, Joel Nothman wrote:
That is, we could consider this resolved after 14 votes in favour.
So far, if I've interpreted correctly:
+1 (adrin, nicolas, hanmin, joel, guillaume, jeremie, thomas, vlad, roman) = 9.
I've not understood a clear position from Alex. I'm assuming Andreas is in favour given his comments elsewhere, but we've not seen comment here.
I was planning to vote -0 mostly to avoid the vote to seem like bandwagon (and because I am not fully sold on the idea), but I actually want this to move forward, and it seems that my vote is needed. Hence, I vote +1. Hopefully Andreas and Alex make their position clear and we can adopt the SLEP. Thank you to you all. Gaël
On Mon, 16 Sep 2019 at 20:06, Roman Yurchak <rth.yurchak@gmail.com> wrote:
+1 assuming we are careful about continuing to allow some frequently used positional arguments, even in __init__.
For instance,
n_components = 10 pca = PCA(n_components)
is still more readable, I think, than,
pca = PCA(n_components=n_components)
-- Gael Varoquaux Research Director, INRIA http://gael-varoquaux.info http://twitter.com/GaelVaroquaux
Hi all, Just a few comments about this SLEP from a contributor and user of the library :). I think it is important for users to be able to quickly and easily know/learn which arguments should be keyword arguments when they use scikit-learn. As a user, I do not want to have to double check each time I use a function the arguments that should be keyword arguments. Hence the following sentence of the SLEP "the decision for these methods should be the same throughout the library in order to keep a consistent interface to the user" is very important to me. Also how is this going to be rendered by sphinx in the doc? (before numpydoc supports section for parameters) Thanks, Albert On Mon, Sep 16, 2019 at 9:33 PM Gael Varoquaux < gael.varoquaux@normalesup.org> wrote:
On Mon, Sep 16, 2019 at 11:28:57PM +1000, Joel Nothman wrote:
That is, we could consider this resolved after 14 votes in favour.
So far, if I've interpreted correctly:
+1 (adrin, nicolas, hanmin, joel, guillaume, jeremie, thomas, vlad, roman) = 9.
I've not understood a clear position from Alex. I'm assuming Andreas is in favour given his comments elsewhere, but we've not seen comment here.
I was planning to vote -0 mostly to avoid the vote to seem like bandwagon (and because I am not fully sold on the idea), but I actually want this to move forward, and it seems that my vote is needed.
Hence, I vote +1.
Hopefully Andreas and Alex make their position clear and we can adopt the SLEP.
Thank you to you all.
Gaël
On Mon, 16 Sep 2019 at 20:06, Roman Yurchak <rth.yurchak@gmail.com> wrote:
+1 assuming we are careful about continuing to allow some frequently used positional arguments, even in __init__.
For instance,
n_components = 10 pca = PCA(n_components)
is still more readable, I think, than,
pca = PCA(n_components=n_components)
-- Gael Varoquaux Research Director, INRIA http://gael-varoquaux.info http://twitter.com/GaelVaroquaux _______________________________________________ scikit-learn mailing list scikit-learn@python.org https://mail.python.org/mailman/listinfo/scikit-learn
Yes I am +1 for positional arguments for the __init__ of the estimators. Alex On Mon, Sep 16, 2019 at 10:25 PM Albert Thomas <albertthomas88@gmail.com> wrote:
Hi all,
Just a few comments about this SLEP from a contributor and user of the library :).
I think it is important for users to be able to quickly and easily know/learn which arguments should be keyword arguments when they use scikit-learn. As a user, I do not want to have to double check each time I use a function the arguments that should be keyword arguments. Hence the following sentence of the SLEP "the decision for these methods should be the same throughout the library in order to keep a consistent interface to the user" is very important to me. Also how is this going to be rendered by sphinx in the doc? (before numpydoc supports section for parameters)
Thanks, Albert
On Mon, Sep 16, 2019 at 9:33 PM Gael Varoquaux < gael.varoquaux@normalesup.org> wrote:
On Mon, Sep 16, 2019 at 11:28:57PM +1000, Joel Nothman wrote:
That is, we could consider this resolved after 14 votes in favour.
So far, if I've interpreted correctly:
+1 (adrin, nicolas, hanmin, joel, guillaume, jeremie, thomas, vlad, roman) = 9.
I've not understood a clear position from Alex. I'm assuming Andreas is in favour given his comments elsewhere, but we've not seen comment here.
I was planning to vote -0 mostly to avoid the vote to seem like bandwagon (and because I am not fully sold on the idea), but I actually want this to move forward, and it seems that my vote is needed.
Hence, I vote +1.
Hopefully Andreas and Alex make their position clear and we can adopt the SLEP.
Thank you to you all.
Gaël
On Mon, 16 Sep 2019 at 20:06, Roman Yurchak <rth.yurchak@gmail.com> wrote:
+1 assuming we are careful about continuing to allow some frequently used positional arguments, even in __init__.
For instance,
n_components = 10 pca = PCA(n_components)
is still more readable, I think, than,
pca = PCA(n_components=n_components)
-- Gael Varoquaux Research Director, INRIA http://gael-varoquaux.info http://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
I think you mean keyword-only, Alex On Tue., 17 Sep. 2019, 4:11 pm Alexandre Gramfort, < alexandre.gramfort@inria.fr> wrote:
Yes I am +1 for positional arguments for the __init__ of the estimators.
Alex
Albert: my position when reviewing changes in accordance with this SLEP would be to (a) perhaps get usage evidence as discussed in the SLEP pull request review; and (b) apply a rule of thumb like "are the semantics reasonably clear when the argument is passed positionally?" I think they are clear for PCA's components, for Pipeline's steps, and for GridSearchCV's estimator and parameter grid. Other parameters of those estimators seem more suitable for keyword-only. Trickier is whether n_components in TSNE should follow PCA in being positional... It's not as commonly set by users.
If we were to assume Andy's vote in the positive, him having been a major proponent of this change, we would say this was accepted by a unanimous vote of a majority of core developers. Having tentatively accepted is good enough basis for us to start implementation. And ideally getting statistics to guide that. We should tackle this module by module, perhaps working through estimators before other public API. As such, I have opened https://github.com/scikit-learn/scikit-learn/issues/15005 to start tracking this work. Thanks everyone, and Andy, we await your vote! J
Sorry, I was on vacation ;) +1 from me. On 9/17/19 7:28 PM, Joel Nothman wrote:
If we were to assume Andy's vote in the positive, him having been a major proponent of this change, we would say this was accepted by a unanimous vote of a majority of core developers.
Having tentatively accepted is good enough basis for us to start implementation. And ideally getting statistics to guide that.
We should tackle this module by module, perhaps working through estimators before other public API.
As such, I have opened https://github.com/scikit-learn/scikit-learn/issues/15005 to start tracking this work.
Thanks everyone, and Andy, we await your vote!
J
_______________________________________________ scikit-learn mailing list scikit-learn@python.org https://mail.python.org/mailman/listinfo/scikit-learn
On 9/17/19 3:42 AM, Joel Nothman wrote:
I think you mean keyword-only, Alex
On Tue., 17 Sep. 2019, 4:11 pm Alexandre Gramfort, <alexandre.gramfort@inria.fr <mailto:alexandre.gramfort@inria.fr>> wrote:
Yes I am +1 for positional arguments for the __init__ of the estimators.
Alex
Albert: my position when reviewing changes in accordance with this SLEP would be to (a) perhaps get usage evidence as discussed in the SLEP pull request review; and (b) apply a rule of thumb like "are the semantics reasonably clear when the argument is passed positionally?" I think they are clear for PCA's components, for Pipeline's steps, and for GridSearchCV's estimator and parameter grid. Other parameters of those estimators seem more suitable for keyword-only. I think you're not fully addressing Albert's concern, which I think is quite important and hasn't been brought up before.
I think Albert is saying that it should be easy for a new user to build a mental model of when a positional argument is allowed. If we can't specify a simple rule, then it's very hard for a new (or really any) user to have clear expectations. And I think sklearn is all about setting clear expectations.
Also how is this going to be rendered by sphinx in the doc?
There will be a star in the signature between positional and kw only args i.e. PCA(n_components=2, *, copy=True, ...) So you could always look at the docs to figure it out. That's clearly not very convenient.
participants (13)
-
Albert Thomas -
Alexandre Gramfort -
Andreas Mueller -
Bertrand Thirion -
Gael Varoquaux -
Guillaume Lemaître -
Hanmin Qin -
Jeremie du Boisberranger -
Joel Nothman -
Roman Yurchak -
Thomas J Fan -
Tom DLT -
Vlad Niculae