3 ms·

Can’t you write the Python functions to force check the input parameter for its type? And error out if not. This should enable you to catch most errors immedi

Can’t you write the Python functions to force check the input parameter for its type? And error out if not. This should enable you to catch most errors immediately during development.

mixmastamyk 6y ago
Yes, but easier to just write tests.
- throwaway894345 6y ago
  And easier still just to use static types.
  - mixmastamyk 6y ago
    Often not, if the overhead of adding them outweighs their utility for the project.
throwaway894345 6y ago
No, this doesn’t help at all. You only hit these errors if you run those paths in your tests, but those paths would already error downstream. Those paths that weren’t tested may still contain errors that go to production, and again you just hit your new type error instead of the downstream type error. What you need is something that can help you test more paths, and static type checking checks all paths. Further, they can check all paths without writing any tests (you should still have tests, but you need fewer with a static type system to keep your bug rate the same). Moreover, static type checkers catch errors almost immediately, so you get feedback about your errors sooner rather and more frequently, so you spend less time investing in code that will have to be rewritten. Lastly, they put rails on the code—it’s harder to write bad code including gratuitously magical or abstract code, so your coworkers aren’t writing as much bas code that you have to interface with. If you find static type systems to be frustrating, you’re probably the problematic coworker. :)
- blackrock 6y ago
  I don’t disagree with you. Python seems to encourage poor development practices. Basically, anything goes. This can be problematic if you use other people’s libraries, and if their libraries are not fully vetted. This is not a Python problem, per se. It is a developer problem. It is a human problem. However, with your own code and libraries, you can enforce your own rigor. Keep your functions smaller, test all the inputs, and validate all the outputs. Although you may end up with smaller production code, but more unit tests. The unit tests are good, as they give you evidence that you did cover those corner cases. However, the good thing, is that if the functions are smaller, and well unit tested, then it becomes rare that you have to modify it at a later date. And especially if you think through all the different angles, and try to future proof it. Now you have the ability to do functional composition. Just keep chaining the outputs of one function into another.

Can’t you write the Python functions to force check the input parameter for its type? And error out if not. This should enable you to catch most errors immediately during development.

mixmastamyk 6y ago

Yes, but easier to just write tests.

throwaway894345 6y ago
And easier still just to use static types.
- mixmastamyk 6y ago
  Often not, if the overhead of adding them outweighs their utility for the project.

throwaway894345 6y ago

No, this doesn’t help at all. You only hit these errors if you run those paths in your tests, but those paths would already error downstream. Those paths that weren’t tested may still contain errors that go to production, and again you just hit your new type error instead of the downstream type error. What you need is something that can help you test more paths, and static type checking checks all paths. Further, they can check all paths without writing any tests (you should still have tests, but you need fewer with a static type system to keep your bug rate the same). Moreover, static type checkers catch errors almost immediately, so you get feedback about your errors sooner rather and more frequently, so you spend less time investing in code that will have to be rewritten. Lastly, they put rails on the code—it’s harder to write bad code including gratuitously magical or abstract code, so your coworkers aren’t writing as much bas code that you have to interface with. If you find static type systems to be frustrating, you’re probably the problematic coworker. :)

blackrock 6y ago
I don’t disagree with you. Python seems to encourage poor development practices. Basically, anything goes. This can be problematic if you use other people’s libraries, and if their libraries are not fully vetted. This is not a Python problem, per se. It is a developer problem. It is a human problem. However, with your own code and libraries, you can enforce your own rigor. Keep your functions smaller, test all the inputs, and validate all the outputs. Although you may end up with smaller production code, but more unit tests. The unit tests are good, as they give you evidence that you did cover those corner cases. However, the good thing, is that if the functions are smaller, and well unit tested, then it becomes rare that you have to modify it at a later date. And especially if you think through all the different angles, and try to future proof it. Now you have the ability to do functional composition. Just keep chaining the outputs of one function into another.