3 ms·

The article doesn't mention type annotations described in PEP484 and added to CPython since Python 3.5. It is possible to add annotations to your code like

The article doesn't mention type annotations described in PEP484 and added to CPython since Python 3.5. It is possible to add annotations to your code like class Foo: x: int # ... and then run type checks using `mypy`, so that for the annotated code probability of the "passes the checks => won't crash the runtime" case is much larger.

striking 9y ago
Sure, but most python code isn't annotated, right? So this might be helpful for code you wrote, but not anywhere it interfaces with other peoples' code (which, in my opinion, is probably the most important place to check for type errors).
- Rapzid 9y ago
  Plus, many packages dynamically add members, stomp named parameters by wrapping stuff with kwargs, etc.
  - humanfromearth 9y ago
    So monkey patching is bad you're saying? I agree that it's possible what you're saying about kwargs, but after about 6 years of python I've never encountered that in any of the code that I've worked on.
- humanfromearth 9y ago
  True, but very popular packages are usually battle tested and type errors are very rare in practice in those packages. Most bugs I've seen are not because of the lack of a static type system.
- asddddd 9y ago
  The older method is docstrings (reST and similar) like here: https://github.com/kennethreitz/requests/blob/master/requests/api.py#L16 https://github.com/kennethreitz/requests/blob/master/request... IDEs like PyCharm can use those and other methods to find most typing issues. In practice this is very effective for most "boring" Python code, but if you get really clever it falls over completely.
fernly 9y ago
Or specifically to his example, from typing import Dict Foo = Dict[int:str] def __init__(self, name:str, balance=0.0): """Construct a Klass.""" self.myfoos = {} # type: Foo I _think_ that's right... close anyway

striking 9y ago

Sure, but most python code isn't annotated, right? So this might be helpful for code you wrote, but not anywhere it interfaces with other peoples' code (which, in my opinion, is probably the most important place to check for type errors).

Rapzid 9y ago
Plus, many packages dynamically add members, stomp named parameters by wrapping stuff with kwargs, etc.
- humanfromearth 9y ago
  So monkey patching is bad you're saying? I agree that it's possible what you're saying about kwargs, but after about 6 years of python I've never encountered that in any of the code that I've worked on.
humanfromearth 9y ago
True, but very popular packages are usually battle tested and type errors are very rare in practice in those packages. Most bugs I've seen are not because of the lack of a static type system.
asddddd 9y ago
The older method is docstrings (reST and similar) like here: https://github.com/kennethreitz/requests/blob/master/requests/api.py#L16 https://github.com/kennethreitz/requests/blob/master/request... IDEs like PyCharm can use those and other methods to find most typing issues. In practice this is very effective for most "boring" Python code, but if you get really clever it falls over completely.

fernly 9y ago

Or specifically to his example, from typing import Dict Foo = Dict[int:str] def __init__(self, name:str, balance=0.0): """Construct a Klass.""" self.myfoos = {} # type: Foo I _think_ that's right... close anyway