[scikit-learn] make all new parameters keyword-only?

[Brown J.B.]

As an end-user, I would strongly support the idea of future enforcement of
keyword arguments for new parameters.
In my group, we hold a standard that we develop APIs where _all_ arguments
must be given by keyword (slightly pedantic style, but has shown to have
benefits).
Initialization/call-time state checks are done by a class' internal methods.

As Andy said, one could consider leaving prototypical X,y as positional,
but one benefit my group has seen with full keyword parameterization is the
ability to write code for small investigations where we are more concerned
with effects from parameters rather than the data (e.g., a fixed problem to
model, and one wants to first see on the code line what the estimators and
their parameterizations were).
If one could shift the sklearn X,y to the back of a function call, it would
enable all participants in a face-to-face code review session to quickly
see the emphasis/context of the discussion and move to the conclusion
faster.

To satisfy keyword X,y as well, I would presume that the BaseEstimator
would need to have a sanity check for error-raising default X,y values --
though does it not have many checks on X,y already?

Not sure if everyone else agrees about keyword X and y, but just a thought
for consideration.

Kind regards,
J.B.

2018年11月15日(木) 18:34 Gael Varoquaux <gael.varoquaux at normalesup.org>:

> I am really in favor of the general idea: it is much better to use named
> arguments for everybody (for readability, and to be less depend on
> parameter ordering).
>
> However, I would maintain that we need to move slowly with backward
> compatibility: changing in a backward-incompatible way a library brings
> much more loss than benefit to our users.
>
> So +1 for enforcing the change on all new arguments, but -1 for changing
> orders in the existing arguments any time soon.
>
> I agree that it would be good to push this change in existing models. We
> should probably announce it strongly well in advance, make sure that all
> our examples are changed (people copy-paste), wait a lot, and find a
> moment to squeeze this in.
>
> Gaël
>
> On Thu, Nov 15, 2018 at 06:12:35PM +1100, Joel Nothman wrote:
> > We could just announce that we will be making this a syntactic
> constraint from
> > version X and make the change wholesale then. It would be less formal
> backwards
> > compatibility than we usually hold by, but we already are loose with
> parameter
> > ordering when adding new ones.
>
> > It would be great if after this change we could then reorder parameters
> to make
> > some sense!
>
> > _______________________________________________
> > scikit-learn mailing list
> > scikit-learn at python.org
> > https://mail.python.org/mailman/listinfo/scikit-learn
>
>
> --
>     Gael Varoquaux
>     Senior Researcher, INRIA Parietal
>     NeuroSpin/CEA Saclay , Bat 145, 91191 Gif-sur-Yvette France
>     Phone:  ++ 33-1-69-08-79-68
>     http://gael-varoquaux.info            http://twitter.com/GaelVaroquaux
> _______________________________________________
> scikit-learn mailing list
> scikit-learn at python.org
> https://mail.python.org/mailman/listinfo/scikit-learn
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-learn/attachments/20181116/e84181c2/attachment.html>