bluesky / ophyd

hardware abstraction in Python with an emphasis on EPICS
https://blueskyproject.io/ophyd
BSD 3-Clause "New" or "Revised" License
48 stars 77 forks source link

Raise Exception on problem Device names #875

Open stashlukj opened 4 years ago

stashlukj commented 4 years ago

Device names with illegal characters can fail in unexpected ways.

Expected Behavior

LiveTable shows the normal entries.

Current Behavior

The livetable runs, but gives "failed to format row" messages. The document in db[-1].table() is still ok looking.

Possible Solution

The MyDevice constructor should raise an exception about the dicey ':' and '.' in the name.

Steps to Reproduce (for bugs)

class MyDevice(Device):
    x = Component(Signal)

det = MyDevice("illegal.device:name")

uid, = RE(count([det], num=1), LiveTable(det.name))

print(db[-1].table())

Context

I was trying to debug why I couldn't LivePlot my sensor.

Your Environment

Ubuntu 20.04 in WSL. Python 3.8. bluesky==1.6.2

prjemian commented 4 years ago

This is for the ophyd repository.

prjemian commented 4 years ago

I moved this because the logic for creating a Device lives in ophyd. LiveTable is a callback in bluesky and should not be responsible for catching problem names for Devices.

tacaswell commented 4 years ago

I don't think we forbid ":" in the names? I am also not sure how much we want to enforce limits imposed by the EventModel (which is actually imposed by a particular database choice in terms of the '.') down to the ophyd level. It is convenient for or current use cases, but it in not clear to me that we want to constrain other the use of arbitrary names in other contexts.

The problem @stashlukj found with LiveTable was that the name had a ':' in it, we format a format string which looks like {{{name}:{fmt}}} which comes out looking like {name:part:d}.format(**{'name:part': value}) which that fails to find the key "name" :facepalm:

klauer commented 4 years ago

ophyd itself doesn't really care about names, as far as I recall. Downstream clients and databases may fail based on their own requirements for column names (for example).

Separately, bluesky does not require ophyd. If a custom, non-ophyd class follows the BlueskyInterface and has a "bad" name, LiveTable/databroker/etc will fail just the same.

tacaswell commented 4 years ago

https://github.com/bluesky/bluesky/pull/1367 fixes this on the bluesky side.