[issue22049] argparse: type= doesn't honor nargs > 1

Changes by paul j3 : -- resolution: -> not a bug stage: needs patch -> resolved status: open -> closed ___ Python tracker ___ ___ Pyt

[issue22049] argparse: type= doesn't honor nargs > 1

Chris Bruner added the comment: Just had a chance to try this, and this does exactly what I wanted from "type=". Thank you! On Fri, Jul 25, 2014 at 4:17 PM, paul j3 wrote: > > paul j3 added the comment: > > What you want is a custom Action rather than a custom Type. > > from the documentation:

[issue22049] argparse: type= doesn't honor nargs > 1

paul j3 added the comment: What you want is a custom Action rather than a custom Type. from the documentation: >>> class FooAction(argparse.Action): ... def __call__(self, parser, namespace, values, option_string=None): ... print('%r %r %r' % (namespace, values, option

[issue22049] argparse: type= doesn't honor nargs > 1

Chris Bruner added the comment: Yes, I know. My function just sees '1', but I think it should see '1 2 3' so that it can figure out what to do. That's impossible (well, impossible without saving state between calls) when it sees the arguments piecemeal. Sent from my iPhone > On Jul 24, 2014,

[issue22049] argparse: type= doesn't honor nargs > 1

paul j3 added the comment: Note that '-t 1 2 3'.split() becomes ['-t', '1', '2', '3'] Your 'type' function sees those 3 strings individually. Try printing 'string' the first thing in your function to see what we mean. -- nosy: +paul.j3

[issue22049] argparse: type= doesn't honor nargs > 1

R. David Murray added the comment: Nope. The documentation says: N (an integer). N arguments from the command line will be gathered together into a list The type function is applied to each argument independently. It would be easy enough to make this explicit in one of the nargs multi-a

[issue22049] argparse: type= doesn't honor nargs > 1

New submission from Chris Bruner: >From the documentation, I think that argparse should pass the entire >nargs-long string to the "type=" callable. Instead, it only passes the first >argument (of nargs), making it impossible within argparse's framework to check >for a tuple of mixed types, e.g