Russ P. a écrit : (snip)
I think the issue here is the distinction between hacking and software engineering. I may be misusing the term "hacking," but I do not mean it in a pejoritive sense. I just mean getting things done fast without a lot of concern for safety, security, and long-term maintainability and scalability.
I do feel concerned by these issues.
I'm not a computer scientist, but it seems to me that Python is great for hacking and good for software engineering, but it is not ideal for software engineering. What Paul is suggesting, I think, is that Python should move in the direction of software engineering. Whether that can be done without compromising its hacking versatility is certainly a valid question, but if it can be done, then why not do it? Certainly one basic principle of software engineering is data encapsulation. Tacking new attributes onto class instances all over the place
There's a clear distinction between "making wise use of dynamicity" and "tacking new attributes onto class instances all over the place".
may be convenient and useful in many cases, but it is not consistent with good software engineering.
simplicity is "good software engineering". Accidental complexity is not. Dynamism _can_ greatly reduce accidental complexity.
If the programmer could somehow disallow it in certain classes,
Already possible - you just have to provide your own implementation of __setattr__.
that could be useful, providing that those who wish to continue doing it would be free to do so. If class attributes could somehow be declared private,
The important point is to make implementation distinct from interface - which we already know how to do -, and sometimes to prevent _accidental_ overriding of some critical implementation attributes - which is also already implemented. Enforcing access restriction is, from experience, just pointless.
""" patient : doctor, when I do this, it hurts doctor : well, don't do it, then. """ -- http://mail.python.org/mailman/listinfo/python-list
