Nevermind, I found the bug in the above code and edited it so it now works.
But the code would better be:
@def itemChange(self, change, value):
print "itemChange", change, value
return value@
The critical part of the documentation is "The default implementation does nothing, and returns value." More precisely it could say: simply returns the passed parameter having name value, unchanged.
There is no reason to call the base class implementation, but you MUST return a result having the same type as the parameter named value.
That is, itemChange() is a hook: it is called when Qt has a value for a change and gives you the opportunity to alter the value before Qt uses the value. If you don't return a value properly, the results are unpredictable. The default implementation is an idempotent hook: transmits the value parameter unchanged.
Note that itemChange(), like sceneEvent() and a few other methods in the list of protected methods of QGraphicsItem have non-void return value. Be careful to return a value that is not None. Apparently Qt does not do run-time error checking (or at least in the Python binding, a returned value of None passes any type checking that Qt does.)
The documentation for itemChange() says "adjustments can be made." This is poor technical writing because it uses the passive voice. It would be better stated: in your reimplementation, you can adjust the value, but you should always return a result having the same type as the parameter named value.
The code and documentation would also be better if longer names were used: itemChange(changeType, changeValue). As you can see in my discussion above, it is difficult for readers to distinguish between the parameter having name value, and the value of that parameter. In other words, the word "value" is too abstract and generic. "Return a value" is too easily confused with "return the parameter having name: value".
