[issue29626] Issue with spacing in argparse module while using help

paul j3 added the comment: I don't anticipate any backward compatibility issues with the proposed patch. But at the same time it feels almost too trivial of an issue to merit a patch. A short metavar such as `metavar="ID"' or even `metavar="_"' would be

[issue29670] argparse: does not respect required args pre-populated into namespace

paul j3 added the comment: http://bugs.python.org/issue26394 Have argparse provide ability to require a fallback value be present is a related issue - getting 'required' values from a config file. -- ___ Python tracker <http://bu

[issue26394] Have argparse provide ability to require a fallback value be present

paul j3 added the comment: http://bugs.python.org/issue29670 argparse: does not respect required args pre-populated into namespace wants to put 'required' values in the Namespace. That's a similar issue. An idea that I tried for that (but didn't submit as a patch) is to mo

[issue29670] argparse: does not respect required args pre-populated into namespace

paul j3 added the comment: http://bugs.python.org/issue27859 argparse - subparsers does not retain namespace may complicate this issue. Due to changes in http://bugs.python.org/issue9351, a user defined namespace is not passed to the subparsers. They get a fresh namespace, which is then

[issue36078] argparse: positional with type=int, default=SUPPRESS raise ValueError

Change by paul j3 : -- priority: normal -> high ___ Python tracker <https://bugs.python.org/issue36078> ___ ___ Python-bugs-list mailing list Unsubscrib

[issue36267] User input to argparse raises Index_Error: "-a=" on a 'store_true' action

New submission from paul j3 : Test case: parser = argparse.ArgumentParser() parser.add_argument("-a", action="store_true") args = parser.parse_args("-a=".split()) raises an Index_Error, which is not caught by the argparse error mechanism. This is an

[issue33775] argparse: the word 'default' (in help) is not marked as translatable

paul j3 added the comment: I haven't paid much attention to the localization issues in `argparse`. The issue is with the help modification done by the: class ArgumentDefaultsHelpFormatter help += ' (default: %(default)s)' This formatter is a convenience, not something

[issue33775] argparse: the word 'default' (in help) is not marked as translatable

paul j3 added the comment: https://bugs.python.org/issue16786 points out that the 'version' action isn't localizable either. -- ___ Python tracker <https://bugs.pyt

[issue36664] argparse: parser aliases in subparsers stores alias in dest variable

paul j3 added the comment: I added a `print(args)` to clarify what you are talking about: 2148:~/mypy$ python3 issue36664.py subsection Namespace(context='subsection') my subsection was called 2148:~/mypy$ python3 issue36664.py s Namespace(context='s') my functon was not

[issue36664] argparse: parser aliases in subparsers stores alias in dest variable

paul j3 added the comment: https://docs.python.org/3/library/argparse.html#argparse.ArgumentParser.add_subparsers shows how to use `set_defaults` in a parser to set a 'func' attribute. That method could just as well be used to set the true 'name' or any other kind o

[issue35495] argparse does not honor default argument for nargs=argparse.REMAINDER argument

paul j3 added the comment: At the start of parse_known_args, all defaults (except SUPPRESS ones) are placed in the namespace: # add any action defaults that aren't present for action in self._actions: if action.dest is not SUPPRESS: if not ha

[issue13824] argparse.FileType opens a file and never closes it

paul j3 added the comment: While I continue to follow argparse issues, I'm not doing development (with my own repository, etc). I haven't revisited the issue since 2013, and don't know that much more about Python file handling. Occasionally 'FileType' issues

[issue9351] argparse set_defaults on subcommands should override top level set_defaults

paul j3 added the comment: A variation on the problem I reported in https://bugs.python.org/issue9351#msg229968 is that a custom Namespace class as documented in https://docs.python.org/3/library/argparse.html#the-namespace-object will not be used by the subparsers. Only the main parser

[issue35495] argparse does not honor default argument for nargs=argparse.REMAINDER argument

paul j3 added the comment: Let me back off on that last suggestion. The problems described here and in https://bugs.python.org/issue17050 only apply to a positional. We could just add a note to the documentation to the effect. This nargs is best used as an optional as illustrated

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

paul j3 added the comment: I attached a script that implements Evan's _match_argument idea, using a ArgumentParser subclass. I think this is the safest way to add different functionality to the parser. It (subclassing) is used, for example in pypi extensions like plac. My version p

[issue32833] argparse doesn't recognise two option aliases as equal

Change by paul j3 : -- nosy: +paul.j3 ___ Python tracker <https://bugs.python.org/issue32833> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyth

[issue32756] argparse: parse_known_args: raising exception on unknown arg following known one

Change by paul j3 : -- nosy: +paul.j3 ___ Python tracker <https://bugs.python.org/issue32756> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyth

[issue32833] argparse doesn't recognise two option aliases as equal

paul j3 added the comment: Subparsers have aliases, argument option strings don't, at least not formally. Once an argument is added, its flags are entered in several lists. One list belongs to the Action itself, another belongs to the parser (it might actually be a dictionary). The

[issue32833] argparse doesn't recognise two option aliases as equal

paul j3 added the comment: When I run your setup in ipython, I see a display of the newly added Action: Out[2]: _StoreAction(option_strings=['--a-b', '--ab'], dest='a_b', nargs=None, const=None, default=None, type=None, choices=None, help=Non

[issue32756] argparse: parse_known_args: raising exception on unknown arg following known one

paul j3 added the comment: This error message is intentional. In def consume_optional(start_index): # identify additional optionals in the same arg string # (e.g. -xyz is the same as -x -y -z if no args are required) # if the action is a

[issue32756] argparse: parse_known_args: raising exception on unknown arg following known one

paul j3 added the comment: Try adding a simple positional argument. '-ab' would still produce this error. -- ___ Python tracker <https://bugs.python.o

[issue17050] argparse.REMAINDER doesn't work as first argument

paul j3 added the comment: This is another expression of the bigger problem of handling arguments that look like flags. In optparse the 'nargs' (or equivalent, it doesn't handle positionals), control how many arguments an Option takes, regardless of their form. In argparse,

[issue17050] argparse.REMAINDER doesn't work as first argument

paul j3 added the comment: Oops, I see I already mentioned 9334. Here the parsing sequence is a bit different, and the fix I suggest there would not apply here. But the underlying issue is still there - the parser has, in its first iteration, determined that the '--def' loo

[issue17050] argparse.REMAINDER doesn't work as first argument

paul j3 added the comment: REMAINDER is not widely used, and probably was not tested thoroughly during development. It works for the example given in the docs. A variant, argparse.PARSER ('A...') is widely used. This is, effectively, REMAINDER ('...') that requires an

[issue17050] argparse.REMAINDER doesn't work as first argument

paul j3 added the comment: A REMAINDER that would work with a flag-like string would be too powerful, too greedy. In [64]: p = argparse.ArgumentParser(); In [65]: p.add_argument('--foo'); In [66]: p.add_argument('rest', nargs='...'); If the f

[issue32867] argparse assertion failure with multiline metavars

paul j3 added the comment: I haven't seen anyone try to use \n in a metavar before, but other special characters like [] and () produce this assertion error. At this point the code is trying split the usage into 2 or more lines, because it's too long for one. It creates a

[issue32756] argparse: parse_known_args: raising exception on unknown arg following known one

paul j3 added the comment: >From the documentation, 16.4.4.1. Option value syntax > For short options (options only one character long), the option and its value > can be concatenated: > Several short options can be joined together, using only a single - prefix, > as long a

[issue33343] [argparse] Add subcommand abbreviations

paul j3 added the comment: This issue was raised in https://bugs.python.org/issue12713, argparse: allow abbreviation of sub commands by users A patch was implemented, and then reverted when it was found to be buggy. Subcommands are not parsed the same as long options. Subcommands are

[issue32552] Improve text for file arguments in argparse.ArgumentDefaultsHelpFormatter class

paul j3 added the comment: This subclass makes are one method change: from: def _get_help_string(self, action): return action.help to: def _get_help_string(self, action): help = action.help if '%(default)' not in action.help: if action.

[issue17050] argparse.REMAINDER doesn't work as first argument

paul j3 added the comment: Since this feature is buggy, and there isn't an easy fix, we should probably remove any mention of it from the docs. We can still leave it as an undocumented legacy feature. There is precedent for leaving `nargs` constants undocumented. `argparse.P

