realOri - non-flipping orient constraint 1.4.0 for Maya (maya script)

Understanding what causes flipping rotation values in orient constraints:
1. *Vector math: Is used in the orient constraint to arrive at a world space orientation, not the complete concantenation of a source hierarchies rotations.
2. Maya's local/world rotation manipulator: is a superimposed screen space 'handle' for adding rotations to pre-existing values in an 'interactive mode'. Once in 'interactive manipulation mode' the manipulator has no 'memory' of generated rotation values and the axis values can be swaped around to arrive at a final orientation. This is because there are multiple ways to arrive at the same orientation depending on how an object is manipulated. This can lead to gimbal locked or 'flipped' values being generated (relative to previous values). In contrast, the 'Gimbal' manipulator displays the true rotation axis' as they relate to one another in their correct rotation order.
3. No reference rotation history: If an object has animation curves these can be used to build a rotation history by comparing the rotation values from the previous frame and adjusting the current values to remove flipping (Euler filtering/constraint caching). However, when recording rotation with euler curves there are multiple ways to arrive at the same orientation. Therefore techniques that record the difference between historic rotation values and interactively generated rotation values can lead to hysteresis. This means that when scrubbing back and forth or randomly accessing frames on the timeline the results can be different than if the animation is played from start to end.
What is needed is a way to update the target rotation values with the entire source rotation history as the source hierarchies are being manipulated.

The realOri (non-vector math*) hierarchical orient constraint
This simple expression queries rotate values from a source hierarchy and executes relative rotates on a target transform (xform -r -ro) to arrive at the same combined (historic) orientation as the source transform (hierarchy). This is far more useful than the default orient constraint - and IK solvers - which just provide an orientation 'snapshot' generated by a world space vector and therefore only support euler angles between -180 and +180 degrees. This limitation (combined with the unpredictability of gimbal lock) causes many problems when rigging natural systems in Maya.
This script is really just a quick prototype to prove a concept and to demonstrate its benefits. Ways of improving it might include hard coding the source hierarchy as direct connections and doing the necessary euler math in MEL rather than with the xform command. I chose to dynamically generate the hierarchies to allow for flexibility when re-parenting. As the exposed transform matrix and quaternion attributes don't support euler angles greater than 180 degrees the math required to calculate euler angle addition and subtraction in a MEL based expression may be too extensive. Use of the xform command simplifies these tasks while unfortunately adding an interactive overhead. There are also issues with interactivity and expression updates in the GUI that are not a problem in batch mode. The functionality of this script should be relatively easy to implement as a faster more 'interactive friendly' API node. I would be keen to hear feedback on ways to improve this script or to create other implementations.
WARNING:
As an expression that uses mel commands rather than direct connections name spaces must be used when importing files which may include clashing object names
Joints: for the target rotate values to correctly reflect source world values the target joint orient must be aligned to world orientation
Only supports one source target
USAGE:
Select a source then a target transform then run: realOri 0 0; Input transforms can be specified (scripted) by replacing zeros with source and target names