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 for
telmich added the comment:
sorry for the noise, it was too early in the morning!
--
___
Python tracker
<http://bugs.python.org/issue19430>
___
___
Python-bug
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
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 arg
Changes by telmich :
--
title: argparse replaces \$ to is passed -> argparse replaces \$ with $ (if in
commandline)
___
Python tracker
<http://bugs.python.org/issu
telmich added the comment:
Anyone alive at bugs.python.org?
--
___
Python tracker
<http://bugs.python.org/issue16308>
___
___
Python-bugs-list mailing list
Unsub
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
telmich added the comment:
And sorry for the long delay...
--
___
Python tracker
<http://bugs.python.org/issue14228>
___
___
Python-bugs-list mailing list
Unsub
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
<http://bugs.python.org/issue14
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:
s/9523/9253/g in my previous post
--
___
Python tracker
<http://bugs.python.org/issue16308>
___
___
Python-bugs-list mailing list
Unsub
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:
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:
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 subpars
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
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:
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 sup
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:
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 hope you understand that this is the
telmich 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, but this looks like
telmich 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 to import
sys, will pro
telmich 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 guess/hope that the race condition
telmich 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 called
Indirect child being called
telmich 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 not catching the exception.
Thus someone who
telmich 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 there, because python is calle
telmich 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 the problem, you'll notice
it&
telmich 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.
Imho this behaviour sho
telmich 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: (, '[
\\f\\t]*((\\r?\\n|#[^\\r
telmich added the comment:
And here's the actual python code
--
Added file: http://bugs.python.org/file24756/caller.py
___
Python tracker
<http://bugs.python.org/is
New submission from telmich :
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 noticed this during development of the
New submission from telmich :
I've this class:
class Path:
"""Class that handles path related configurations"""
def __init__(self,
target_host,
remote_user,
remote_prefix,
initial_manif
31 matches
Mail list logo