[issue22848] Subparser help does not respect SUPPRESS argument

paul j3 added the comment: I've reviewed the comments and proposed patch, and still think that the custom metavar is still the best fix. subparses.metavar can be changed after subparsers has been created. The programmer could, for example, write a simple helper function that

[issue33389] argparse redundant help string

paul j3 added the comment: This is normal behavior for argparse. People have asked before for a more compact display. I remember suggesting changes to the HelpFormatter subclass on Stackoverflow questions, and there's probably one or more bug/issues addressing the same

[issue33415] When add_mutually_exclusive_group is built without argument, the help breaks with "IndexError: list index out of range"

paul j3 added the comment: The usage formatter is brittle, especially the part that adds mutually exclusive markings to the normal usage string. I don't think I've seen this error before, but I'm not surprised. A real fix requires a rewrite of the usage formatter, which I&

[issue33389] argparse redundant help string

paul j3 added the comment: https://bugs.python.org/issue29626 Issue with spacing in argparse module while using help This deals with a extra space that is produced when a blank metavar is used to produce a more compact help line -s , --service help text My answers have links to

[issue33389] argparse redundant help string

paul j3 added the comment: Also https://bugs.python.org/issue27303 [argparse] Unify options in help output -- ___ Python tracker <https://bugs.python.org/issue33

