"Giovanni Bajo" <[EMAIL PROTECTED]> writes: > My feeling is that you're trying to get too much out of my words. I'm > not trying to handcuff anyone. You seem to concentrate on me trying to > avoid people adding attributes to my precious objects. It's not > that. If I write a class and want it to be immutable, it is because it > has to be so. If I write a queue class and I say that people shouldn't > call pop() if it's empty, I mean it. If I enforce it with a > RuntimeError, I'm not thinking I'm handcuffing someone. I don't see a > ImmutableError to be so different from it.
But why would you call it that, when the object isn't actually implemented as immutable? It's pretty misleading to call an object immutable rather than saying that it shouldn't be changed for some reason. Throw an exception that describes why it doesn't make sense to change that particular object instead. As I said before, I think you're confusing the (in Python pretty non-existent) concept of encapsulation with Python's immutable types, which are immutable because the implementation demands it. (A fact I hope will disappear at some point.) -- Björn Lindström <[EMAIL PROTECTED]> Student of computational linguistics, Uppsala University, Sweden -- http://mail.python.org/mailman/listinfo/python-list
