[Python-Dev] argparse ugliness (original) (raw)
Eric Smith eric at trueblade.com
Wed Mar 10 14:13:17 CET 2010
- Previous message: [Python-Dev] argparse ugliness
- Next message: [Python-Dev] argparse ugliness
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Nick Coghlan wrote:
Greg Ewing wrote:
Steven Bethard wrote:
Because the names are so long and you'd have to import them, I've left them as private attributes of the module, but if there's really demand, we could rename them to argparse.StoreTrueAction, etc. What's wrong with just StoreTrue? All of this discussion about the class names is ignoring the main benefit of using the string names: - with Python variables, you just get a generic name error at the reference site (which may or may not be useful, depending on the program structure) - with a string, the parser tells you that the problem is with the requested action for a particular argument The second, explicit error is going to be more informative in most cases. Using strings also reduces the verbosity of the code, avoiding either an "argparse." buried in the middle of the function call, or else a "from argparse import ".
I agree that it should be left as a string. About the only reason I would suggest changing it from a string to an object is that it makes it obvious that argparse does accept an object that conforms to the Action API. But this is already well documented, so I don't see the need. Just leave it as a string.
-- Eric.
- Previous message: [Python-Dev] argparse ugliness
- Next message: [Python-Dev] argparse ugliness
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]