[issue22848] Subparser help does not respect SUPPRESS argument

paul j3 added the comment: I've attached a file that tries out the idea of building a custom `metavar` in the `add_parser` method. It subclasses argparse._SubParsersAction, and registers it with the parser. No other modification to production code is required. Subparsers with a blank

[issue31640] Document exit() from parse_args

paul j3 added the comment: And the actual exit is via `parse.error` and `parse.exit`, which are documented in 16.4.5.9. When run interactively in Ipython, exits (including the help) are captured and displayed with: In [896]: parser.parse_args() usage: ipython3 [-h] [--one | --two | --six

[issue31768] argparse drops '|'s when the arguments are too long

paul j3 added the comment: As documented in many other issues, the usage formatter is brittle. It formats the individual usages, joins them into a string. Then if too long to fit on one line it tries t split into actions, etc. This split produces an assertion error if there are '

[issue31768] argparse drops '|'s when the arguments are too long

paul j3 added the comment: I've changed your example a bit to clarify some points. parser.add_argument('n', type=int) group = parser.add_mutually_exclusive_group() group.add_argument("-v", "--verbose", action="store_true") group.add

[issue9253] argparse: optional subparsers

paul j3 added the comment: In a recent stackoverflow question a user wanted this optional-subparsers ability in Python 2.7. https://stackoverflow.com/questions/46667843/how-to-set-a-default-subparser-using-argparse-module-with-python-2-7 Short of modifying the _parse_known_args method, the

[issue18943] argparse: default args in mutually exclusive groups

paul j3 added the comment: Did you copy the output right? Testing your parser: Without any arguments, I get the exclusive group error - the group is required: 0930:~/mypy/argdev$ python3 issue18943.py usage: issue18943.py [-h] (--device-get-capabilities | --ptz-absolute

[issue32123] Make the API of argparse.HelpFormatter public

paul j3 added the comment: A difficulty with writing a public API is that useful changes can occur at almost any level of the class. The existing subclasses modify small, but deep methods, ones that handle things like line wrapping. On the other hand, most of the issues you cite deal with

[issue18943] argparse: default args in mutually exclusive groups

paul j3 added the comment: That's not how flagged (optionals) arguments work. The default value is used if the flag is not provided at all. One of your arguments is a 'store_true'. Its default value if False, which is changed to True if the '--device-get-capabiliti

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

paul j3 added the comment: In the recently pushed, https://bugs.python.org/issue14191, "argparse doesn't allow optionals within positionals" we added new parsing functionality by defining a new parser method: parse_intermixed_args It added functionality without requiring a ne

[issue32474] argparse nargs should support string wrapped integers too

paul j3 added the comment: In https://bugs.python.org/issue11354 'argparse: nargs could accept range of options count' I explored the option allowing regex style range arguments, such as nargs='{2,4}' or an equivalent tuple nargs=(2,4). But that builds on https://bugs.

[issue32123] Make the API of argparse.HelpFormatter public

paul j3 added the comment: To elaborate on my last comment, the existing subclasses that customize formatting modify _fill_text _split_lines _get_help_string _get_default_metavar_for_optional _get_default_metavar_for_positional those are all 'private

[issue15327] Argparse: main arguments and subparser arguments indistinguishable

Change by paul j3 : -- nosy: +paul.j3 ___ Python tracker <https://bugs.python.org/issue15327> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyth

[issue15112] argparse: nargs='*' positional argument doesn't accept any items if preceded by an option and another positional

paul j3 added the comment: `parse_intermixed_args` was added in v 3.7. https://docs.python.org/3/library/argparse.html#intermixed-parsing https://stackoverflow.com/questions/50916124/allow-positional-command-line-arguments-with-nargs-to-be-seperated-by-a-flag

[issue34046] subparsers -> add_parser doesn't support hyphen char '-'

paul j3 added the comment: Do you understand why this is happening? Subparsers is, in effect, a positional argument with 'choices' - the choices being the parsers (and their aliases). But '-dr' looks like an flagged (optionals) argument. Since you didn't define

[issue34174] argparse formatter_class issue for RawDescriptionHelpFormatter

paul j3 added the comment: argparse does import 'textwrap', but as '_textwrap', so it could be used with: argparse._textwrap.dedent(...) Importing your own is cleaner. -- nosy: +paul.j3 ___ Python tracker <https://bug

[issue34191] argparse: Missing subparser error message should be more clear

paul j3 added the comment: Your code runs fine under 3.6.5. But if I add 'subparsers.required=True', I get your error. It's having problems formatting the name of the subparsers command when issuing the error message. If I add a 'dest' to the add_subparsers

[issue34188] Allow dict choices to "transform" values in argpagse

paul j3 added the comment: 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 o

[issue34191] argparse: Missing subparser error message should be more clear

paul j3 added the comment: Updating you Python3.7 might change the behavior. If I read https://github.com/python/cpython/commits/master/Lib/argparse.py correctly, subparsers are no longer required by default (it reverted back to earlier Py3 behavior). There is a proposed patch for

[issue34299] argparse description formatting

Change by paul j3 : -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue34299> ___ ___ Python-bugs-list

[issue34390] arparse.ArgumentParser misparses list arguments followed by undefined arguments

paul j3 added the comment: Parsing is a two step process. First the strings are passed through def _parse_optional(self, arg_string): which classifies them as 'O', an optional flag, or 'A', an argument. - no prefix char => A - the string is in the dictionary of optio

[issue34390] arparse.ArgumentParser misparses list arguments followed by undefined arguments

paul j3 added the comment: Duplicate of https://bugs.python.org/issue22909 [argparse] Using parse_known_args, unknown arg with space in value is interpreted as first positional arg (closed as duplicate) https://bugs.python.org/issue22433 Argparse considers unknown optional arguments with

[issue34188] Allow dict choices to "transform" values in argpagse

paul j3 added the comment: The 'choices' mechanism is quite simple. As noted for testing it simply uses an 'in' test. For help formating it uses choice_strs = [str(choice) for choice in action.choices] result = '{%s}' % ','.join(choice_

[issue34458] No way to alternate options

paul j3 added the comment: I agree that a custom Action subclass like this is the way to go. The regular 'append' is implemented in _AppendAction class, which is different from the default _StoreAction. So even if there was enough demand for this new idea to be put into devel

[issue34479] ArgumentParser subparser error display at the wrong level

paul j3 added the comment: The subparser is called with `parse_known_args` which just puts unknown args in a _UNRECOGNIZED_ARGS_ATTR attribute slot in the namespace, which is then passed back to the main parser. (this occurs in _SubParsersAction.__call__) If `parser.parse_known_args` is

[issue34479] ArgumentParser subparser error display at the wrong level

paul j3 added the comment: Errors that are associated with a specific argument, such as a wrong 'type' do get usage from the appropriate subparser. e.g. In [164]: p.parse_args('--foo 1 cmd1 --bar x'.split()) usage: ipython3 cmd1 [-h] [--bar BAR] ipython3 cmd1: e

[issue14156] argparse.FileType for '-' doesn't work for a mode of 'rb'

paul j3 added the comment: It's been sometime since I looked at this issue. The main sticking point is passing unittests, and ensuring that there are no backward compatibility issues. But, since FileType is a standalone class, anyone could put a corrected version in their own work

[issue32027] argparse allow_abbrev option also controls short flag combinations

paul j3 added the comment: The PR 4396 should be closed. -- nosy: +paul.j3 ___ Python tracker <https://bugs.python.org/issue32027> ___ ___ Python-bugs-list m

[issue34724] argparse subparser help indent too short

paul j3 added the comment: Looks like I had my say on this in the Stackoverflow link (3 yrs ago). -- nosy: +paul.j3 ___ Python tracker <https://bugs.python.org/issue34

[issue34742] Add optional argument for exit status in argparse.ArgumentParser.error

Change by paul j3 : -- nosy: +paul.j3 ___ Python tracker <https://bugs.python.org/issue34742> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34744] New %(flag)s format specifier for argparse.add_argument help string

paul j3 added the comment: In your example, what is 'flag'? There's no Action attribute of that name. There is a 'dest' and a 'option_strings' list. All the 'help' '%(...)s' does is display one of the Action object attribute

[issue34742] Add optional argument for exit status in argparse.ArgumentParser.error

paul j3 added the comment: While I don't think this change will cause any backward compatibility issues, I wonder whether it does much good. https://docs.python.org/3/library/argparse.html#exiting-methods already documents the option of customizing `parser.exit` and `parser.

[issue34458] No way to alternate options

Change by paul j3 : -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue34458> ___ ___ Python-bugs-list

[issue34479] ArgumentParser subparser error display at the wrong level

Change by paul j3 : -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue34479> ___ ___ Python-bugs-list

[issue34744] New %(flag)s format specifier for argparse.add_argument help string

paul j3 added the comment: In your proposed change: params = dict(vars(action), prog=self._prog) + if action.option_strings: + params['flag'] = action.option_strings[0] 'params', as I noted earlier already includes the 'dest&#x

[issue16360] argparse: comma in metavar causes assertion failure when formatting long usage message

paul j3 added the comment: I'm closing this since the https://bugs.python.org/issue11874 fix also handles this issue. -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.pyth

[issue34479] ArgumentParser subparser error display at the wrong level

Change by paul j3 : -- resolution: -> not a bug ___ Python tracker <https://bugs.python.org/issue34479> ___ ___ Python-bugs-list mailing list Unsubscrib

[issue34458] No way to alternate options

Change by paul j3 : -- resolution: -> not a bug ___ Python tracker <https://bugs.python.org/issue34458> ___ ___ Python-bugs-list mailing list Unsubscrib

[issue34744] New %(flag)s format specifier for argparse.add_argument help string

Change by paul j3 : -- resolution: -> rejected stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue34188] Allow dict choices to "transform" values in argpagse

Change by paul j3 : -- resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue34188> ___

[issue34046] subparsers -> add_parser doesn't support hyphen char '-'

Change by paul j3 : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue34046> ___

[issue26952] argparse help formatter crashes

paul j3 added the comment: If I add an argument to the mutexGroup as suggested by xiang In [7]: mutexGroup.add_argument('--foo', action='store_true') Out[7]: _StoreTrueAction(option_strings=['--foo'], dest='foo', nargs=0, const=True, default=False, typ

[issue33415] When add_mutually_exclusive_group is built without argument, the help breaks with "IndexError: list index out of range"

paul j3 added the comment: This is duplicate of https://bugs.python.org/issue26952 - argparse help formatter crashes The same issue - a mutually exclusive group without arguments. It also deals with issue of nesting groups. -- resolution: -> duplicate stage: -> resolved

[issue26952] argparse help formatter crashes

paul j3 added the comment: https://bugs.python.org/issue29553 deals with a similar problem, the usage display when one mutually exclusive group is embedded in another mutually exclusive group. In that case, usage is displayed, but with some missing brackets. As here there are two issues

[issue34744] New %(flag)s format specifier for argparse.add_argument help string

paul j3 added the comment: The preferred way of adding new features to the Formatter is to subclass it, and modify one or more methods. That's what the existing alternative formatters do. A user can easily create such a subclass, and use it with their own parser, without having to m

[issue34803] argparse int type does not accept scientific notation

paul j3 added the comment: The `type` parameter is normally a function (or more generally a callable). When given a string it should convert it as needed, or raise an error. In your example that function is the stock, 'int()'. Test `int('123')`, `int('1e3')

[issue34803] argparse int type does not accept scientific notation

Change by paul j3 : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue34803> ___

[issue32552] Improve text for file arguments in argparse.ArgumentDefaultsHelpFormatter class

paul j3 added the comment: An alternative to customizing a HelpFormatter is to write your own utility `add_argument` function, e.g. def my_add_argument(parser, *args, add_default=True, **kwargs): if add_default: help = kwargs.get('help','') help += &#x

[issue34827] Make argparse.NameSpace iterable

paul j3 added the comment: As documented in https://docs.python.org/3/library/argparse.html#the-namespace-object you can create your own 'namespace' class, that does everything you want and more. argparse makes very few assumptions about the object - using getattr, setattr, a

[issue32756] argparse: parse_known_args: raising exception on unknown arg following known one

Change by paul j3 : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue32756> ___

[issue32833] argparse doesn't recognise two option aliases as equal

paul j3 added the comment: I'm going to close this issue. The current behavior is a logical consequence of how option_strings and abbreviations are handled. Handling this particular case differently would be require adding a special test, as opposed to a minor tweak to the current

[issue32552] Improve text for file arguments in argparse.ArgumentDefaultsHelpFormatter class

paul j3 added the comment: https://bugs.python.org/issue28742 argparse.ArgumentDefaultsHelpFormatter sometimes provides inaccurate documentation of defaults, so they should be overrideable is asking for something similar - the ability to override the automatic `%(default)s` in certain cases

[issue34744] New %(flag)s format specifier for argparse.add_argument help string

paul j3 added the comment: https://bugs.python.org/issue13280, argparse should use the new Formatter class Raymond Hettinger argued against making such a switch. However there may be some value in allowing its use in parallel with the '%' style of formatting. That is, if the &#x

[issue13280] argparse should use the new Formatter class

paul j3 added the comment: Thinking about https://bugs.python.org/issue34744, I realized that the new style formatting could provide some added flexibility to the help lines. I think new style formatting could be added in parallel with the existing style, as an alternative, not as a

[issue35005] argparse should accept json and yaml argument types

paul j3 added the comment: The results of reading one of these @-prefix files are just spliced into the `argv` list before it is parsed. This is done early in the parsing method, in the _read_args_from_files method. The documentation illustrates how this file reading can be modified to

[issue35005] argparse should accept json and yaml argument types

paul j3 added the comment: If I define a 'type' function like: def readdata(astr): if astr.startswith('@'): with open(astr[1:], 'r') as f: d = json.load(f) return d else: return astr I can use it to load a json fi

[issue30220] Why are custom messages for ValueError, TypeError suppressed in argparse?

paul j3 added the comment: I'm going to close this. Python makes it easy to test for Exception class. Testing exception messages is messy, especially if the test wants to compare the message against 'generic message'. I don't see anything generic about the messages pr

[issue20039] Missing documentation for argparse.ArgumentTypeError

paul j3 added the comment: A related closed request: https://bugs.python.org/issue30220 that wants to test ValueError for non-generic message, instead of using ArgumentTypeError. -- ___ Python tracker <https://bugs.python.org/issue20

[issue35005] argparse should accept json and yaml argument types

paul j3 added the comment: Adding a new 'type' function or factor is certainly possible, and probably will be free of backward compatibility issues. But so far no other custom type has been added to argparse. https://bugs.python.org/issue23884 - rejects adding a DateTime cl

[issue35005] argparse should accept json and yaml argument types

paul j3 added the comment: This kind of file read can be done just as easily after parsing. For example using the function in my previous post: In [127]: parser = argparse.ArgumentParser() In [128]: parser.add_argument('-d','--data'); In [129]: args = parser.parse_a

[issue35049] argparse.ArgumentParser fails on arguments with leading dash and comma

paul j3 added the comment: I think it's the same issue. A dash argument that is not clearly a number is interpreted as an optional's flag. With few exceptions, the parser does not examine the contents of the string It tests the initial character, it tests for space, it tests f

[issue35049] argparse.ArgumentParser fails on arguments with leading dash and comma

Change by paul j3 : -- resolution: -> duplicate stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue35049> ___

[issue14191] argparse doesn't allow optionals within positionals

paul j3 added the comment: This is a refinement of the patch with Message188609. In parse_known_intermixed_args, the temporary capture of formatted usage has been put in a try/finally structure. Positionals are now 'deactivated' with action.nargs = SUPPRESS action.default

[issue9625] argparse: Problem with defaults for variable nargs when using choices

Changes by paul j3 : -- nosy: +paul.j3 ___ Python tracker <http://bugs.python.org/issue9625> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue9625] argparse: Problem with defaults for variable nargs when using choices

paul j3 added the comment: I've added 2 more tests, one with default='c', which worked before. one with default=['a','b'], which only works with this change. http://bugs.python.org/issue16878 is useful reference, since it documents the differences between

[issue16468] argparse only supports iterable choices

Changes by paul j3 : -- nosy: +paul.j3 ___ Python tracker <http://bugs.python.org/issue16468> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

<    1   2   3   4   5   6   7   8   >