[issue38217] argparse should support multiple types when nargs > 1
New submission from Ryan Govostes :
argparse supports consuming multiple command-line arguments with nargs=2, etc.
It converts them to the type given in the argument's type parameter.
argparse does not provide a good solution when the input arguments should be
different data types. For an example, you cannot have an argument that expects
a str followed by an int, '--set-age Bob 34'.
Ordinarily, the suggestion would be to split it into two arguments, like
'--set-person Bob --set-age 34'.
However, this becomes awkward with an action such as 'append', where the
command line arguments become tedious, like '--set-person Bob --set-age 34
--set-person Alice --set-age 29', or confusing, as in '--set-person Bob
--set-person Alice --set-age 34 --set-age 29'.
My proposal is to allow the 'type' parameter to accept a tuple of types:
p.add_argument('--set-age', nargs=2, type=(str, int))
Since 'nargs' is redundant, this could even be simplified to just:
p.add_argument('--set-age', type=(str, int))
The resulting parsed argument would then be a tuple of (str, int), as opposed
to a list. If action='append', the result would be a list of such tuples.
This creates no backwards compatibility issue because tuple instances are not
callable, so this was never valid code that did something else.
A further enhancement could be that when nargs='+' or '*', and a tuple of types
is provided, the types are used round robin: '--set-ages Bob 34 Alice 29'. An
exception would be raised if it would create an incomplete tuple.
See here for other discussion and workarounds:
https://stackoverflow.com/questions/16959101/python-argparse-how-to-have-nargs-2-with-type-str-and-type-int
--
components: Library (Lib)
messages: 352741
nosy: rgov
priority: normal
severity: normal
status: open
title: argparse should support multiple types when nargs > 1
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue38217>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38595] io.BufferedRWPair doc warning may need clarification
New submission from Ryan Govostes : The documentation for the io.BufferedRWPair class gives this warning: > BufferedRWPair does not attempt to synchronize accesses to its underlying raw > streams. You should not pass it the same object as reader and writer; use > BufferedRandom instead. I have a hard time understanding what this warning is trying to tell me. 1. What does it mean to "synchronize accesses"? 2. Why can't I pass the same object as reader and writer? The docstring in _pyio.py says, "This is typically used with a socket or two-way pipe." 3. How does BufferedRandom, which adds the seek() and tell() interfaces, address the issue of "synchroniz[ing] accesses"? Is synchronization automatic? What does this do for sockets or pipes which cannot seek? -- assignee: docs@python components: Documentation messages: 355404 nosy: docs@python, rgov priority: normal severity: normal status: open title: io.BufferedRWPair doc warning may need clarification type: behavior versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue38595> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38595] io.BufferedRWPair doc warning may need clarification
Ryan Govostes added the comment: The origin of this warning involves interleaving read and write operations, and was added here: https://bugs.python.org/issue12213 I'm not sure if it applies to sockets, pipes, etc. though. The pySerial documentation advises using io.BufferedRWPair(x, x) where x is a serial device. But this StackOverflow post reports that it is problematic, in line with the warning. (The author appears to be talking about Windows.) https://stackoverflow.com/questions/24498048/python-io-modules-textiowrapper-or-buffererwpair-functions-are-not-playing-nice -- nosy: +benjamin.peterson, pitrou, stutzbach ___ Python tracker <https://bugs.python.org/issue38595> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20126] sched doesn't handle events added after scheduler starts
Ryan Govostes added the comment: This absolutely should be documented. If adding an earlier event is not supported then it should raise an exception. Appearing the enqueue the event but not triggering the callback is especially confusing. It may be obvious behavior to someone who has spent time developing this module or working with it but not to someone who just wants to, e.g., build an alarm clock or calendar app. -- nosy: +rgov ___ Python tracker <https://bugs.python.org/issue20126> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42542] weakref documentation does not fully describe proxies
New submission from Ryan Govostes : The documentation for weakref.proxy() does not describe how the proxy object behaves when the object it references is gone. The apparent behavior is that it raises a ReferenceError when an attribute of the proxy object is accessed. It would probably be a good idea to describe what the proxy object does in general, for those who are unfamiliar with the concept: attribute accesses on the proxy object are forwarded to the referenced object, if it exists. -- assignee: docs@python components: Documentation messages: 382319 nosy: docs@python, rgov priority: normal severity: normal status: open title: weakref documentation does not fully describe proxies versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue42542> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35495] argparse does not honor default argument for nargs=argparse.REMAINDER argument
Ryan Govostes added the comment: Thanks Michael for all of the examples. After reading them all, I concur that "it can be hard to conceptualize what the exact behavior should be." A documentation change is warranted, at the least. However the argparse documentation, while great, is dense and it would be easy to overlook a simple comment. And I think the point that is being raised isn't merely a suggestion on how to design a good CLI, but a pitfall that makes the behavior of code non-obvious---it's not something someone would necessarily consult the documentation for while reviewing code. (By the way, I'm considering CLIs like `docker run` and `ssh` which take an optional command to execute, and when absent, fall back on default behavior.) So I would prefer a code change that makes it harder to write code that hits this corner case. Potential solutions would be either (a) making a positional REMAINDER arg with a default value an error, as in Paul's proposed change; or (b) making a default value with a positional REMAINDER arg 'just work' I think (a) is the most reasonable. The exception can recommend the use of nargs='*' instead, which makes it actionable. And it is unlikely that the exception would be buried down some untested code path that would end up in released code. (Perhaps it's also worth raising an exception when adding a positional argument after a nargs>1 positional argument already exists, but that's another issue.) -- ___ Python tracker <https://bugs.python.org/issue35495> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35495] argparse does not honor default argument for nargs=argparse.REMAINDER argument
New submission from Ryan Govostes :
import argparse
parser = argparse.ArgumentParser()
parser.add_argument('things', nargs=argparse.REMAINDER, default=['nothing'])
parser.parse_args([])
>>> Namespace(things=[])
Since there were no unparsed arguments remaining, the `default` setting for
`things` should have been honored. However it silently ignores this setting.
If there's a reason why this wouldn't be desirable, it should raise an
exception that the options aren't compatible.
--
components: Library (Lib)
messages: 331837
nosy: rgov
priority: normal
severity: normal
status: open
title: argparse does not honor default argument for nargs=argparse.REMAINDER
argument
type: behavior
___
Python tracker
<https://bugs.python.org/issue35495>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35495] argparse does not honor default argument for nargs=argparse.REMAINDER argument
Change by Ryan Govostes : -- versions: +Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <https://bugs.python.org/issue35495> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35495] argparse does not honor default argument for nargs=argparse.REMAINDER argument
Ryan Govostes added the comment:
Just don’t run the last line which is just an echoing of the output of
parser.parse_args() repeated. The Namespace type would need to be imported
if you really wanted to but there’s no point.
On Tuesday, May 7, 2019, Michael Blahay wrote:
>
> Michael Blahay added the comment:
>
> Ryan, what are the exact steps to reproduce the problem? This is what I
> get when I run the code you included:
>
> >>> import argparse
> >>> parser = argparse.ArgumentParser()
> >>> parser.add_argument('things', nargs=argparse.REMAINDER,
> default=['nothing'])
> _StoreAction(option_strings=[], dest='things', nargs='...', const=None,
> default=['nothing'], type=None, choices=None, help=None, metavar=None)
> >>> parser.parse_args([])
> Namespace(things=[])
> >>> Namespace(things=[])
> Traceback (most recent call last):
> File "", line 1, in
> NameError: name 'Namespace' is not defined
>
> --
> nosy: +mblahay
>
> ___
> Python tracker
> <https://bugs.python.org/issue35495>
> ___
>
--
___
Python tracker
<https://bugs.python.org/issue35495>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32347] System Integrity Protection breaks shutil.copystat()
New submission from Ryan Govostes : On macOS, shutil.copystat() uses chflags() to try to copy filesystem flags from the source to destination. In recent years, Apple introduced System Integrity Protection, which prevents modification of system files. These files have the non-standard SF_RESTRICTED flag set, which only the superuser can set. Thus, unprivileged users can no longer use shutil.copy2() et al. to copy system files, which is a regression from previous releases of the OS. It's unclear what the correct behavior should be: It some cases, it would be desirable to attempt to copy the bit. It might be informative to look at the behavior of Apple's `copyfile_stat` function, which unsets these two flags: /* * File flags that are not preserved when copying stat information. */ #define COPYFILE_OMIT_FLAGS (UF_TRACKED | SF_RESTRICTED) https://opensource.apple.com/source/copyfile/copyfile-146/copyfile.c.auto.html This was also filed to Apple as rdar://36090921 -- components: macOS messages: 308479 nosy: Ryan Govostes, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: System Integrity Protection breaks shutil.copystat() type: behavior versions: Python 3.6 ___ Python tracker <https://bugs.python.org/issue32347> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32347] System Integrity Protection breaks shutil.copystat()
Change by Ryan Govostes : -- keywords: +patch pull_requests: +4806 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue32347> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20821] Should be able to break long numbers across lines
New submission from Ryan Govostes: I cannot find a way to break a long number across multiple lines, other than to write the number as a string, take advantage of string literal concatenation, and then convert the string to an integer. I'd like to be able to write, for example, N = 17976931348623159077293051907890247336179769789423065727343008115 \ 77326758055056206869853794492129829595855013875371640157101398586 \ 47833778606925583497541085196591615128057575940752635007475935288 \ 71082364994994077189561705436114947486504671101510156394068052754 \ 0071584560878577663743040086340742855278549092581 To support this, adjacent integer literals should be concatenated also. I don't think this would introduce any backwards-compatibility issues. My preference would be to require each literal be written with its prefix, e.g., '0xDEAD 0xBEEF'. It strikes me as poor style to mix different bases, e.g., '0xa 5'. -- components: Interpreter Core messages: 212533 nosy: rgov priority: normal severity: normal status: open title: Should be able to break long numbers across lines type: enhancement versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue20821> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
