Making immutable instances

[bonono at gmail.com]

Mike Meyer wrote:
> bonono at gmail.com writes:
> > Mike Meyer wrote:
> >> bonono at gmail.com writes:
> >> > Well, in this case, would it be simple for the OP that if he wants to
> >> > disallow this attaching additional things, just use __slot__.
> >> That's *documented* as an implementation-dependent behavior. Using it
> >> to get that effect is abuse of the feature, and may well quit working
> >> in the future.
> > It still won't affect what is working, so it is harmless side effect,
> > if it ever changes in the future.
>
> If not allowing is required, then allowing is "not working", pretty
> much by definition.
>
> > Abuse or not doesn't matter so long it fits the needs, IMO.
>
> I guess it doesn't matter to you whether or not your code works in the
> future. It does to me.
>
For this particular case, I don't see it as a problem.

First it meets the need, works on 2.2, 2.3, 2.4. No one knows what
would change in the future, beside the fact that I don't see it as
implementation-dependent in the doc.

Adding to the fact that things can/may be removed even it is fully
documented, without this caveat emptor(like the famous reduce/map
etc.). That is if I read the document when I was writing python codes
in the early days and used reduce/map/filter/lambda, my code still
breaks if in one day those are removed and I can't forsee that either.

So why bother, unless it has some definitive schedule(like saying in
2.5, reduce won't be there or __slot__ behaviour will definitely
change), then I would consider if the code I write now should avoid
using it.

And back to this case, I regard it as a no harm side effect, yes, it
doesn't perform as expected(assume it really is changed in some unknown
version in the future) that someone does hang something there, it
doesn't hurt my expected usage of the class, as this is used to prevent
unexpected usage.

Quoting the frequently used term "Practicality beats purity". If I have
a practical problem/needs now and it solves it, why not use it ?

The zip(it,it) case is even worse than this __slot__ situation and I
don't have much problem in using that either. It is not unusual in this
industry that certain software only expects to be working with some
combination of OS/Compiler version.