4 ms·

To me it is not smart to use that. You make the code complicated that it will be unreadable. Normally the code should speak for itself. This is the key strong p

To me it is not smart to use that. You make the code complicated that it will be unreadable. Normally the code should speak for itself. This is the key strong point of python. Also, then you need annotation and tests to validate your annotations!

stefanka 4y ago
Fair. I personally prefer to see the expectation to the arguments (especially in a scientific / data science context) over looking into asserts in the function body, which distract from the algorithm in there. Originally, I planned to automatically include the lambdas in the docstring/sphinx but unfortunately, Python does not keep the source code of the lambda (only the whole line and parsing would be overkill). I did not understand your second remark, could you clarify please?
hansvm 4y ago
The example of dimension checking is handy, especially in fields where the same name for an idea has multiple incompatible instantiations or when there's an arbitrary choice that some subfield uses and some other makes differently (left vs right multiplication as a convention, left vs right handed coordinates as a convention, tensor ordering, ...). Sometimes better names help, but often they're just a lot of visual noise for the tiny bit of additional information they portray. Usually I use strings as type annotations for that purpose (compactly describing common constraints like the shape's shape, which dimensions are in common, ...) to communicate to other developers, but I could see a use case for some actual tooling, especially to the extent that somebody could build on top of the library and tailor it to some problem domain. def foobar(a: '(i>1, j)', b: '(j, k)') -> '(k,)':
- stefanka 4y ago
  Seems you refer to a domain specific language in the annotations. This is exactly what https://github.com/AndreaCensi/contracts https://github.com/AndreaCensi/contracts does (it's an amazing project but has a very large code base). However, I wanted to achieve something similar in pure python and as compact as possible – so there are compromises (like no real symbolic calculus)

stefanka 4y ago

Fair. I personally prefer to see the expectation to the arguments (especially in a scientific / data science context) over looking into asserts in the function body, which distract from the algorithm in there. Originally, I planned to automatically include the lambdas in the docstring/sphinx but unfortunately, Python does not keep the source code of the lambda (only the whole line and parsing would be overkill). I did not understand your second remark, could you clarify please?

hansvm 4y ago

The example of dimension checking is handy, especially in fields where the same name for an idea has multiple incompatible instantiations or when there's an arbitrary choice that some subfield uses and some other makes differently (left vs right multiplication as a convention, left vs right handed coordinates as a convention, tensor ordering, ...). Sometimes better names help, but often they're just a lot of visual noise for the tiny bit of additional information they portray. Usually I use strings as type annotations for that purpose (compactly describing common constraints like the shape's shape, which dimensions are in common, ...) to communicate to other developers, but I could see a use case for some actual tooling, especially to the extent that somebody could build on top of the library and tailor it to some problem domain. def foobar(a: '(i>1, j)', b: '(j, k)') -> '(k,)':

stefanka 4y ago
Seems you refer to a domain specific language in the annotations. This is exactly what https://github.com/AndreaCensi/contracts https://github.com/AndreaCensi/contracts does (it's an amazing project but has a very large code base). However, I wanted to achieve something similar in pure python and as compact as possible – so there are compromises (like no real symbolic calculus)