TaurusLabel: Warning when {} is part of the attribute value

[vallsv]

Hi,

Here is a log i receive from a device.

MainThread     WARNING  2020-09-09 20:13:35 b'TaurusLabel.foo/metadata/manager/dataFolder': Error formatting display (KeyError('scanName',)). Reverting to raw string

The short story is that the device attribute can contain strings like that /foo/bar/{scanName}.

Do you consider this warning relevant?

This is due to this part of the code. But value here is already pre-formatted. So there is not anymore distinction between the data value and the formatting. I feel like it's not easy to fix.

        try:
            v = value.format(dev=dev, attr=attr)
        except Exception as e:
            self.warning(
                "Error formatting display (%r). Reverting to raw string", e)
            v = value

I think i will only skip it on my logging config. But just to let you know it can happen.

[vallsv]

Oh, btw i have created that safe_format few years ago (https://github.com/silx-kit/pyFAI/blob/master/pyFAI/utils/stringutil.py#L57). This could fix this issue if you like. Basically everything is replaced, but non-matching sequences stay as it is.

[cpascual]

Thanks @vallsv for reporting! I think this should be considered a bug.

For simplicity, it can be reproduced with the following snippet:

from taurus.qt.qtgui.application import TaurusApplication
from taurus.qt.qtgui.display import TaurusLabel
import sys
app = TaurusApplication()
w = TaurusLabel()
w.setModel("eval:'foo{bar}'")
w.show()
sys.exit(app.exec_())

I am not sure about which approach to use for fixing it. The safe_format approach could do, but I would like to think a bit to see if there is a simpler solution in this specific case (something like changing the TaurusBaseComponent.defaultFormatDict to treat format strings literally)

[cpascual]

I looked a bit more into the code, and I think that, since the problem is limited to TaurusLabel's reimplementation of displayValue, probably the simplest is to follow there the approach of safe_format suggested by @vallsv .

I submitted the PR #1151 in this line. @vallsv , could you please test it?

[vallsv]

Yes, safe_format is not perfect cause you will still be able to replace stuff you should not, like i guess {obj}.

I will try to setup a test.