Param parse

[alexcjohnson]

@AdriaanRol @MarkusJacobsen Some more parsing options for Parameters:

• separate functions for parsing both ways: set_parser to transform the input value, and get_parser to transform the instrument response (replaces parse_function)
• for symmetry, I also added this to Function, where I called them parameter_parser and return_parser because it's not really set and get there.
• an even shorter, cleaner mechanism, val_mapping for cases where there are a fixed set of possible values that need to be passed to the instrument in coded form - a single dictionary takes care of translating for both set and get, as well as generating the correct Validator

parse_function still works but is marked deprecated - I'll take out existing parse_function instances and the compatibility code in a later PR - after this PR is merged and you've had a chance to merge master into any branches you're working on - so the change doesn't conflict with things you are doing now.

[alexcjohnson]

syncable_command has too many parameters... much more comprehensible AND robust to call it with only kwargs.

[AdriaanRol]

In general I think having a set and a get parser makes perfect sense 👍

[alexcjohnson]

Thanks @AdriaanRol - any comments about val_mapping? Is it clear what this is for and how to use it?

[AdriaanRol]

I think val_mapping itself is clear, the only thing that is not clear to me form the example is which end of the command is the user end (I assume '0' and '1') and which end is the instrument side (I assume 'one' and 'zero'). Maybe a one line comment to the test case there and all should be good.

[alexcjohnson]

the only thing that is not clear to me form the example is which end of the command is the user end

Yes, that's always a concern with bidirectional mappings... - how's this?

[alexcjohnson]

(and a tiny bit more)

[AdriaanRol]

💃 (or was there something else here?)