Support for alternative generic inference algorithms
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 believe there is a use case for generic inference that doesn't get as wide as possible.
Look at this example of an assertion function, you would never want to do an assertion between two different types, but there is currently no way to type this:
from typing import TypeVar
T = TypeVar("T")
def assert_something(expected: T, actual: T) -> None:
...
assert_something(1, "") # no error, SUS alert!, T is inferred as `object`
Here are some behaviors from other languages
TypeScript
In Typescript generic inference is narrowed to type level types(not down to instance level types) and is never widened:
function assertSomething<T>(expected: T, actual: T): void { ... }
assertSomething(1, "") // Argument of type 'string' is not assignable to parameter of type 'number'.
Kotlin
Kotlin by default acts the same as Python, but there are annotations for changing the behavior of inference.
NoInfer will exclude that usage from inferring the type.
fun <T> assertSomething(expected: T, actual: @NoInfer T) { }
assertSomething(1, "") // Type mismatch: inferred type is String but Int was expected
Exact will require the type of the parameter is equal at a type level (Number != Int)
fun <T> foo(x: @Exact T) { }
foo<Number>(1) // Type mismatch. Required: Number, Found: Int
OnlyInputTypes will require a type annotation if there is any difference in types between the usages of the generic:
fun <@OnlyInputTypes T> doSomething(a: T, b: T) { }
val a = doSomething("a", "b")
val b = doSomething("a", 1) // Type inference failed. The value of the type parameter T should be mentioned in input types (argument types, receiver type or expected type). Try to specify it explicitly.
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 bằng cách so sánh ví dụ Python với các hành vi suy luận của TypeScript và Kotlin được mô tả trong issue. Xác định những thuật toán suy luận thay thế hoặc chú thích nào cần được hỗ trợ, cũng như cách các kiểu đối số hỗn hợp, các kiểu chính xác và suy luận bị loại trừ được kỳ vọng sẽ hoạt động; việc hoàn thành sẽ yêu cầu một thiết kế được thống nhất và đặc tả kiểu 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
- devtools
- 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