Mike Meyer wrote: > That's not a use case, that's a debugging aid. The same logic applies > to adding type declarations, private/public/etc. declerations, and > similar B&D language features. It's generally considered that it's not > a good enough reason for adding those, so it doesn't really constitute > a good enough reason for making an instance immutable. > By design, this is a "don't use" feature so it would be very hard to find a "use case" ;-)
I can only think of a situation which may not be able to detect by testing. Say I have a module version 1 which is used by app version 1. In your app, you attach your own attribute to an instance of the module. Everything is fine. Now module becomes version 2 which happens to use the same attribute name that you hang on it and the program starts to behave strangely because they are stepping on each other's foot without knowing it. If everything is done by the same group of people with good communication, it may be possible to detect it. But if the module is done by a third party, and the app is done by yet another third party. The situation becomes complicated. Say if under debian, I do an apt-get python-sqlobject which may be used by multiple apps. If one of them happens to do it this way, this senario may happen. -- http://mail.python.org/mailman/listinfo/python-list
