Mike Meyer wrote: >>> Note that this property of __slots__ is an implementation detail. >>> You >>> can't rely on it working in the future. >> I don't "rely" on it. I just want to catch bugs in my code. > > I certainly hope you're not relying on it to catch bugs. You should do > proper testing instead. Not only will that catch pretty much all the > bugs you mention later - thus resolving you of the need to handcuff > clients of your class - it will catch lots of other bugs as well.
This sounds a little academic. Writing a real Python program without testing is impossible or close to it, so you are really not telling me anything new. Even *with* testing, there are bugs. I'm sure you well know this. 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. I often design objects that I want to be immutable. I might keep it as a key in dictionaries, or I might have external, non-intrusive caches of some kind relying on the fact that the instance does not change. Of course, it *might* be that testing uncovers the problem. Unittests tend to be pretty specific, so in my experience they happen to miss *new* bugs created or uncovered by the integration of components. Or if they hit it, you still have to go through debug sessions. An ImmutableError would spot the error early. In my view, enforcing immutability is no different from other forms of self-checks. Do you reckon all kind of asserts are useless then? Surely they don't help for anything that a good unittest couldn't uncover. But they help catching bugs such as breakage of invariants immediately as they happen. Immutability can be such an invariant. >>>> If it's not a wart, why would it be a wart for user-defined types >>>> to >>>> have the same behaviour? >>> >>> It's a wart because user-defined classes *don't* have the same >>> behavior. >> Then *my* solution for this would be to give user-defined classes a >> way to behave like builtins, eg. explicitally and fully implement >> immutability. > > Well, if you want to propose a change to the language, you need a good > use case to demonstrate the benefits of such a change. Do you have > such a use case? Catching bugs doesn't qualify, otherwise Python would > be radically different from what it is. One good reason, in my opinion, is that there *are* immutable objects in Python, among builtins. And people can easily build extension objects which are immutable. So being impossible to write a regular object in Python which is immutable is not orthogonal to me. Now let me ask you a question. What is a good use case for "assert" that justifies its introduction in the language? What is a good usecase for module 'unittest' which justifies its introduction in the standard library? Why do you think tuples are immutable and *enforced* to be so? >> Immutability is an important concept in Python programs, and I'm >> impressed it does not have explicit support. > > I'm not convinced that immutability is that important a concept. Yeah, > you have to know about it, but it seems more like an implementation > detail than a crucial concept. Probably it's just a matter of design styles. > I'm not sure it's more important than > things like interned strings and the sharing of small integers. Most > of the discussion of immutables here seems to be caused by newcomers > wanting to copy an idiom from another language which doesn't have > immutable variables. Their real problem is usually with binding, not > immutability. I'm not such a newcomer, but (how funny) Python is *the* language that introduced me to the concept of immutable objects and their importance in design :) -- Giovanni Bajo -- http://mail.python.org/mailman/listinfo/python-list
