telmich added the comment:
Victor, the problem is *not* that python exits. This is fine and virtually
every other unix program behaves like that.
The problem is that python throws an ugly-to-read and completly senseless
backtrace to the novice (end!) user by default. Backtraces are great
New submission from telmich:
When using argparse and the string \$ occurs on the commandline, it is
converted to $. This as definitely wrong and renders argparse useless, if the
input needs to be trusted (i.e. defitinely the same as given into it)'
Example code:
import sys
import argparse
Changes by telmich nico-bugs.python@schottelius.org:
--
title: argparse replaces \$ to is passed - argparse replaces \$ with $ (if in
commandline)
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19430
telmich added the comment:
Background information:
cdist is written in python 3 and makes heavy use of argparse.
One common task is to run a cdist type with some arguments, which
in the end configure a remote system.
We triggered the bug by running
__line ps1 --file /etc/bash.bashrc --line
telmich added the comment:
sorry for the noise, it was too early in the morning!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19430
telmich added the comment:
Anyone alive at bugs.python.org?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16308
___
___
Python-bugs-list
telmich added the comment:
I created two diffs to solve the problem:
a) a static late init of the signal handler
b) configurable late init (using python -z)
Both apply against latest mercurial code:
[15:20] brief:cpython% ./python -V
Python 3.4.0a0
[15:20] brief:cpython% ./python -h | grep
telmich added the comment:
+ parameter -z based change of behaviour
--
Added file:
http://bugs.python.org/file27925/init_sigs_after_site_parameter_z.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14228
telmich added the comment:
And sorry for the long delay...
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14228
___
___
Python-bugs-list mailing
telmich added the comment:
Any news on this one?
If the proposed changes are ok for you, I'd implement two patches:
- fix set_defaults() to not propagate func= to child parsers = makes it usable
- add required= argument to add_subparsers, defaulting to False
New submission from telmich:
Using argparse with subparsers, the default behaviour if no subparser was
selected, was to print help:
cdist% git describe
2.0.14-59-g5315c41
cdist% ./bin/cdist
usage: cdist [-h] [-d] [-v] [-V] {banner,config} ...
cdist: error: too few arguments
cdist% python3 -V
telmich added the comment:
Having a closer look at the changes using hg diff -r v3.2:v3.3.0
Lib/argparse.py, it seems the following removal could be related to the
different behaviour:
-# if we didn't use all the Positional objects, there were too few
-# arg strings supplied
telmich added the comment:
Thanks a lot - let me know when I can help more.
After re-reading the documentation, I think the behaviour for subparsers is not
specified: It is not specified, whether a subparser is required to be present
or not.
Attached stripped down version of the cdist code
telmich added the comment:
I've copy pasted the example from the documentation and added the following
lines to it (attached full file)
args = parser.parse_args('')
args.func(args)
Following the style / way show in the documentation, I'd expect this block to
work (3.2.2 behaviour). I do
telmich added the comment:
Assuming 3.3.0 behaviour is correct (as in no subparser specified, args.func
not setup), I'd expect to have setup a function on the main parser. Trying
this, it prevents the subparsers function from being completly:
[16:03] brief:~% python3 subparse3.py
telmich added the comment:
Proposal / resume from the previous tests:
- add a parameter to add_subparsers(): required
If required=True, one of the subcommand names need to be present.
If required=False (default), allow parse_args() to return successfully, if
no subcommand is given
telmich added the comment:
Interesting! The issue 9523 has now somehow become obsolete,
as in 3.3.0 subcommands are de-facto optional, which is the problem I am facing.
Regarding my last comment, here are the relations:
- add a parameter to add_subparsers(): required
This is a similar
telmich added the comment:
s/9523/9253/g in my previous post
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16308
___
___
Python-bugs-list
telmich nico-bugs.python@schottelius.org added the comment:
Hello François,
I'm confused about your statement: You prefer to throw random and useless error
messages to users who are using python instead of doing a clean shutdown like
every other application by default?
Don't be offended
telmich nico-bugs.python@schottelius.org added the comment:
Antoine,
let me explain again: I do not say, python should not print uncaught exceptions.
My point here is that an exception is thrown, which is not catchable at all and
this results in random and misleading errors.
I really
telmich nico-bugs.python@schottelius.org added the comment:
It seems not even using -S fixes the problem:
[16:25] brief:python-traceback-test% head -n 2 caller.py
#!/usr/bin/python3 -S
[16:25] brief:python-traceback-test% ./caller.py
Indirect child being called
Indirect child being
telmich nico-bugs.python@schottelius.org added the comment:
I think setting up SIGINT after importing site is a good solution: It will kill
the program as expected and as soon as the user takes over control, she can
decide what todo.
In which stage/part is the python interpreter when
I
telmich nico-bugs.python@schottelius.org added the comment:
Oh yes, you are right. Sorry for the confusion.
When modifying caller.py to only print(), everything works.
But then I've a different problem: If I want to exit(1),
in case I get a SIGINT, I'd like to try to import sys. But trying
telmich nico-bugs.python@schottelius.org added the comment:
Dear Charles-François,
for everybody who is not *programming* python (imagine there is a *real* user)
the tracebacks are useless. Even worse, because the error messages are
*changing*, because of different library parts
telmich nico-bugs.python@schottelius.org added the comment:
The problem is *NOT* in the parent: The problem is in the *CHILD* that is being
called from the shell that is throwing a traceback, which I cannot prevent in
the python code.
Please run the script yourself and try to get around
telmich nico-bugs.python@schottelius.org added the comment:
You are right, there is no different behaviour as parent or child in general.
I used this example python = shell = python, because it is actually being
used like this in cdist (first link in the first post).
The problem arises
New submission from telmich nico-bugs.python@schottelius.org:
Hello,
pressing ctrl-c or having sigint delivered to the python process in its startup
phase results in random tracebacks displayed.
This is related to issue3137, but actually happening in Python 3.2.2 on
archlinux.
We
telmich nico-bugs.python@schottelius.org added the comment:
And here's the actual python code
--
Added file: http://bugs.python.org/file24756/caller.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14228
telmich nico-bugs.python@schottelius.org added the comment:
This does not change a thing:
Indirect child being called
^CTraceback (most recent call last):
File /usr/lib/python3.2/functools.py, line 176, in wrapper
caught signint in parent
result = cache[key]
KeyError: (class 'str
telmich nico-bugs.python@schottelius.org added the comment:
Regarding feature request: I think this is a *bug*, not a feature request:
For me, it is impossible to handle SIGINT correctly with my code, because it is
half-handled (exception raised, but impossible to catch) by python itself
New submission from telmich nico-bugs.python@schottelius.org:
I've this class:
class Path:
Class that handles path related configurations
def __init__(self,
target_host,
remote_user,
remote_prefix,
initial_manifest
31 matches
Mail list logo
