Matthijs Kooijman <matthijskooij...@gmail.com> added the comment:
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).
----------
nosy: +Matthijs Kooijman
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue34188>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
