I was today trying to achieve something similar. I also considered the solution using `type` argument, but that does not seem to play well with the `choices` argument. I was going to report that as a bug, but this issue seems similar enough to comment here instead.

The solution proposed by Paul works, in the sense that if 'I' is passed on the commandline, the parsed value because `int` (the actual type, not a string, not sure if Paul really intended that). However, when running --help with his example, you get:

    usage: foo.py [-h] {<class 'float'>,<class 'int'>}

So:
  - Since the `choices` argument is used to display help text, `choices` should  contain the values that should be specified on the commandline (e.g. the *inputs* to the `type` converter.
 - Since the *type-converted* value is checked against the `choices` argument, `choices` should contain the *outputs* of the `type` converter.

AFAICS these two constraints cannot be fulfilled at the same time, except when no type conversion happens (or, when converted values can be stringified back to their unconverted value, which works in simple cases, I suppose).

IMHO this looks like a bug: `type` and `choices` do not play well together. Checking specified values against `choices` *before* type conversion happens seems more sensible to me and would fix this, as well  fullfil Victor's original usecase (though not with the syntax he suggests).