[issue43942] RawDescriptionHelpFormatter seems to be ignored for argument descriptions
Reuben Thomas added the comment: D'oh! Sorry for the noise. And congratulations to the author/designer of `RawDescriptionHelpFormatter` for designing/implementing exactly what I wanted all along! -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue43942> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43942] RawDescriptionHelpFormatter seems to be ignored for argument descriptions
Reuben Thomas added the comment: (Tested with Python 3.9.4.) -- ___ Python tracker <https://bugs.python.org/issue43942> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43942] RawDescriptionHelpFormatter seems to be ignored for argument descriptions
New submission from Reuben Thomas : The documentation seems very clear on this subject: "RawTextHelpFormatter maintains whitespace for all sorts of help text, including argument descriptions. However, multiple new lines are replaced with one." But consider the following code: ``` from argparse import ArgumentParser, RawDescriptionHelpFormatter parser = ArgumentParser( description='A simple templating system.', epilog='Use `-\' as a file name to indicate standard input or output.', formatter_class=RawDescriptionHelpFormatter, ) parser.add_argument( '--verbose', help='show on standard error the path being built,\nand the names of files built, included and pasted' ) args = parser.parse_args() ``` Then try running it in a suitably-sized terminal: $ python3 test.py --help usage: test.py [-h] [--verbose VERBOSE] A simple templating system. optional arguments: -h, --help show this help message and exit --verbose VERBOSE show on standard error the path being built, and the names of files built, included and pasted Use `-' as a file name to indicate standard input or output. ``` The \n in the help for the `--verbose` argument is not respected. -- components: Library (Lib) messages: 391890 nosy: rrt priority: normal severity: normal status: open title: RawDescriptionHelpFormatter seems to be ignored for argument descriptions versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue43942> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43875] glob.glob with ** does not always detect symlink loops
Change by Reuben Thomas : -- title: path.glob with ** does not always detect symlink loops -> glob.glob with ** does not always detect symlink loops ___ Python tracker <https://bugs.python.org/issue43875> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43875] path.glob with ** does not always detect symlink loops
Change by Reuben Thomas : -- components: +Library (Lib) versions: +Python 3.9 ___ Python tracker <https://bugs.python.org/issue43875> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43875] path.glob with ** does not always detect symlink loops
New submission from Reuben Thomas :
Example session:
$ mkdir foo
$ cd foo
$ ln -s .. bar
$ ln -s .. baz
$ python3.9
Python 3.9.0+ (default, Oct 20 2020, 08:43:38)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from glob import glob
>>> glob('**/README', recursive=True)
[HANG]
Removing either of the symlinks fixes the hang.
--
messages: 391253
nosy: rrt
priority: normal
severity: normal
status: open
title: path.glob with ** does not always detect symlink loops
___
Python tracker
<https://bugs.python.org/issue43875>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41854] argparse.add_mutually_exclusive_group fails for optional positional arguments
Reuben Thomas added the comment: Thanks for the hint; could this be documented, please? -- ___ Python tracker <https://bugs.python.org/issue41854> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41856] argparse: auto-generated synopsis omits REMAINDER argument
Reuben Thomas added the comment:
A workaround to help users for now is:
>>> parser.add_argument('args', metavar='...', nargs=argparse.REMAINDER)
as then at least the help entry corresponds to the synopsis:
positional arguments:
command
...
And with a `help` string, this can be clarified further, e.g.:
>>> parser.add_argument('args', metavar='...', nargs=argparse.REMAINDER,
>>> help='arguments to the command')
--
___
Python tracker
<https://bugs.python.org/issue41856>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41856] argparse: auto-generated synopsis omits REMAINDER argument
New submission from Reuben Thomas :
Consider the following example from the Python documentation:
>>> parser = argparse.ArgumentParser(prog='PROG')
>>> parser.add_argument('--foo')
>>> parser.add_argument('command')
>>> parser.add_argument('args', nargs=argparse.REMAINDER)
Now show the help:
>>> parser.parse_args(['-h'])
This prints:
usage: PROG [-h] [--foo FOO] command ...
positional arguments:
command
args
Note that "args" is not shown in the synopsis. I suggest that the synopsis
should instead say:
usage: PROG [-h] [--foo FOO] command args...
--
components: Library (Lib)
messages: 377469
nosy: rrt
priority: normal
severity: normal
status: open
title: argparse: auto-generated synopsis omits REMAINDER argument
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue41856>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41854] argparse.add_mutually_exclusive_group fails for optional positional arguments
New submission from Reuben Thomas :
The following code:
group = parser.add_mutually_exclusive_group()
group.add_argument('--install-only', action='store_true',
help='just install the program, do not run it')
group.add_argument('args', metavar='ARGUMENT', nargs='*', default=None,
help='arguments to PROGRAM')
gives the following error:
group.add_argument('args', metavar='ARGUMENT', nargs='*',
File "/usr/lib/python3.8/argparse.py", line 1398, in add_argument
return self._add_action(action)
File "/usr/lib/python3.8/argparse.py", line 1621, in _add_action
raise ValueError(msg)
ValueError: mutually exclusive arguments must be optional
But the 'args' argument *is* optional, as there can be 0 of them.
--
components: Library (Lib)
messages: 377460
nosy: rrt
priority: normal
severity: normal
status: open
title: argparse.add_mutually_exclusive_group fails for optional positional
arguments
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue41854>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37062] `AutoNumber` class in enum documentation: support *args in constructor
Reuben Thomas added the comment: That's the one I was thinking of: the example in the docs. -- ___ Python tracker <https://bugs.python.org/issue37062> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37571] Incorrect use of c_char_p in example code
New submission from Reuben Thomas : The CTypes documentation has this example: >>> s = c_char_p() >>> s.value = "abc def ghi" >>> s.value 'abc def ghi' >>> s.value is s.value False >>> It appears not to have been updated since Python 2: in Python 3, you can't assign a str to a c_char_p. If one tries the example code above, one gets: >>> s = c_char_p() >>> s.value = "abc def ghi" Traceback (most recent call last): File "", line 1, in TypeError: bytes or integer address expected instead of str instance Using a bytes works: >>> s = c_char_p() >>> s.value = b"abc def ghi" >>> s.value b'abc def ghi' >>> s.value is s.value False >>> Hence adding the two "b"s is an obvious fix. Note that the similar example with c_wchar_p does work fine with str. -- assignee: docs@python components: Documentation messages: 347725 nosy: docs@python, rrt priority: normal severity: normal status: open title: Incorrect use of c_char_p in example code versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue37571> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37062] `AutoNumber` class in enum documentation: support *args in constructor
Reuben Thomas added the comment: Just to be clear, the proposed change to the documentation is simply to add ", *args" to the argument list of AutoNumber.__new__. -- ___ Python tracker <https://bugs.python.org/issue37062> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37062] `AutoNumber` class in enum documentation: support *args in constructor
New submission from Reuben Thomas :
By changing one line of AutoNumber:
def __new__(cls):
to
def __new__(cls, *args):
Enums derived from AutoNumber can now support constructors that take named
arguments; for example:
class Color(AutoNumber):
def __init__(self, pantone=None):
self.pantone = pantone or 'unknown'
class Swatch(Color):
AUBURN = ('3497')
SEA_GREEN = ('1246')
BLEACHED_CORAL = () # New color, no Pantone code yet!
Without the change, one gets the error:
TypeError: __new__() takes 1 positional argument but 2 were given
I attach runnable demonstration code.
--
assignee: docs@python
components: Documentation
files: foo.py
messages: 343607
nosy: docs@python, rrt
priority: normal
severity: normal
status: open
title: `AutoNumber` class in enum documentation: support *args in constructor
versions: Python 3.8
Added file: https://bugs.python.org/file48365/foo.py
___
Python tracker
<https://bugs.python.org/issue37062>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36799] Typo in ctypes documentation
Reuben Thomas added the comment: No, as I'm not an active Python contributor, do not aspire to be one, and don't really want to have to learn yet another contribution system to a major project just to fix a trivial typo. Sorry! -- ___ Python tracker <https://bugs.python.org/issue36799> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36799] Typo in ctypes documentation
New submission from Reuben Thomas : "It is possible to defined" → "It is possible to define" -- assignee: docs@python components: Documentation messages: 341419 nosy: docs@python, rrt priority: normal severity: normal status: open title: Typo in ctypes documentation versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue36799> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32666] Valgrind documentation seems to need updating
Reuben Thomas added the comment: Victor, thanks; that's precisely the sort of thing that would make a useful addition to the docs. -- ___ Python tracker <https://bugs.python.org/issue32666> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32666] Valgrind documentation seems to need updating
New submission from Reuben Thomas :
I have just been trying to use Valgrind (in my case, to debug code in a library
being tested via a Cython module).
It is working fine, but there seem to be some discrepancies between the
documentation in README.valgrind and valgrind-python.supp on the one hand, and
the actual code on the other.
README.Valgrind says (current git master):
Second, you must do one of the following:
* Uncomment Py_USING_MEMORY_DEBUGGER in Objects/obmalloc.c,
then rebuild Python
* Uncomment the lines in Misc/valgrind-python.supp that
suppress the warnings for PyObject_Free and PyObject_Realloc
However, Objects/objmalloc.c no longer contain this symbol (though
Python/dtoa.c does).
Further, in https://bugs.python.org/issue31494 I find the following comment:
Also, I don't think --with-pydebug works well with valgrind.
It's either:
1) --with-pydebug
2) CFLAGS="-O0 -g" --with-valgrind
3) CFLAGS="-O0 -g" --without-pymalloc
Combining 2) and 3) probably does not hurt, but is not necessary.
It would be useful to have this information in README.valgrind.
Also, the provided suppressions do not currently work with a normal build of
Python, at least with Python 2.7 (with the PyObject_{Free,Realloc} suppressions
uncommented). There seem to be at least two problems:
1. Extra symbols from LTO. This can be fixed by adding "*" to PyObject_Realloc
in all its suppressions.
2. After fixing that, I still get one more "Invalid read of size 4":
==3227== Invalid read of size 4
==3227==at 0x4FCEE2: long_dealloc.lto_priv.323 (abstract.c:2000)
==3227==by 0x4BA22B: frame_dealloc (frameobject.c:458)
==3227==by 0x4BA22B: PyEval_EvalCodeEx (ceval.c:3593)
==3227==by 0x4C16E6: fast_function (ceval.c:4445)
==3227==by 0x4C16E6: call_function (ceval.c:4370)
I can't see how this is related to any existing suppression.
I am using the stock Python 2.7 on Ubuntu 16.04. I find that I can work around
both the above problems (that is, use the suppressions file as-is, just
uncommenting the extra suppressions for PyObject_{Free,Realloc}) by using
Ubuntu's debug build of Python (installed as /usr/bin/python-dbg). It is built
with --with-pydebug.
Finally, README.valgrind says: "Valgrind is used periodically by Python
developers to try to ensure there are no memory leaks or invalid memory
reads/writes." Another reason to use Valgrind is, as in my case, to debug
unrelated C code that is being run via Python (this is often a convenient way
to write tests). I suggest deleting this sentence and making it more obvious
how to simply make Python "transparent to Valgrind" for those trying to debug C
libraries.
To summarise:
i. It seems that for current Python 3, this text:
* Uncomment Py_USING_MEMORY_DEBUGGER in Objects/obmalloc.c,
then rebuild Python
needs to be updated.
ii. For Python 2.7 at least, and possibly Python 3, extra suppressions are
needed to use a standard build.
iii. It would be good to have the specific build advice from
https://bugs.python.org/issue31494 in README.valgrind.
iv. It would be nice to clarify how to use a normal build of Python (e.g. by
splitting the advice into "For Python developers" and "For Python users").
Given some guidance on what is correct, and what is desired/acceptable, I'd be
happy to work up a patch to README.valgrind and valgrind-python.supp.
--
assignee: docs@python
components: Documentation
messages: 310673
nosy: docs@python, rrt
priority: normal
severity: normal
status: open
title: Valgrind documentation seems to need updating
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue32666>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28609] argparse claims '*' positional argument is required in error output
Reuben Thomas added the comment: Thanks, that's a simple, robust workaround. I'll duck out now and leave the Python experts to sort out the underlying problem, if they can; I think it's still well worth sorting out, though documenting the problem and workaround would be much better than nothing. -- ___ Python tracker <http://bugs.python.org/issue28609> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28609] argparse claims '*' positional argument is required in error output
Reuben Thomas added the comment: > Try `nargs='?'` or try providing a `default` along with the '*'. Why would I do that? I want 0 or more arguments, and there's no default value. > Including your ARGUMENT action in the error message is intentional. It will likely confuse the user. The syntax message says that it's optional, the error suggests (wrongly) that it is required. Patching the Python documentation will not help in this case, because the user of my program will not be reading the Python documentation to understand how it works, only the program's own documentation. Note that I did not suggest that the behavior be changed, only the message that is output. The analysis of why the message is output is useful, but it does not demonstrate that the error message is correct; the error message, as I've already demonstrated, is undeniably wrong. In no sense is "ARGUMENT" missing, because 0 occurrences are entirely legal. Therefore although in terms of the API the argument is "required", it makes no sense to tell the user this (the user will assume that "required" has its colloquial sense, not a technical sense). I entirely sympathise with the argument that the behavior of argparse should not change; I see nothing wrong with the behavior, in any case. The problems are purely cosmetic: 1. The syntax message says, redundantly and confusingly, "[ARGUMENT [ARGUMENT ...]]" where it should say just "[ARGUMENT ...]". 2. The error message says that ARGUMENT is "required", whereas, from the user's point of view, it clearly is not. These are serious annoyances from the developer's point of view (in this case, from my point of view), because they mean that in order to release a production-quality tool, I have to hack around argparse's shortcomings. So in fact, you're quite right that the documentation should be fixed; only in this case it is the documentation generated by argparse, not the documentation of argparse (which, again, is fine as far as I can see). -- ___ Python tracker <http://bugs.python.org/issue28609> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28609] argparse claims '*' positional argument is required in error output
Reuben Thomas added the comment: Thanks very much for this. It would be great if the redundancy I referred to in the usage message could also be removed, so that instead of "[ARGUMENT [ARGUMENT ...]]" it just said "[ARGUMENT ...]". (Similarly, for a '+' argument, it could say just ARGUMENT ... ) -- ___ Python tracker <http://bugs.python.org/issue28609> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28609] argparse claims '*' positional argument is required in error output
New submission from Reuben Thomas:
In Python 3.5.2, with a positional argument with nargs='*', running the program
with no arguments gives an error like this:
usage: caffeinate [-h] [-V] COMMAND [ARGUMENT [ARGUMENT ...]]
caffeinate: error: the following arguments are required: COMMAND, ARGUMENT
Here it is clear from the (correct, though redundant) syntax that "ARGUMENT" is
optional, but the error message claims, incorrectly, that it is required.
The add_argument calls used were:
parser.add_argument('COMMAND', help='command to run')
parser.add_argument('ARGUMENT', nargs='*', help='arguments to COMMAND')
parser.add_argument('-V', '--version', action='version', version=PROGRAM_NAME +
' ' + VERSION)
--
components: Library (Lib)
messages: 280052
nosy: rrt
priority: normal
severity: normal
status: open
title: argparse claims '*' positional argument is required in error output
type: behavior
versions: Python 3.5
___
Python tracker
<http://bugs.python.org/issue28609>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
