> Indeed, especially Eckels article shed some light about testing as an > alternative to static typing. I still can't quite understand why you > can't > do both. Clearly unit tests should be part of any software, not only > Python software. > You can do both, but why? *Especially* in a language like C++, where thanks to pointers and casting, there really isn't any type safety anyway. How much time in your C/C++ code is spent casting and trying to trick the compiler into doing something that it thinks you shouldn't be doing?
> Test failures, however, don't tell you anything about the current > usage of > your program - just about the inteded usage at the point where the test > was writte. Clearly you can't test _anything_? And clearly you can > never > be sure that all you collegues did so as well? This not only about type > safety, but simply name safety. > How does type safety tell you anything about the current usage of your program? All static types can tell you is what the input/output types should be, and in no way show any semantic relationship between actual output and the input. Tests can do that. And unit tests *might* not tell about the current usage, but integration tests certainly do. > What do you do when you want to no if a certain method or function is > actually used from somewhere, say "foobar", it a language which allows > (and even encourages) that it could be called by: > > getattr(obj, "foo" + "bar")() > > ? > > There is no systematic way to find this call. > > In C++, just commend out the definition and the compiler will tell you. > I don't think I've ever seen anyone advocating calling a function like getattr(obj "foo" + "bar")(). You can do some very powerful things with getattr, thanks to Python's dynamic nature, but I don't think anyone is recommending calling a function like that. > That's true. If the programmer wants to obfuscate his intention, I'm > sure > neither Python nor C++ can stop him. The question is how much more > work is > to write comprehensible code in one language or the other. I'm a bit > afraid about Python on that matter. > And is that fear based simply on "feeling", or on actual experience. Because in all of my own industry experience, it's been MUCH easier to jump into someone else's Python code than someone else's C++ code (and at my last job, I had to do a lot of both). I find Python to be much more self-documenting, because there's not so much scaffolding all over the place obfuscating the true intention of the code. > Python provides ways to easy literal documentation. But I'd really > like to > have a way of indicating what I'm talking about in a way that's > ensured to > be in-sync with the code. Tests are not where the code is. I have > difficulties remembering the type of a lot of symbols, and looking at > testing code to fresh up usage is more difficult that just jumping to > the > definition (which the development envirnment is likely to be able to). > You need to look at doctest: http://docs.python.org/lib/module-doctest.html With doctest, tests are EXACTLY where the code is. I've used doctest with incredibly successful results, in industry. >> [smart pointers and GC] > > As you say, smart pointers are not full-blown garbage collection, > which is > usually what you want, isn't it? I my (admittedly short) life as a > professional developer I have not yet come accross a situation where > reference counting was not sufficient to model the memory management. > Reference counting by itself is not necessarily sufficient (because of circular references). That's why even Python, with its reference counting based system, has additional capabilities for finding circular references. >> At Google, we collectively have rather a lot of experience in these >> issues, since we use three general-purpose languages: Python, Java, >> C++. > > I have no doubt that goolge know what they're doing, and if you're > working > there then you're likely to know what you're talking about. > I believe that Alex's official job title at Google is "Uber Technical Lead". I'm sure I'll quickly be corrected if that's wrong, but trust me (and everyone else who's spent significant time reading c.l.p.) that Alex Martelli knows what he's talking about. A lot of your arguments are the very typical arguments that people levy against Python, when they're first around it. And that's fine, most people go through that. They are taught programming in C++ or Java, and that that *that* is the way you're supposed to program. Then they see that Python does things in different ways, and automatically assume that Python is doing it wrong. All I can say is that if you spend time with Python (and more importantly, read quality, well-established Python code that's already out there), you'll see and understand the Python way of doing things. Jay P. -- http://mail.python.org/mailman/listinfo/python-list
