You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is an interesting community approach at https://github.com/34j/types-array-api
It has an autogen for array type stubs, which would be nice to implement, however, the generated codes uses Python 3.12 syntax for generic types, making it unusable in older Python versions.
There are also some issues, where np.ndarray is considered incompatible with the TArray type when casting: 34j/types-array-api#61.
Perhaps it would be beneficial to merge these two projects? @NeilGirdhar@34j
What is the current stance on automatic stub generation?
My stance is that protocols with many methods are not a good idea. Because for once thing, they're detrimental for type-checker performance when used in overloads. Another is that it's highly unlikely that the downstream array api library annotations will be compatible with them, and are therefore practically useless for them.
That being said, I'm sure that there are ways to apply code generation is a way that's more, erm, constructive. For example, it can be useful for exhaustive type-test generation, of which there are many examples in numtype (a library with experimental new typing stubs for numpy).
Populate the protocols introduced by #20
This issue is required for the creation of TODOs. 馃槃