Jay wrote: > 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?
Not much frankly. Though I have no doubt that there is a lot of code that does, but more so in older C++ code. > How does type safety tell you anything about the current usage of your > program? Quite a bit; of course, it's doesn't cover everything and clearly testing the semantics is still needed, but a lot of what code is used in what way is described by the type system. And I admit that I'm used to use the type system as documentation of what's going on. > And unit tests *might* not tell about the current usage, but > integration tests certainly do. Of course tests will cover a lot what static typing does and more. I'm just claiming that they can support each other. > 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. A lot of people got me wrong on that, please see Paul's postings. I really didn't mean that literally. > And is that fear based simply on "feeling", or on actual experience. The former, that's why I did start this branch of the thread, though I'm already regretting it. > 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. That really depends on who's code you're looking at, as in any language. I can believe there are more C++ obfuscaters out there than ones for Python. I usually have little problems jumping into C++ code of other people but the principle reason for that will be that the people I'm working with have a very clean and expressive coding style. > 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. That's indeed a good point for Python. > 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. Whenever I encountered the need for circular references it was because an object, that was in some sense owned by another, needed a pointer back to it's owner. That solved easily with non-owning C-style pointers or weak pointers. If you have an example where this is not sufficient, I'd be *very* keen on hearing it (it may be easy, I don't know). > 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. You seem to be thinking that I was ironic. That was certainly not my intention. I was just trying to minimise the amount of flames I'll be getting. > 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. I'm sorry to hear this, and whilst I'm certainly lacking experience in Python, I'm not one of those people. > 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. I will. Jens -- http://mail.python.org/mailman/listinfo/python-list