Hi, I have come across the following statement a number of times:
http://mail.python.org/pipermail/python-list/2003-July/171805.html [... how to enforce pure abstract class ...] > Python, in general, doesn't try to stop the programmer doing things, the > way many other languages do. This is known in the community as the > "we're all consenting adults" philosophy. I have a split opinion on that: pro: If you're writing smaller apps and everything stays rather clearly laid out you don't need to care about abstract, virtual, accessor functions, private, public, interfaces, etc con: If you are planning larger applications (for a reasonable value of "large") you have to discipline yourself to write well structured code. Then you will want to specify interfaces, accessor functions with different read /write access, ... Unless you have designed the software interactions completely bevorehand (which never works out) this is the only way to incorporate changes without refactoring your source all the time. Therefore I come to the conclusion that a general purpose language like Python may well allow tampering with name-mangeling, dynamic method resolution, whatever, BUT it should also provide facilities to allow enforcing a more structured approach. This is why I welcome i.e. the decorator support in Python 2.4. And I think this should be expanded further, i.e. more build-in decorators for interfaces, abstract classes, parameter and return value restrictions. You can, but you must not; and I use both, depending on the project I'm working on. IMO this is a problem i.e. Perl is faceing: you can do even more rubbish with Perl than with Python and since there is no way of forcing a programmer to do it a certain way, its often easyer to rewrite Perl programs over 400 lines than to fix them. Ciao Uwe -- http://mail.python.org/mailman/listinfo/python-list