Generic specialization?
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 1.8k
- Forks
- 302
- Avg merge
- 23h
- Merged PRs (30d)
- 8
Description
I was wondering if it was possible to redefine what a particular generic means for a particular type (and maybe its subclasses, superclasses depending on covariance/contravariance?).
My use case comes from the scikit-learn API. In this API each "estimator" class has two set of attributes: those that are passed to __init__ and those that are computed after calling .fit() to fit the model. The convention is that the latest ones end with an underscore.
Also the fit method returns self.
In addition to that, there are methods, like predict, that are only allowed after fitting.
Currently the code that uses this library is like this:
my_estimator = MyEstimator(param1, param2)
my_estimator.fit(X_train, y_train)
# Now is safe to access fit attributes and call predict, score, etc
print(my_estimator.fitted_attr1_)
print(my_estimator.predict(X_test))
The idea was to allow Mypy (or other analyzer) to check these invariants using additional types. Instead of typing fit as:
def fit(self, X: ..., y: ...) -> Self
we could type it as
def fit(self, X: ..., y: ...) -> Fitted[Self]
We then would need a way to:
- Define that
Fitted[T]is a subclass ofT. Similar to #802. - Define the particular fit attributes of
Fitted[T]for a particularT. - Define that some methods. such as
predictcan only be used with aFitted[T]object, and not with aTobject. - Define that
Fitted[Fitted[T]] == Fitted[T].
Then, only a small change would be needed in the previous code to allow type checkers to detect whether the invariants have been broken:
my_estimator = MyEstimator(param1, param2)
my_estimator = my_estimator.fit(X_train, y_train) # Line changed
# Now is safe to access fit attributes and call predict, score, etc
print(my_estimator.fitted_attr1_)
print(my_estimator.predict(X_test))
This is only a possibility. Alternatives include:
- Defining a subclass just for the type-checker in a
if TYPE_CHECKING:environment. This works for the basic usage illustrated here, but not in other generic cases, e.g.: typing a function that accepts a fitted estimator of any type. It also creates a parallel class structure, which should also be subclassed by subclasses, etc. - Just typing the whole class and don't let type-checkers to verify these invariants.
However I think that adding this flexibility to the type system could maybe help in other cases.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the proposed Fitted[T] examples in this issue and read the referenced issue #802. Compare the requested subclassing, specialization, method restrictions, and idempotence behavior with the alternatives described; done would require an agreed type-system design and corresponding specification details.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- developer-experience
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100