3 ms·

That's a good point, for example in Eigen you can do Eigen::Matrix<float, 10, 5> I just really want it in Python because that's where I do most of my matrix m

by lacker 11mo ago

That's a good point, for example in Eigen you can do Eigen::Matrix<float, 10, 5> I just really want it in Python because that's where I do most of my matrix manipulation nowadays. I guess you also would really like it to handle non-constants. It would be nice if these complicated library functions like torch.nn.MultiheadAttention(embed_dim, num_heads, dropout=0.0, bias=True, add_bias_kv=False, add_zero_attn=False, kdim=None, vdim=None, batch_first=False, device=None, dtype=None) would actually typecheck that kdim and vdim are correct, and ensure that I correctly pass a K x V matrix and not a V x K one.

zozbot234 11mo ago
Python is a dynamic language where everything happens at run time, including checks of variable types. So you can already do this.
- nephanth 11mo ago
  Python has static typechecking which, while not perfect, works pretty well as long as you're not actually trying to circumvent it (or manipulating things "too dynamically")
  - eru 11mo ago
    I think Python actually has multiple, different static typechecking systems, depending on which checker you use. Python itself only gives you type annotations, but doesn't specify what they are supposed to mean. (I think. Please correct me if I am wrong.)
    - nephanth 11mo ago
      You are slightly wrong. Python does allow you to put anything in annotations. ( pep 3107 that defines type annotations says that explicitly [1]). But it also defines a type checking annotations, which is a specific convention for using pep 3107 annotations. Type annotations were introduced in PEP 484 and updated in a lot of subsequent peps. The python typing system is fully specified in [3]. It does have several implementations, although the reference implementation is mypy [1]: https://peps.python.org/pep-3107/#rejected-proposals https://peps.python.org/pep-3107/#rejected-proposals [2]: https://peps.python.org/pep-0484/ https://peps.python.org/pep-0484/ [3]: https://typing.python.org/en/latest/spec/index.html https://typing.python.org/en/latest/spec/index.html
- bluGill 11mo ago
  The problem with runtime is when you make a mistake it can be a long time before you find out. Compile time means a large class of problems is prevented without perfect test coverage. On a small project it isn't a big deal but when you have hundgeds of developers over decades you will miss something

by lacker 11mo ago

zozbot234 11mo ago

Python is a dynamic language where everything happens at run time, including checks of variable types. So you can already do this.

nephanth 11mo ago
Python has static typechecking which, while not perfect, works pretty well as long as you're not actually trying to circumvent it (or manipulating things "too dynamically")
- eru 11mo ago
  I think Python actually has multiple, different static typechecking systems, depending on which checker you use. Python itself only gives you type annotations, but doesn't specify what they are supposed to mean. (I think. Please correct me if I am wrong.)
  - nephanth 11mo ago
    You are slightly wrong. Python does allow you to put anything in annotations. ( pep 3107 that defines type annotations says that explicitly [1]). But it also defines a type checking annotations, which is a specific convention for using pep 3107 annotations. Type annotations were introduced in PEP 484 and updated in a lot of subsequent peps. The python typing system is fully specified in [3]. It does have several implementations, although the reference implementation is mypy [1]: https://peps.python.org/pep-3107/#rejected-proposals https://peps.python.org/pep-3107/#rejected-proposals [2]: https://peps.python.org/pep-0484/ https://peps.python.org/pep-0484/ [3]: https://typing.python.org/en/latest/spec/index.html https://typing.python.org/en/latest/spec/index.html
bluGill 11mo ago
The problem with runtime is when you make a mistake it can be a long time before you find out. Compile time means a large class of problems is prevented without perfect test coverage. On a small project it isn't a big deal but when you have hundgeds of developers over decades you will miss something