[issue16468] argparse only supports iterable choices
Brendan Barnwell added the comment: Here is an example of someone who cares about the behavior and/or the documentation (and still cares enough to check up on their StackOverflow question six years later): https://stackoverflow.com/questions/13833566/python-argparse-choices-from-an-infinite-set/13833736 . The issue is not the use of the word "container". The docs literally say "Any object that supports the `in` operator can be passed as the choices value" and that is not true. In fact, changing it to say "any container type" would be an improvement as that is at least arguably correct, whereas the current documentation is unambiguously incorrect. -- versions: -Python 3.9 ___ Python tracker <https://bugs.python.org/issue16468> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16468] argparse only supports iterable choices
Brendan Barnwell added the comment: This issue has sat idle for six years. Meanwhile, the docs are still incorrect, giving every user wrong information about how the module works. Can we consider just changing the documentation instead of worrying about what the behavior should be or what the rationale is? -- ___ Python tracker <https://bugs.python.org/issue16468> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16697] argparse kwarg 'choices' documentation
Brendan Barnwell added the comment: This issue has sat idle for six years. Meanwhile, the docs are still incorrect, giving every user wrong information about how the module works. Can we consider just changing the documentation instead of worrying about what the behavior should be or what the rationale is? -- nosy: +BrenBarn versions: +Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <https://bugs.python.org/issue16697> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16468] argparse only supports iterable choices
Brendan Barnwell added the comment: https://bugs.python.org/issue16468 -- nosy: +BrenBarn versions: +Python 3.7 ___ Python tracker <https://bugs.python.org/issue16468> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16701] Docs missing the behavior of += (in-place add) for lists.
Brendan Barnwell added the comment: This needs to be fixed. The documentation for the behavior of += on lists needs to be with the documentation on lists. The existing, vague documentation that += works in-place "when possible" is insufficient. A central feature of Python is that the behavior of operators like + and += is overridable on a per-type basis. Hence, the Language Reference is not the appropriate place for describing the behavior of += on a particular type. The behavior of += on lists should be documented where the behavior of lists is documented (as, for instance, the behavior of + on lists already is), not where the syntax of += is documented. Someone just asked a question on StackOverflow about this (http://stackoverflow.com/questions/32657637/python-changing-variables-vs-arrays-in-functions/32657770#32657770). It is embarrassing to have to tell people, "To know what += does on a type, you need to look at the documentation for that type. . . except that the documentation for the builtin types doesn't document what some operators do." -- nosy: +BrenBarn ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue16701> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24890] Windows launcher docs don't fully explain shebang semantics
New submission from Brendan Barnwell: With the fix of issue #17903 in place, the behavior of the Windows launcher for a shebang of #!/usr/bin/env python is now different from the behavior for the other virtual commands in that the PATH is searched for this particular virtual command but not the others. But this difference is not explained in the docs (see https://docs.python.org/3/using/windows.html#shebang-lines). The docs should be updated to make the difference clear. In addition, as noted in bug #24625, the launcher parses and executes shebang lines normally if the shebang is not one of the virtual commands. However, this is not actually stated on the documentation page; the only examples on the page either use the virtual commands or use a bare command like python. Given that shebang lines don't normally work at all on Windows, and given that the shebang handling is already different on Windows because of the virtual commands, the docs shouldn't assume that it's clear what works like a normal shebang means. A note should be added to the docs to make this explicit. Something like If the shebang line is not one of these virtual commands, it is executed as a normal program and the script filename is passed to it as a command-line argument. -- components: Windows messages: 248796 nosy: BrenBarn, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Windows launcher docs don't fully explain shebang semantics type: behavior versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24890 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
