What static checking can actually guarantee varies depending on the specific type system at hand (C# vs Haskell vs Idris for example). But most of them can guarantee simple stuff like: "I'm I allowed to invoke this function at this point?"
If you don't have that, well you can rely on tests to show that certain code paths behave in a certain way when exercised with certain inputs. 2016-08-09 12:22 GMT-07:00 MRAB <pyt...@mrabarnett.plus.com>: > On 2016-08-09 19:57, Chris Angelico wrote: > >> On Wed, Aug 10, 2016 at 4:51 AM, Michael Selik <michael.se...@gmail.com> >> wrote: >> >>> "File-like" is a good example. Rather than go through the frustration of >>> a >>> formal definition for what is file-like, stay productive and flexible >>> with >>> duck typing. Objects that don't have the appropriate methods or >>> attributes >>> will cause a TypeError or AttributeError. If you're passing in the wrong >>> kind of object, you'll find out almost as soon as you write the code >>> (because you test early and often), just as you would with a statically >>> analyzed type system. >>> >> >> It's slightly delayed; with Python, you have to actually execute the >> code path in question, whereas a static type system would detect it at >> the compilation stage. So it may depend on the quality of your >> testing. MyPy may be able to help there. >> >> Static checking won't tell you if, say, you're adding when you should be > subtracting, so you'd need to execute the code path in question anyway > during testing! > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
