4 ms·
mypy has gotten a lot better and I wouldn't discount it because of one bad use case. I went through the exercise of applying type hints to a large code base and
by rzimmerman 8y ago
mypy has gotten a lot better and I wouldn't discount it because of one bad use case. I went through the exercise of applying type hints to a large code base and uncovered several latent bugs.
That being said, mypy supports type hints in Python 2 code, so that really just adds to your argument.
- carapace 8y agoI want to be clear, I like MyPy and the whole type-hints in Python thing, but it's not good enough to make Python 3 compelling to me. I was doing something that was totally "plain vanilla" in the Python semantics but outside the assumptions of the type checker.[1] It made me realize that "strictly-typed" Python is a subset of actual Python. It's not that "strictly-typed" Python isn't a useful language, it's that if I really wanted strict typing I'd use e.g. Haskell or Elm, where you get so much more bang for the buck it's not even funny. "Duck-typing" is a trade-off. In that sense, strict typing actually kinda weakens Python 3, because you're losing [the full advantage of] duck-typing but not gaining [the full advantage of] strictly-enforced type-checking and type inference. And, as you point out, the lesser advantages of type hints are available to Python 2... [1] I was experimenting with a purely functional web template sytem and I was using the keyword args dict as a sort of "grab bag" of values that functions could pass around, picking out the values they were "interested in" by named keyword parameters. It worked fine but there was no way to tell MyPy what the type of the dict should be.