On Fri, 30 Sep 2005 03:42:32 -0700, Paul Rubin wrote: > Steven D'Aprano <[EMAIL PROTECTED]> writes: >> Still, [EMAIL PROTECTED]'s point that you must know the base classes >> is correct. It is *easy* to find them out (NotSoSecret.__bases__ should do >> it), but if you don't you are taking a chance that your class name doesn't >> clash with one of the bases. > > It's not easy if the base classes change after you check your code in. > You shouldn't need to know about that if it happens. Modularity, remember?
Yes. And if you are relying on a public method in a class, and somebody dynamically modifies that public method, your code will stop working too. py> class Klass: ... def spam(self): ... return "spam" ... py> def food(): ... c = Klass() ... return c.spam() ... py> food() 'spam' py> Klass.Spam = Klass.spam; del Klass.spam py> food() Traceback (most recent call last): File "<stdin>", line 1, in ? File "<stdin>", line 3, in food AttributeError: Klass instance has no attribute 'spam' Let's be frank. When you have a dynamic language like Python, the cost is that somebody -- even yourself -- can pull the rug out from under your feet. But that cost gives you flexibility and power. While your competitors are still defining the variables and their types in some other language, you've finished and debugged your entire program. Now maybe they can put their hand on their heart and say with absolute 100% mathematical certainty that there are no bugs in their code, and you can't do that, and perhaps that mathematical certainty is appropriate for your ICBM control system or nuclear reactor, but it is a needless affectation for (say) a word processor. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
