Hi Leonard,
thanks for your reply. I don not really care about monitoring changes to an object, I just choose this example to show why the following workflow is not working:
In [38]: b = launchpad.bugs[253799]
In [39]: b.tags
Out[39]: [u'bar', u'foo']
In [40]: b.tags.append("far")
n [41]: b.lp_save()
This fails silently, because launchpadlib does not know about changes of mutable attributes of an object.
IMHO, changing the type of the tags attribute to a tuple or a string is not a good solution, the workflow described above is the most natural one.
Without knowing all the internals of launchpadlib I agree that wrapping it in a proxy object is not a good solution here. But what about storing mutable objects in a cache right after fetching the data, and when calling lp_save() compare the current value with the value in the cache. This way you know if a mutable object changed. - just my suggestion.
Hi Leonard,
thanks for your reply. I don not really care about monitoring changes to an object, I just choose this example to show why the following workflow is not working:
In [38]: b = launchpad. bugs[253799]
In [39]: b.tags
Out[39]: [u'bar', u'foo']
In [40]: b.tags. append( "far")
n [41]: b.lp_save()
This fails silently, because launchpadlib does not know about changes of mutable attributes of an object.
IMHO, changing the type of the tags attribute to a tuple or a string is not a good solution, the workflow described above is the most natural one.
Without knowing all the internals of launchpadlib I agree that wrapping it in a proxy object is not a good solution here. But what about storing mutable objects in a cache right after fetching the data, and when calling lp_save() compare the current value with the value in the cache. This way you know if a mutable object changed. - just my suggestion.
Markus