I haven't used optional typing in python. However, the problem I see with optional typing is that while I may choose to use it my team mates might not. Even more importantly, the 3rd party dependencies I use probably don't. So the amount of code that actually uses the types would be very limiting. Saying the choice is entirely up to you personally is a misnomer.
Strict use of type annotations has to be a team decision, yes. Checking for them can be integrated into a CI build, though.
The typing spec provides for supplementary "stub files" that can be provided for third-party dependencies without their own annotations. The typeshed project provides these for a fair and quickly increasing number of common dependencies, and is plugged into pycharm and mypy by default: https://github.com/python/typeshed
Re:Diminishing returns of static typing
by yawaramin on Monday October 02, 2017 @03:43PM
(#15387259)
I think GP meant 'you' as in 'your team'. Anyway, Python has a type repository for popular libraries, just like TypeScript does. And mypy can still typecheck your code even without type annotations.
In fairness the hints available in Python 3 aren't really a static typing system. It would take a lot of extra work to make it one.
Re:Diminishing returns of static typing
by lomnakkus on Monday October 02, 2017 @05:09PM
(#15387974)
Well, nothing except almost the whole ecosystem of libraries not having type annotations, those type annotations that exist themselves being quite limited (IIRC), etc. etc.?
Can we stop pretending that adding type annotations to a 'dynamic' language solves the "good static typing" problem? It's just silly.
(About as silly as pretending that static types solve all problems.)
nothing stops you from using static typing with python3