On Dec 7, 2007 10:39 AM, paul <[EMAIL PROTECTED]> wrote: > Chris Mellon schrieb: > > On Dec 6, 2007 5:52 AM, paul <[EMAIL PROTECTED]> wrote: > > >> function or method. I hope type annotations in py3k will allow for > >> something like constraints in C# where you can tell the caller right > >> away she's doing something wrong. > >> > > [language rant snipped] > > On a more pragmatic basis, there are only 2 kinds of type errors in Python: > > 1: The object passed doesn't implement the correct interface, and will > > raise an error when called. This will be caught by a unit test. > > 2: The object passed implements something that looks like the right > > interface, but implements it incorrectly. This will be caught by a > > unit tests. > So if I use your code I need to read all of it to understand how "file > like" something for bla(filelike) needs to be to be able to write > unittests? Or do your unittests magically detect all possible callers > and send them email with nice warnings? >
My unit tests assert that operations perform as desired. Yours should to. If they don't, your code might not behave as desired. Those are called "bugs". Real live type errors are a subclass of bugs. Type errors that occur because you'd didn't sufficiently placate the compiler are not bugs, they are obnoxious. In my Python work, I have *never* had a bug occur in production that would have been caught by a C++/Java/C# style type system. Are you seriously suggesting here that there should be a type for every possible combination of methods and attributes that might be needed for a file like object? > > > > Note that both these errors will be caught by behavior exercising unit > > tests and do not rely on any sort of "typechecking code" to be > > written. Explicit typechecking in Python is done only when you need to > > dispatch on type, not because you feel like generating spurious > > errors. > Do you prefer situations like Hrvoje has descibed two post below? > > To reiterate: I'd like to have a TypeError: "foo called with <str>, > <Point> expected" which is concise and informative for the caller, > rather than have him hunt down obscure errors in totally unrelated code > like AttributeError: 'str' object has no attribute 'move'. > The type error is *wrong*, and you only want it because you think backwards. The error is not that what was passed was the wrong type, because "type" is an ephemeral concept in Python. The problem was that the thing passed doesn't have a "move" method or, possibly, that the move method didn't do the right thing. There's no reason whatsoever that I should need to inherit from your Point class just to make this method work (there's actually a corner case where you do, which is with types implemented in C, but I'll leave that alone for now). I reiterate my suggestion to use Haskel, or another language with type inference, because that's what you really want, if you're going to go the static typing route. If you're looking for static typing, you're in the wrong newsgroup. And even if you are, manifest typing where you need to declare everything by hand and then force the compiler to ignore the declarations in order to compile anyway is a dead end. If you find benefit in static typing and want to write your code that way, there are better approaches, like ML-style type inference. -- http://mail.python.org/mailman/listinfo/python-list
