On Tue, 04 Mar 2014 11:56:07 +0100, Antoon Pardon wrote: > Op 04-03-14 09:56, Steven D'Aprano schreef: > > >> >>> If you >>> explicitly say that this is an int, then yes, that should be >>> disallowed; >> It's that "explicitly" part that doesn't follow. Having to manage types >> is the most tedious, boring, annoying, *unproductive* part of languages >> like Java, C and Pascal. Almost always, you're telling the compiler >> stuff that it can work out for itself. > > In the same way writing unit tests is the most tedious, boring, > annoying, *unproductive* part.
Actually, I like writing unit tests. How do you know what the function does until you test it? I'm not a TDD fanatic, but often I write tests before I write the code, and there's really nothing nicer than seeing a whole lot of failing unit tests suddenly start working. Well, maybe a nice BLT sandwich, when the bacon is nice and lean and the lettuce crisp and the tomato flavourful and not too soggy. But other than that, writing unit tests and seeing them pass is great. On the other hand, writing int n, m double x, y and similar three hundred times throughout your program is not terribly exciting. Even when it compiles, it doesn't mean it works. > Amost always you are giving the program > results it can work out for itself. Not even close. I'd like to see the compiler that can work out for itself that this function is buggy: def sine_rule(side_a, side_b, angle_a): """Return the angle opposite side_b.""" return math.sin(side_b/side_a)*angle_a If you don't remember your Sine Rule from trigonometry, that's okay. Trust me, the function is badly wrong. It's rubbish really. But short of some really impressive AI coupled with a Mathematica-level of maths knowledge, how is the compiler supposed to know that? Static type testing, while valuable, cannot tell you that the program does what you wanted it to do. -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list