Change by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<https://bugs.python.org/issue46101>
___
___
Python-bugs-list mailing list
Unsubscribe:
paul j3 added the comment:
At least until these latest deprecations, the only nesting that made sense was
to put a mutually_exclusive_group inside an argument_group. This was a way of
providing a title and description for the exclusive_group. (And not
documented.) I don't know if t
paul j3 added the comment:
Don't add an argument_group to another argument_group. While input allows this
nesting, the formatting is not designed to handle it. Nor does the
documentation illustrate such nesting.
Nesting a mutually_exclusive_group in an argument_group works becaus
paul j3 added the comment:
This patch should be rejected.
By using `common_opts_parser` as parent to both the main and subparsers, you
have defined the same argument in both.
By a long standing patch, the value assigned in the subparser has precedence
(whether it's the default or
paul j3 added the comment:
"I tried to create a group hierarchy in a way that I can pass the
responsibility of argument validation to the argument parser."
I looked at your example in:
https://bugs.python.org/issue46058
The many levels of nesting groups was confusing, but now
paul j3 added the comment:
Duplicate of https://bugs.python.org/issue41255
Argparse.parse_args exits on unrecognized option with exit_on_error=False
--
nosy: +paul.j3
resolution: -> duplicate
stage: patch review -> resolved
status: open -&g
Change by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<https://bugs.python.org/issue46080>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by paul j3 :
--
resolution: -> rejected
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<https://bugs.python.org/issue46228>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from paul j3 :
The Windows programming guidelines for the multiprocessing module documentation
should include a warning that any logging initialization should be protected by
the 'if __name__' block. Otherwise you will get duplicate logging entries for
the child
paul j3 added the comment:
'-1' and '-1.23' are recognized as numbers, and treated as arguments. '-1'
requires some special handling because it is allowed as a flag, as in
parser.add_argument('-1','--one')
'-1:00' on the ot
paul j3 added the comment:
I'm not set up to work with the current development distribution (via github).
All my proposed patches are diffs for earlier repos.
Paul
--
___
Python tracker
<https://bugs.python.org/is
paul j3 added the comment:
hai shi
Do you have a specific need for this, or do you want it just for the same of
completeness?
--
___
Python tracker
<https://bugs.python.org/issue9
paul j3 added the comment:
But see
https://bugs.python.org/issue37793
for a discussion of whether 'container' is as good a descriptor as 'iterable'.
--
___
Python tracker
<https://bug
paul j3 added the comment:
That usage formatting is extremely brittle. It's not just "" metavar that can
mess it up. Other 'usual' characters can mess it in the same way.
The underlying problem is that it formats the whole usage, and if it is too
long tries to
paul j3 added the comment:
https://bugs.python.org/issue26510
https://bugs.python.org/issue33109
There was some flip/flop over whether required should be true by default or not
- the current behavior is False, (the 3.3.0)
The lasting change since this issue in 2012 is that `add_subparsers
Change by paul j3 :
--
nosy: +paul.j3
status: closed -> open
___
Python tracker
<https://bugs.python.org/issue27227>
___
___
Python-bugs-list mailing list
Un
paul j3 added the comment:
Which is more valuable to you, the string conversion, or the checking?
What's wrong with doing the 'type check' in post parsing code? (MarSoft's
answer in the SO link).
To make a better case for this, I'd suggest writing your own fix.
paul j3 added the comment:
So the error occurs in HelpFormatter._format_action when 'help_lines' is an
empty list:
if action.help:
help_text = self._expand_help(action)
help_lines = self._split_lines(help_text, help_width)
>>
Change by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<https://bugs.python.org/issue38438>
___
___
Python-bugs-list mailing list
Unsubscribe:
paul j3 added the comment:
Just today on SO someone found a similar bug in the help format with metavars,
that involved an unpacking the expected only one value, but got 2.
https://stackoverflow.com/questions/58541460/tuple-metavar-value-for-positional-argument-with-nargs-1
This had be
paul j3 added the comment:
Just clarify how the code currently works. `subparsers` is a positional Action
of subclass _SubParsersAction. It has a nargs='+...', requiring at least one
string, and taking all remaining strings. Its __call__ has the standard
signature. So everyth
paul j3 added the comment:
A couple of quick observations:
- this is one of the first patches that I worked on, so the details aren't
fresh in my mind. A glance at my latest patch show that this isn't a trivial
change.
- nargs changes affect the input handling, the parsing
paul j3 added the comment:
With one exception, groups are not designed or intended to be nested. But by
inheritance (from _ActionsContainer) nesting isn't blocked nor does it raise
any errors.
As you surmise, an ArgumentGroup, is used only for grouping the help lines. By
default tha
paul j3 added the comment:
get_default just returns the default attribute as it is stored in the Action.
Defaults are stored as given.
During parsing the Action's default is placed in the args namespace at the
start. At the end, it checks if the value in the namespace is a string
paul j3 added the comment:
An overlapping issue
https://bugs.python.org/issue18943
argparse: default args in mutually exclusive groups
That issue shows that this problem arises with small integers as well (<257),
which in cpython have unique ids. It's an implementation detail,
paul j3 added the comment:
This is a well known (if not fixed) issue - if subparsers is required, then a
dest is needed to give a working error message. Looks like we've variously
talked about documenting the requirement, or using some sort of substitute for
the missing name.
One
paul j3 added the comment:
Let's see if I can clarify somethings. But first, I should say that I've
worked with this code for so long, that I may miss things that could confuse a
beginner.
A basic distinction is between "optionals" and "positionals". I put t
paul j3 added the comment:
Post parsing testing for the correct number of strings is the easy part.
It's the auto-generate usage that's harder to do right, especially if we wanted
to enable the metavar tuple option. Clean usage for '+&#
paul j3 added the comment:
You test with RawDescriptionHelpFormatter, but quote from the
RawTextHelpFormatter.
--
nosy: +paul.j3
___
Python tracker
<https://bugs.python.org/issue43
paul j3 added the comment:
To a large degree the Action parameters operate independently. That is,
different parts of the code use the parameters for their own purposes. The
composite behavior is a result of those individual actors, rather than some
sort of overall coordinated plan.
First
paul j3 added the comment:
Joker
'type=bool' has been discussed in other issues. 'bool' is an existing python
function. Only 'bool("")' returns False. Write your own 'type' function if
you want to test for specific strings. It&#x
paul j3 added the comment:
I've explored something similar in
https://bugs.python.org/issue11588
Add "necessarily inclusive" groups to argparse
There is a local variable in parser._parse_known_args
seen_non_default_actions
that's a set of the actions that have be
paul j3 added the comment:
More on the refactoring of error handling in _parse_known_args
https://bugs.python.org/issue29670#msg288990
This is in a issue wanting better handling of the pre-populated "required"
arguments,
https://bugs.python.org/issue29670
argparse: does n
paul j3 added the comment:
Another way to play with the defaults is to use argparse.SUPPRESS. With such a
default, the argument does not appear in the namespace, unless provided by the
user.
In [2]: p = argparse.ArgumentParser()
...: p.add_argument('--foo', default=argpars
Change by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<https://bugs.python.org/issue44986>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<https://bugs.python.org/issue44587>
___
___
Python-bugs-list mailing list
Unsubscribe:
paul j3 added the comment:
This is has been requested various times on StackOverflow, and possibly here
(I'd have to do a search).
The closest thing to making a compact action_invocation is to set the metavar
to '', and even thing we get a space, eg.
-f , --foo
paul j3 added the comment:
https://bugs.python.org/issue42980 argparse: GNU-style help formatter
https://bugs.python.org/issue33389 argparse redundant help string
https://bugs.python.org/issue29626
Issue with spacing in argparse module while using help
https://bugs.python.org/issue27303
paul j3 added the comment:
The idea of combining help features by defining a subclass that inherits from
other subclasses was endorsed by the original developer (we could dig up an old
bug/issue to prove that).
The provided subclasses all tweak a "private" method, often one tha
paul j3 added the comment:
In
https://stackoverflow.com/questions/69108632/unable-to-catch-exception-error-for-argparse
we found that `exit_on_error` does not work when the error occurs in a
subparser.
Unless someone wants to take time to get this right, I think this feature
should be
paul j3 added the comment:
In
https://stackoverflow.com/questions/69108632/unable-to-catch-exception-error-for-argparse
it looked like `exit_on_error` does not work when using subparsers. On on
further thought, I realized that it has to included in the definition of the
subparser. As
Change by paul j3 :
--
Removed message: https://bugs.python.org/msg401554
___
Python tracker
<https://bugs.python.org/issue41255>
___
___
Python-bugs-list mailin
paul j3 added the comment:
Adding `newline` to `FileType` requires modifying both the `__init__` and
`__call__` methods. That's nearly the whole class. I'd copy and edit, and
forget about subclassing.
--
___
Python track
Change by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<https://bugs.python.org/issue45587>
___
___
Python-bugs-list mailing list
Unsubscribe:
paul j3 added the comment:
`add_argument` also returns a Action subclass object. All of those subclasses
are "private". While that return reference is usually ignored, sometimes it is
useful to it, assigning it to a variable or list. The documentation could be
clearer about
paul j3 added the comment:
The usage formatting is fragile, with many associated bug reports. Until
someone does a major rewrite, it is best to avoid special characters,
especially `()` and `[]` in the `dest` or `metavar`.
Usage uses () to encolde mutually_exclusive_groups and [] to mark
paul j3 added the comment:
Are you expecting the subcommand help to show the 'help' line that the main
help shows?
subparsers.add_parser('a', help='a help')
add_parser takes all of the parameters that `ArgumentParser` takes, including
description and epilo
paul j3 added the comment:
As a default option flags can be abbreviated (unless there's a conflict).
Recent version have a allow_abbrev parameter that lets you turn this off.
--
nosy: +paul.j3
___
Python tracker
<https://bugs.py
Change by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<https://bugs.python.org/issue45235>
___
___
Python-bugs-list mailing list
Unsubscribe:
paul j3 added the comment:
I haven't studied or tested this change, but it looks like a partial retraction
of
https://bugs.python.org/issue9351
argparse set_defaults on subcommands should override top level set_defaults
Originally the main namespace was passed to the subparser. S
paul j3 added the comment:
I just downloaded this `argparse.py`.
This change makes it impossible to use a subparser argument if it is defined in
the user provided namespace, or by the main parser. It blocks not only
subparser default, but also user input.
It has reverted the 9351 patch
paul j3 added the comment:
parser = argparse.ArgumentParser()
sub = parser.add_subparsers()
example_subparser = sub.add_parser("example")
example_subparser.add_argument("--flag", default=10)
print(parser.parse_args(["example","--flag=15"
paul j3 added the comment:
A _SubParsersAction is private to the extent that users should not attempt to
create it directly, and thus don't need to know the details - beyond what's
documented:
"The add_subparsers() method is normally called with no arguments and returns a
Change by paul j3 :
--
stage: resolved -> test needed
status: closed -> pending
___
Python tracker
<https://bugs.python.org/issue45235>
___
___
Python-bugs-
Change by paul j3 :
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue45504>
___
___
Python-bugs-list
paul j3 added the comment:
Артём Иконников, developers and experienced users are familiar with other
programs, such as 'svn' which is used as an example
svn checkout, svn update, and svn commit
Also the use of '--foo' as flagged/optional(s) argument is so familiar to
New submission from paul j3 :
https://bugs.python.org/issue45235
argparse does not preserve namespace with subparser defaults
was passed and put into the latest release with rather obvious buggy behavior.
This means that the unittest file does not adequately test for overlapping
'des
paul j3 added the comment:
I should study previous posts in more detail, but here are some thoughts on
correctly handling user namespace.
At the start of `parse_known_args`, there's a
if namespace is None:
namespace = Namespace()
We need to hang on to a copy of
paul j3 added the comment:
A new patch, https://bugs.python.org/issue45235 has clobbered this patch.
It has also exposed the inadequate unittesting for the case(s) where the 'dest'
of main namespace, subparser namespace, user provided namespa
paul j3 added the comment:
There was a bug/issue that addressed problems with nested
mutually_exclusive_groups. It should be easy to find.
The problem is that the usage formatter is brittle, building a string and then
striping out "unnecessary" characters. I assume the fix h
paul j3 added the comment:
This is too big of an example for this board; I think it should have been asked
on StackOverFlow. Or maybe trimmed do to a more compact example.
But in any case, this is normal behavior for argparse. Type checking, here
'int', is done after the
paul j3 added the comment:
Use of 'prefix_chars' as a argument_group parameter is not documented, nor
intended.
If it does appear to work in the help formatting, it is probably the result of
inheritance, since both ArgumentParser and Argument_group subclass a
_Actions_Conta
paul j3 added the comment:
https://bugs.python.org/issue29553
Argparser does not display closing parentheses in nested mutex groups
supposedly fixed the parentheses for nested groups. You can read its
discussion and patches to see why it does not handle your case.
I don't see any exa
paul j3 added the comment:
prefix_chars is a parameter of the parent _ActionsContainer
class _ActionsContainer(object):
def __init__(self,
description,
prefix_chars,
argument_default,
conflict_handler):
super
paul j3 added the comment:
https://bugs.python.org/issue9338
argparse optionals with nargs='?', '*' or '+' can't be followed by positionals
As you can see this is an old issue, but still too big for a quick fix.
As a general rule, don't use `nargs`
paul j3 added the comment:
Put the required positional first
$ myapp myfile -s
or one of the store_true arguments
$ myapp -s -j myfile
I think
$ myapp -s -- myfile
will work as well, but that needs to be tested.
The '-s' has to be followed by something won't be
paul j3 added the comment:
Yes you can set the default to be any object, such as an evaluated string. If
it isn't a string it won't be passed through 'type'.
The purpose of the delayed evaluation that I described is to avoid unnecessary
evaluations. The worse c
Change by paul j3 :
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue38736>
___
___
Python-bugs-list
Change by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<https://bugs.python.org/issue38821>
___
___
Python-bugs-list mailing list
Unsubscribe:
paul j3 added the comment:
It doesn't have to be a special class. It can be a `argparse.Namespace` object.
If the preexisting namespace has an attribute set, the action default will not
over write it.
In [85]: parser = argparse.ArgumentParser()
...: parser.add_argument(&
paul j3 added the comment:
This related to an old issue
https://bugs.python.org/issue9694
argparse required arguments displayed under "optional arguments"
argparse defines two initial argument groups, titled 'positional arguments' and
'optional arguments'. Al
Change by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<https://bugs.python.org/issue39076>
___
___
Python-bugs-list mailing list
Unsubscribe:
paul j3 added the comment:
This patch changes the super class, _AttributeHolder. ArgumentParser and
Actions also inherit from this, though they have their own _get_kwargs methods,
and so aren't affected by the sort and its removal.
I just had occasion on stackoverflow to discuss the
paul j3 added the comment:
Despite the name, the 'type' parameter specifies a function, not a Python
class.
The only string that produces False is the empty one: bool(''). So 'type=bool'
is valid Python, even if it isn't useful.
With `nargs='+
paul j3 added the comment:
The rejected boolean type proposal:
https://bugs.python.org/issue37564
--
___
Python tracker
<https://bugs.python.org/issue39
paul j3 added the comment:
This is a complicated issue that needs a lot of thought and testing before we
make any changes.
While all Actions have the 'required' attribute, the programmer can only set it
for optionals. _get_positional_kwargs() will raise an error if the programmer
paul j3 added the comment:
The issue of testing a script that uses argparse has come up on StackOverFlow a
number of times.
As noted the unittesting framework(s) often use their own parsers (not
necessarily argparse). That means they are looking at the sys.argv
commandline. It is
paul j3 added the comment:
A mutually_exclusive_group is not an argument_group. It affects parsing and
the usage, but does nothing in the help lines.
A mutually_exclusive_group may be nested in an argument_group if you want
another group title.
g1 = parser.add_argument_group(&#x
paul j3 added the comment:
I don't think the SO question is relevant. It's about changing the order of
Actions in the Help and/or usage.
Here it's a question of whether to sort the `argparse.Namespace` display. I
think it's been adequately discussed in the recen
paul j3 added the comment:
https://bugs.python.org/issue9694
is the original issue about the titles of the base argument groups.
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bug
paul j3 added the comment:
https://bugs.python.org/issue13041
is (I think) the latest issue/patch to deal with the help width.
I don't like the idea of adding more parameters to the `ArgumentParser` class.
It's too complicated already.
There are a couple of ways that a user c
paul j3 added the comment:
But you can replace the simple 'lambda' with a function that takes the max with
'columns'. In other words, include:
width = _shutil.get_terminal_size().columns
width -= 2
width = min(max_text_width, wi
paul j3 added the comment:
Could you show the sys.argv (for both the linux and windows cases)?
print(args) (without your correction) might also help, just to see the 'raw'
Namespace.
(I'd have to restart my computer to explore the Windows
paul j3 added the comment:
Then this isn't an argparse issue. Probably not even a Python one. The
windows shell (which one? cmd.exe? power? some batch) is making the
substitution.
I see lots of discussion about Windows use of backslash, both as directory
separator and escape.
Change by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<https://bugs.python.org/issue39955>
___
___
Python-bugs-list mailing list
Unsubscribe:
paul j3 added the comment:
You are right, this part of the same issue.
_get_value() tests '==SUPPRESS==' both for type and choices.
--
___
Python tracker
<https://bugs.python.o
paul j3 added the comment:
I think it can be closed.
--
___
Python tracker
<https://bugs.python.org/issue19462>
___
___
Python-bugs-list mailing list
Unsub
paul j3 added the comment:
'type=bool' doesn't get any special treatment. 'bool' is a builtin Python
function.
test with
def mybool(astr):
print("mybool:", astr, len(astr), bool(astr))
return bool(astr)
The trick to getting a False
paul j3 added the comment:
This is a consequence of Python's own definition of append vs extend
In [730]: alist = []
In [731]: alist.append(&#x
paul j3 added the comment:
The display of the choices has been discussed in previous issues. When the
choices is long there isn't a clean way of handling the display.
I'd suggest using a 'metavar' to show a short value, and then enumerate the
choices in the help text.
Change by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<https://bugs.python.org/issue40509>
___
___
Python-bugs-list mailing list
Unsubscribe:
paul j3 added the comment:
Handling the positional with '?' and '*' in a mutually_exclusive_group is
tricky enough!
I believe your user can use the '--' to get the same effect.
--
___
Python tracker
<h
paul j3 added the comment:
Related topic re. long usage with choices : https://bugs.python.org/issue16418
--
___
Python tracker
<https://bugs.python.org/issue40
paul j3 added the comment:
A flagged argument with REMAINDER works just fine in a mutually exclusive group.
group.add_argument('-g', nargs='...')
positionals in such a group can only have ? or *. If you check the code, and
past issues you'll see that those requ
paul j3 added the comment:
choices is fine for a few strings, but quickly becomes awkward with other types
and large numbers. The testing isn't an issue, since it just does a simple
`in/contains` test. But display, whether in usage, help or error, is
problematic if you try anythin
paul j3 added the comment:
Duplicate of
https://bugs.python.org/issue14074
argparse allows nargs>1 for positional arguments but doesn't allow metavar to
be a tuple
--
resolution: -> duplicate
stage: patch review -> resolved
status:
paul j3 added the comment:
I'll reopen it - your patch, while not a complete resolution, does take care of
the immediate error.
--
resolution: duplicate ->
status: closed -> open
___
Python tracker
<https://bugs.python.
paul j3 added the comment:
What exactly do you do with a path argument?
Admittedly I'm not expert with os and os.path modules, but isn't a path just a
string passed to a function such as cwd(), or joined to another create a
filename.
I don't know what a 'path'
paul j3 added the comment:
The pathlib.Path is new since I paid much attention to os matters (I cut my
teeth on py2.5).
Off hand it looks like the user could
import pathlib
parser.add_argument('-p', type=pathlib.Path)
to convert a string into a Path object.
A custom typ
1 - 100 of 778 matches
Mail list logo
