Experimental Framework in scikit-learn #34149
Replies: 1 comment
|
I think having an From a user's perspective, it makes experimental features much easier to discover and evaluate without introducing additional dependencies or compatibility concerns. Users can try new functionality while still working within the familiar scikit-learn ecosystem. From a development perspective, it also allows experimental features to be tested against existing estimators, utilities, pipelines, and documentation before becoming part of the stable API. This can help gather real-world feedback earlier and make API changes with greater confidence. A separate package certainly provides more freedom to iterate, but it may also create additional maintenance work around version compatibility, testing, and user adoption. Overall, I think an experimental namespace provides a good balance between encouraging innovation and maintaining the consistency and reliability that users expect from a mature library. |
Uh oh!
There was an error while loading. Please reload this page.
Hello everyone,
I'm a GSoC student working with Django. I'll be mentored by Andrew Miller on this and we are looking at creating a new experimental framework in Django core to test new features safely.
Because scikit-learn has utilized sklearn.experimental to test features while they are still being worked on, you have direct experience with this. So, in your experience, what are the benefits of having a feature in sklearn.experimental rather than leaving it as a completely separate third-party package?
Can you share an example of a feature that would have been very difficult to manage as a standalone package, but you were able to successfully build or improve it because it lived in your experimental namespace? I'm particularly interested in cases where being inside the library allowed for better integration or faster iteration.
Thanks for any insights!
All reactions