In D1812#41333, @Joshua Leung (aligorith) wrote:

Functionality
I guess this is ok. I'd been thinking of doing something similar that would allow for the use of strings here, that would have functioned in a similar manner.

Two minor potential issues that may arise (not blocking issues, but I think they should be noted here for future reference):

• I'm slightly worried about riggers getting lazy and just adding a single var for the object/bone, then grabbing the transforms off that (problematic because they'll not be grabbing the final transforms that way). Then again, they can do similar things already with the single prop anyway.

Valid point, but think guys who need to access this are already using workarounds, so not sure it changes much.

• If we do end up implementing a simpler Py-subset-expression-evaluator for use with driver expressions, "obj.prop" constructions in the expressions would necessarily need to be viewed as suspicious. This is because the goal of having that subset-evaluation engine is to bypass the need for autoexec protections to block the execution of the most common set of "simple" driver expressions (e.g. things like "var", or "var * 2", or "var * 10 + 1", vs "use_my_crazy_potentially_evil_callback("rm", "-rf")). The issue here with the functionality proposed here is that there may be some user confusion about why some driver vars passed in work, and others don't. However, at this stage, this system doesn't exist, so it's probably just a hypothetical concern that we don't need to care about too much now.

Am quite skeptical of auto-detection being used to validate strings. If we have some *safe* evaluate one day, likely this will only work for very basic expressions, non-trivial drivers will likely need to be updated.

Implementation

• IIRC, when using driver types other than expressions (e.g. Averaged Values), we will still end up looping over all the vars, calling driver_get_variable_value() on them. In that case, these variables would get flagged as being invalid.

This can only work with Python expression, so average values or anything are incompatible.

• Is the "As Object" toggle really needed? Couldn't we do something like check on the type of the RNA prop, and use Py Objects otherwise?
  
  On second thought, maybe it's ok - it does simplify checking for this case, and it would also allow bools to be represented in their native form instead of as floats).

Think its worth checking on making this default. With Python3 its _very_ unlikely people rely on a float in a way that breaks scripts, since Python coerces bools and ints into floats as needed.
So think its worth considering, if this works on a handful of complex rigs (rigify, blendrig, glasshalf... perhaps others on the cloud)... think its reasonable to make this change.

(Note that for making this default I'll need to add array index lookup support, will update patch).