[issue46335] asyncio.create_subprocess_exec throws RuntimeError yet still executes subprogram

Clint Olsen added the comment: Yes, I tried FastChildWatcher and I've had much better luck with that. If any exception gets thrown we _know_ for certain that the process wasn't created. -- ___ Python tracker <https://bugs.python.org/issue46

[issue46335] asyncio.create_subprocess_exec throws RuntimeError yet still executes subprogram

Clint Olsen added the comment: In a multi-user environment, you should not expect to be able to spawn infinite processes. In some cases system administrators have reduced the thresholds to values that guarantee a machine is still responsive under heavy load. See limits.conf(5) as an example

[issue46335] asyncio.create_subprocess_exec throws RuntimeError yet still executes subprogram

New submission from Clint Olsen : When stress testing my code in a process-limited environment I found that despite throwing an exception, it appears the process still executes. Attempting to catch/retry results in a duplicate. Attached is a script that I was able to repro the problem

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

Clint Olsen added the comment: I think this should serve as a cautionary tale that while (POSIX) standards aren't always the best of solutions, they are often made for good reasons, and special care should be taken when you decide to deviate from them. Otherwise it just causes frustration

[issue43192] Argparse complains argument required when default is provided

Clint Olsen added the comment: I think your original suggestion makes sense: '?' My intuition is that nargs helps argparse discern whether it's dealing with single or multiple values. That may not be what was intended. There probably shouldn't be multiple ways of indicating an argument

[issue43192] Argparse complains argument required when default is provided

Clint Olsen added the comment: Do you think it's unreasonable/unintuitive to infer nargs from the default value? -- ___ Python tracker <https://bugs.python.org/issue43

[issue43192] Argparse complains argument required when default is provided

Clint Olsen added the comment: Sorry, I meant to say args.foo should be 'bar'. -- ___ Python tracker <https://bugs.python.org/issue43192> ___ ___ Python-bug

[issue43192] Argparse complains argument required when default is provided

New submission from Clint Olsen : When I run the following program, I expect args.run to be 'foo' if no argument is specified on the command-line. parser = argparse.ArgumentParser() parser.add_argument('foo', default='bar') args = parser.parse_args() $ ./test usage: test [-h] foo test

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

Clint Olsen added the comment: Thanks for the suggestion! It seems to be extremely limited, unfortunately. I don't want option processing to cease once I hit this switch. p=argparse.ArgumentParser() p.add_argument('--subscipt_args', nargs='...') #p.add_argument('pos',nargs='*') p.add_argument

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

Clint Olsen added the comment: I'm not sure if this is applicable to this bug, but one feature missing from argparse is the ability to snarf arbitrary options up to a terminating '--'. The purpose of this is to collect arguments for potential children you may spawn. An example