Whoops I forgot to list the reference. Also, I just finished reading the old thread, so I see some damage-control may be needed.
On Sat, 4 Mar 2006 11:52:59 -0600 Terry Hancock <[EMAIL PROTECTED]> wrote: > [1] > http://news.hping.org/comp.lang.python.archive/28916.html And more specifically, I'm referring to Alex Martelli's reply: http://news.hping.org/comp.lang.python.archive/28966.html [Vain attempt to co-opt a flame-war follows] And having seen that that discussion largely devolved into a rant about why "you shouldn't do that", can we PLEASE restrict this thread to the *how*? My use case is quite similar to Ben's enumeration type. In both cases, assigning attributes to the objects is NONSENSICAL and possibly UNWISE. Any attempt to do so is almost certainly a bug in your code if you are using my module -- and it happens to be one I want to make sure I catch. It is also true that the average person using my code is not a blackbelt pythoneer, but rather a scripter who needs/wants training wheels whenever it is practical to provide them. If you are REALLY sure you want mutability, you can always subclass it. If you think that code that handles prime numbers by marking integer objects like so: 101.prime = True is "just fine", and are not bothered that 101 is mysteriously unclassified sometime after you've marked it (because 100+1 is 101 == False), then we are not going to see eye-to-eye, so let's not argue about it. I also am not trying to alter the Python language. I am trying to figure out how to most easily fix __setattr__ etc to act immutably, *using* the existing features. I can already do what I want with some 25-30 lines of code repeated each time I need it, but I think it's dumb that it's that complicated. -- Terry Hancock ([EMAIL PROTECTED]) Anansi Spaceworks http://www.AnansiSpaceworks.com -- http://mail.python.org/mailman/listinfo/python-list