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 <whatever>". 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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4