{"action":"closed","issue":{"url":"https://api.github.com/repos/NSLS-II/bluesky/issues/308","repository_url":"https://api.github.com/repos/NSLS-II/bluesky","labels_url":"https://api.github.com/repos/NSLS-II/bluesky/issues/308/labels{/name}","comments_url":"https://api.github.com/repos/NSLS-II/bluesky/issues/308/comments","events_url":"https://api.github.com/repos/NSLS-II/bluesky/issues/308/events","html_url":"https://github.com/NSLS-II/bluesky/issues/308","id":130011956,"number":308,"title":"Another looming API issue: 'set' is a contested term","user":{"login":"danielballan","id":2279598,"avatar_url":"https://avatars.githubusercontent.com/u/2279598?v=3","gravatar_id":"","url":"https://api.github.com/users/danielballan","html_url":"https://github.com/danielballan","followers_url":"https://api.github.com/users/danielballan/followers","following_url":"https://api.github.com/users/danielballan/following{/other_user}","gists_url":"https://api.github.com/users/danielballan/gists{/gist_id}","starred_url":"https://api.github.com/users/danielballan/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/danielballan/subscriptions","organizations_url":"https://api.github.com/users/danielballan/orgs","repos_url":"https://api.github.com/users/danielballan/repos","events_url":"https://api.github.com/users/danielballan/events{/privacy}","received_events_url":"https://api.github.com/users/danielballan/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":2,"created_at":"2016-01-30T17:03:18Z","updated_at":"2016-03-11T20:55:09Z","closed_at":"2016-03-11T20:55:09Z","body":"While I'm in the business of re-writing the Msg API in #294, let's consider another lurking issue: apparently \"set\" means \"set zero point\" to SPEC users like @cmazzoli. Last summer, @stuwilkins warned @tacaswell and I against adopting \"set\" as bluesky terminology. This has come up as a point of confusion a couple times since. Does anyone know whether this is common terminology in hardware control generally or mainly a SPEC thing?\r\n\r\nWhen we do add support for setting zero points, I would prefer something explicit like `set_zero` or `zeropoint`.\r\n\r\nAs for \"set\" itself, should we:\r\n* carry on with `Msg('set', ...)`, asking scientists to forget SPEC's meaning of \"set\" and learn ours\r\n* relent, and do a name change in bluesky and ophyd like\r\n\r\n    ```\r\n    s/Msg('set'/Msg('SOMETHING_ELSE'/\r\n    s/def set(/def SOMETHING_ELSE(/\r\n    s/\\.set(/.SOMETHING_ELSE(/\r\n    ```\r\n\r\nCandidates for SOMETHING_ELSE:\r\n* 'write', which is a better counterpart to 'read'\r\n* 'move': We avoided this originally to avoid have some isolation from `Positioner.move` and because people don't think about \"moving\" a temperature controller. I'm not sure \"writing\" to a temperature controller is much more intuitive, language-wise, and I do think that `move` ~~satisfies the bluesky API at this point.~~ could easily be made to satisfy the bluesky API if it was asynchronous by default. The behavior of `ophyd.commands.mov` and of `obj.move(wait=True)` would not have to change."}}