Type annotations?
ariebovenberg opened this issue Ā· 3 comments
Hi there, it seems like the use of type annotations is becoming ever more popular in the community. Is there any reason Pyphen doesn't have them? I'd be happy to submit a PR š
Hi there, it seems like the use of type annotations is becoming ever more popular in the community. Is there any reason Pyphen doesn't have them? I'd be happy to submit a PR š
Hi, and thanks for the kind proposal!
Weāre not fond of type annotations for many reasons that would be too long to discuss here š, thatās why we donāt have them in Pyphen (and in other projects maintained by CourtBouillon). But, well, maybe one day, at least for "small" libraries like Pyphen. Thatās a topic for discussion, because theyāre becoming popular as you notice, thatās why we often take a lot of time to answer this kind of issues! But itās not the moment (yet?) for us.
Iām closing this issue, because thereās nothing to yet!
Thanks for the well-considered reply š . Interesting to hear that this is a conscious choice. I can imagine reasons for this, but I'd of course be interested in your considerations š . Publishing this rationale may prevent this type of question from occurring in the future. Feel free to close the issue as the question has been answered.
I can imagine reasons for this, but I'd of course be interested in your considerations š . Publishing this rationale may prevent this type of question from occurring in the future.
Why not!
First of all, Iām not trying to convince anyone that type annotations are "bad", and I donāt want to be convinced that they are "good". I find them somehow useful, but I also find them quite annoying.
Thatās only my personal point of view.
Iāve been working for some time on a quite big project with 100% type annotations, and Iāve found them really interesting and intellectually challenging. Thatās a great exercice to really think about the type of your parameters, it forces to take care of corner cases and to be sure about what you can and canāt do with your functions. Iāve spent a lot of time carefully defining types and see mypy give me 100% coverage, and each time it was great reward!
But, even if itās rewarding, letās face it: I donāt find them really useful in Python.
When I write code with statically typed languages, checks at compilation time can give me some confidence with my code. The best language Iāve tested for this is Rust: it can take a lot of time before my code compiles, but when it does I can be almost sure that it does what I want. I then have the impression that the large amount of time Iāve spent defining types and ownership is very useful for the quality of the code I write.
I have the impression that adding type annotations in Python takes time, but that itāll never give me the confidence that types give me in other statically typed languages. If I want to carefully think about types, then I prefer to write Rust! The compiler is amazingly powerful, and it is by design.
To be honest, I often donāt want to carefully think about the types I use. Iām soooo lazy. For sure, itās really easy to write code that doesnāt work with Python. But itās also really easy write code that works. š Thatās what I love š. It will never be as clean, as solid, as "right" as Rust, but itās damn easier, faster and shorter, at least for me! And I can always write tests to check that I didnāt break anything.
Moreover, adding type annotations adds code. And I love when code is short, because I find it easier to read and to maintain. I think that finding "good" variable names is important because it increases readability, for example when reading the signature of a function. When there are type annotations, I really lose the ability to understand what the code does, because I have the feeling that types tell me how the code works.
In the future, I may be interested to add type annotations in projects that I know very well, if theyāre small enough to fit entirely in my head. But my head is really, really limited!
TL;DR: Letās say that I prefer when code is short and simple than extensive and exact.