Allow dict choices to "transform" values in argpagse

[vporton]

BPO	34188
Nosy	@rhettinger, @zware, @vporton

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2018-09-23.01:24:49.982>
created_at = <Date 2018-07-22.12:53:50.222>
labels = ['3.8', 'type-feature', 'library']
title = 'Allow dict choices to "transform" values in argpagse'
updated_at = <Date 2018-09-23.01:24:49.981>
user = 'https://github.com/vporton'

bugs.python.org fields:

activity = <Date 2018-09-23.01:24:49.981>
actor = 'paul.j3'
assignee = 'bethard'
closed = True
closed_date = <Date 2018-09-23.01:24:49.982>
closer = 'paul.j3'
components = ['Library (Lib)']
creation = <Date 2018-07-22.12:53:50.222>
creator = 'porton'
dependencies = []
files = []
hgrepos = []
issue_num = 34188
keywords = []
message_count = 9.0
messages = ['322142', '322144', '322167', '322168', '322170', '322233', '323673', '323681', '323732']
nosy_count = 6.0
nosy_names = ['rhettinger', 'bethard', 'paul.j3', 'zach.ware', 'porton', 'Matthijs Kooijman']
pr_nums = []
priority = 'normal'
resolution = 'rejected'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue34188'
versions = ['Python 3.8']

[vporton]

The below code produces "rock", but it should produce "a". This (to use dict value instead of the key by argparse result) is both to be a new useful feature (for example to map strings in a command line to certain functions or classes provided as dict values) and conform to intuition better.

My feature proposal breaks backward compatibility, but I think no reasonable programmer wrote it in such a way that he relied on the current behavior for dict values for choices.

import argparse

parser = argparse.ArgumentParser(prog='game.py')
parser.add_argument('move', choices={'rock':'a', 'paper':'b', 'scissors':'c'})
print(parser.parse_args(['rock']))

[zware]

I like to think I'm fairly reasonable :). You can get what you want by specifying type=choices_dict.get, or by extracting from the dict manually after calling parse_args.

[rhettinger]

I concur with Zachary. Downstream processing or transformation of inputs is beyond the scope of argparse which should stick to its core responsibilities of argument extraction.

[vporton]

@Raymond:
"Downstream processing or transformation of inputs is beyond the scope of argparse which should stick to its core responsibilities of argument extraction."

You somehow contradict the official documentation:
"One particularly effective way of handling sub-commands is to combine the use of the add_subparsers() method with calls to set_defaults() so that each subparser knows which Python function it should execute."

The official documentation seems to recommend to pass real Python functions to the parser. So it does do simple "processing or transformation of inputs" which you recommend against.

[rhettinger]

Victor, please don't try to get your way by adopting a tone of shoving people around or mis-parsing their words try to catch them in a contradiction. There is in fact a boundary between argument parsing logic and application logic. In my view, the proposed behavior crosses that boundary. Where the docs mention "transformations", they do so in limited ways (such as type conversion) that are tightly bound to argument parsing and are not part of the application logic.

FWIW, I'm not the one you need to convince. Steven Bethard is the module maintainer and arbiter of feature requests. Recommendations from Zachary and me are meant to help inform his decision.

[paulj3]

The 'choices' mechanism is a simple 'value in choices' test. A dictionary (or other mapping) works because it works with 'in'.

'type' as noted is the means that argparse provides for transforming an input string into some other object (most commonly a number with 'int' or 'float'). The choices test is performed after the type transformation.

The 'set_defaults()' with subparsers is offered almost as a parenthetical idea, and has nothing to do with 'choices' or 'type'. 'set_defaults' is just another way of setting default values, and works even with 'dest' which aren't otherwise defined. If that isn't clear, I'd suggest testing it with the main parser.

In Python functions are first class objects, and thus can be used just like strings or numbers - assigned to variables, put in lists, etc.

In:

   adict = {'I':int, 'F':float}
   parser.add_argument('foo', type=lambda x: adict.get(x), choices=adict.values())

the 'type' transforms the commandline string into a the dictionary value, and 'choices' then tests that against the values of the dictionary. (I had to use lambda instead of 'adict.get' directly because of testing that 'type' does.)