On Tue, 2013-02-26 at 15:21 +0100, Lars Buitinck wrote: > > I'm all in favor of that, but we have so many different estimators > that special-casing Pipeline for all (kinds of) them is infeasible. So > we should come up with an elegant and general set of rules, which we > can then implement by e.g. a custom __getattr__ on Pipeline.
Yes, I agree. Special-casing properties for all possible use cases of the Pipeline is infeasible. Implementing a custom __getattr__ seems a viable approach to me. > There are several questions to be answered: > * which attributes should be exported? (all? all those with final _? > what about methods?) Hmm... I would say those that are part of the API of the estimator that is the final step of the Pipeline. What is the current status on APIs of different estimators? That being said, the estimator's methods, e.g. predict(), must not replace the Pipeline's methods, since things would stop working properly then. > * if two estimators in the pipeline implement an attribute, which one > does the pipeline's attribute refer to? possibly classes_, with > L1-feature selection by SVMs; we could select the last member of the > pipeline in this case, but will that always work? Yes, I would say that only properties of the last step of the Pipeline should be considered for "exportation". If you need a property of some intermediate step of the Pipeline, you should be aware of the fact that you are using a Pipeline and extract that property using existing mechanisms. ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ Scikit-learn-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/scikit-learn-general
