Repository navigation
Populate various protocols #23
Description
Populate the protocols introduced by #20
This issue is required for the creation of TODOs. 😄
Populate the protocols introduced by #20
This issue is required for the creation of TODOs. 😄
Activity
krokosik commentedon Aug 18, 2025
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
NeilGirdhar commentedon Aug 18, 2025
@krokosik Oh I'm not in charge! Best to contact one the maintainers :) I know @jorenham had some ideas about not generating stubs.
jorenham commentedon Aug 18, 2025
We have tried working together on this before, but that didn't work out. See data-apis/array-api#863 (reply in thread) and #14 for context.
krokosik commentedon Aug 18, 2025
Oh my, I see. Understandable
krokosik commentedon Aug 18, 2025
What is the current stance on automatic stub generation?
jorenham commentedon Aug 18, 2025
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).