bluesky / ophyd-async

Hardware abstraction for bluesky written using asyncio
https://blueskyproject.io/ophyd-async
BSD 3-Clause "New" or "Revised" License
10 stars 23 forks source link

Cannot have tuples as soft signal values #393

Closed callumforrester closed 2 months ago

callumforrester commented 3 months ago

Trying to make a soft signal of type tuple[int, str, float], say, yields an error when you try to count it:

AssertionError: invalid converter for value of type <class 'tuple'>
coretl commented 3 months ago

I think this is a feature not a bug. Please can you provide the use case for supporting it.

callumforrester commented 3 months ago

I have a soft signal whose value should be a 3d vector (miller indices). So I wanted a SignalR[tuple[int, int, int]]. I can have a list, but then the type checker won't validate the dimensionality. Is there a particular issue with supporting tuples?

coretl commented 3 months ago

We had an ambition to do the type checking at the Signal level rather than the SignalBackend level. Then we didn't need to define another TypeVar for the supported types of each SignalBackend. Thinking about it though, PVA is more restrictive than CA so we would have to do that anyway.

Ok, so this makes sense. I assume the usecase is a SoftSignalBackend. How much runtime error checking do we want for those? Or casting? Length checking?

callumforrester commented 3 months ago

...I'm happy with virtually none. Unlike with an epics backend I'm typing the values into my IDE and using a static type checker so I'm happy to rely on that.

coretl commented 3 months ago

I guess your use case is read only then? For the read-write case, then your user might be using a generic abs_set plan, so will be reliant on runtime checking...

callumforrester commented 3 months ago

I will also say my use case for code that is temporary and that we don't expect to last forever, so if no one else is asking for this I wouldn't prioritise it.

coretl commented 2 months ago

Closing this until we have a concrete use-case. Initial set of supported types in #310