7 ms·

I disagree. I've had a serious attempt at array typing using variadic generics and I'm not impressed. Python's type system has numerous issues... and now they j

I disagree. I've had a serious attempt at array typing using variadic generics and I'm not impressed. Python's type system has numerous issues... and now they just apply to any "ArrayWithNDimensions" type as well as any "ArrayWith2Dimensions" type. Variadic protocols don't exist; many operations like stacking are inexpressible; the synatx is awful and verbose; etc. etc. I've written more about this here as part of my TorchTyping project: [0] [0] https://github.com/patrick-kidger/torchtyping/issues/37#issuecomment-1153294196 https://github.com/patrick-kidger/torchtyping/issues/37#issu...

davidatbu 4y ago
Thanks for linking this! And I (though not OP) totally agree with your points! I hope that these things could be solved with future iterations. For example: Variadic protocols don't exist. Hopefully they are added sometime. the syntax is awful and verbose. Hopefully we can settle on allowing `1` instead of `Literal[1]` as a type (and other similar improvements). many operations like stacking are inexpressible. These could be expressed if things like "multiplying"/"adding" literal numeric types would be supported. The variadic generics PEP was partly motivated by the ML use-case (and took input from maintainers of numpy ..etc), so I hope future iterations will also improve the usage in the ML space.
- Mehdi2277 4y ago
  Partly motivated? The primary focus was ML space. The creators of PEP 646 work at Facebook with goal of supporting pytorch tensor dimension tracking. That was main motivation and many of the features/design of that pep were based on what's needed to type hint tensor dimensions. Pep was originally even longer and there's planned follow up peps for other tensor related type features like literal arithmetic to allow type hinting function like np.concatenate. I expect 2/3 more peps in that area in the next year or two.
  - davidatbu 4y ago
    Absolutely right about ML being the main motivation. The PEP says: The main case this PEP targets - concerns typing in numerical libraries. However, despite the authors of the PEP working at facebook, the Pytorch team, at facebook, wasn't interested at all in the PEP. This is also from the PEP: For the sake of transparency - we also reached out to folks from a third popular numerical computing library, PyTorch, but did not receive a statement of endorsement from them. Our understanding is that although they are interested in some of the same issues - e.g. static shape inference - they are currently focusing on enabling this through a DSL rather than the Python type system

davidatbu 4y ago

Thanks for linking this! And I (though not OP) totally agree with your points! I hope that these things could be solved with future iterations. For example: Variadic protocols don't exist. Hopefully they are added sometime. the syntax is awful and verbose. Hopefully we can settle on allowing `1` instead of `Literal[1]` as a type (and other similar improvements). many operations like stacking are inexpressible. These could be expressed if things like "multiplying"/"adding" literal numeric types would be supported. The variadic generics PEP was partly motivated by the ML use-case (and took input from maintainers of numpy ..etc), so I hope future iterations will also improve the usage in the ML space.

Mehdi2277 4y ago
Partly motivated? The primary focus was ML space. The creators of PEP 646 work at Facebook with goal of supporting pytorch tensor dimension tracking. That was main motivation and many of the features/design of that pep were based on what's needed to type hint tensor dimensions. Pep was originally even longer and there's planned follow up peps for other tensor related type features like literal arithmetic to allow type hinting function like np.concatenate. I expect 2/3 more peps in that area in the next year or two.
- davidatbu 4y ago
  Absolutely right about ML being the main motivation. The PEP says: The main case this PEP targets - concerns typing in numerical libraries. However, despite the authors of the PEP working at facebook, the Pytorch team, at facebook, wasn't interested at all in the PEP. This is also from the PEP: For the sake of transparency - we also reached out to folks from a third popular numerical computing library, PyTorch, but did not receive a statement of endorsement from them. Our understanding is that although they are interested in some of the same issues - e.g. static shape inference - they are currently focusing on enabling this through a DSL rather than the Python type system