Generic specialization?
Chưa có ai nhận issue này.
- Ngôn ngữ chính
- Python
- Star
- 1.8k
- Fork
- 302
- Merge trung bình
- 23 giờ
- Pull request đã merge (30 ngày)
- 8
Mô tả
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.
Hướng dẫn đóng góp
Chưa lập chỉ mục được hướng dẫn đóng góp cho kho mã nguồn này
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Hướng nghiên cứu
Bắt đầu với các ví dụ Fitted[T] được đề xuất trong issue này và đọc issue được tham chiếu #802. So sánh việc phân lớp con, chuyên biệt hóa, các hạn chế đối với phương thức và hành vi lũy đẳng được yêu cầu với các phương án thay thế đã mô tả; công việc được xem là hoàn tất khi có một thiết kế hệ thống kiểu được thống nhất và các chi tiết đặc tả tương ứng.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Đánh giá
- Công nghệ
- python
- Lĩnh vực
- developer-experience
- Loại issue
- Tính năng
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức độ hoạt động
- Đình trệ
- Độ rõ ràng
- Khá rõ ràng
- Mức phù hợp với người mới
- 25/100