Andreas Beyer wrote: > There has been quite some traffic about mutable and immutable data types > on this list. I understand the issues related to mutable numeric data > types. However, in my special case I don't see a better solution to the > problem. > Here is what I am doing: > > I am using a third party library that is performing basic numerical > operations (adding, multiplying, etc.) with objects of unknown type. Of > course, the objects must support the numerical operators. In my case the > third party library is a graph algorithm library and the assigned > objects are edge weights. I am using the library to compute node > distances, etc. > > I would like to be able to change the edge weights after creating the > edges. Otherwise, I would have to remove the edges and re-create them > with the new values, which is quite costly. Since I also didn't want to > change the code of the graph library, I came up with a mutable numeric > type, which implements all the numerical operators (instances are of > course not hashable). This allows me to change the edge weights after > creating the graph. > > I can do the following: > >>> x = MutableNumeric(10) > >>> y = MutableNumeric(2) > >>> x*y > 20 > >>> x.value = 1.3 > >>> x*y > 2.6000000000000001 > >>> > > The effect of numerical operations is determined by the contained basic > data types: > >>> x.value = 3 > >>> x/2 > 1 > >>> x.value = 3.0 > >>> x/2 > 1.5 > >>> > > Augmented operations change the instance itself: > >>> x.value = 0 > >>> id(x) > -1213448500 > >>> x += 2 > >>> x > MutableNumeric(2) > >>> id(x) # show that same instance > -1213448500 > >>> > > Is there anything wrong with such design?
The library you are planning to feed with your mutable numbers has to be designed with such somewhat unusual beasts in mind. For instance, it can no longer cache intermediate values as their constituents may have changed without notification. Don't use that design unless the library's designers explicitly allow it or at least after extensive testing. Be aware that in the latter case every new version of the library may break your app beyond fixability. > I am a bit surprised that > Python does not already come with such data type (which is really simple > to implement). I'm guessing: Such a type is not normally useful -- and if you need it it is really simple to implement :-) Peter -- http://mail.python.org/mailman/listinfo/python-list
