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.varoqu...@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@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@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
