Consider not running mypy?

[ricardoV94]

PyTensor is not really geared to be compatible with mypy, and we waste a bunch of dev/ci time trying to make it happy.
I would like to have type hints without summoning the mypy beast

If someone wants to spend the time to make pytensor mypy-friendly we can make it a requirement again.

[maresb]

Sad but understandable. Is there any good way we could still keep it around in the background, but more out of your way?

[maresb]

Can you treat it like codecov where it flags a potential issue but then you may just ignore it? I guess the tricky part is how to get a "mypy diff" without some horrible hack?

[ricardoV94]

If you ignore it there's no point in having it run, it will just break more and more overtime, since type hints failures in some places lead to failures in others. Whereas coverage is more modular

[maresb]

It makes me sad to see the typing effort abandoned, but I'm not in a position to step up myself.

I support you doing whatever you need to do to keep going!

[jessegrabowski]

It makes me sad to see the typing effort abandoned, but I'm not in a position to step up myself.

Ironically, mypy is standing in the way of the typing effort! We are constantly punished for adding type hints to functions, because mypy doesn't agree with them, or it decides that the design of pytensor breaks some programming rule. The most common instance is that the class inheritance structure between Variance and TensorVariable violates the Liskov Substitution Principle, which mypy complains about ad nauseum.

I vote for keeping the script around, but removing the CI job that runs it. We should also pin an issue to do a deep refactor of pytensor to bring it in line with "modern design ideas", and tag it with psycho requested

Such a pinned issue could also look into alternative typing frameworks, like e.g. beartyping (fits the psycho theme)

[Armavica]

Would there perhaps be a way to configure mypy to only lint the most basic typing violations, and ignore the difficult problems?