[issue13113] Wrong error message on class instance, when giving too little positional arguments
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_manifest=False, base_dir=None, debug=False): That is falsely instantiated from a different class with these arguments: self.path = cdist.path.Path(self.target_host, initial_manifest=initial_manifest, base_dir=home, debug=debug) Which results in the following traceback: [13:40] kr:cdist% ./bin/cdist config -d localhost Traceback (most recent call last): File "./bin/cdist", line 119, in commandline() File "./bin/cdist", line 102, in commandline args.func(args) File "/home/users/nico/oeffentlich/rechner/projekte/cdist/lib/cdist/config.py", line 296, in config c = Config(host, initial_manifest=args.manifest, home=args.cdist_home, debug=args.debug) File "/home/users/nico/oeffentlich/rechner/projekte/cdist/lib/cdist/config.py", line 52, in __init__ debug=debug) TypeError: __init__() takes at least 4 arguments (5 given) Problem: - there are 5 arguments, so an error message indicating there are at least 4 needed is not helpful Proposal (pseudocode): Change to "Only %d of %d required positional arguments given" required_positional, giving_positional -- components: Interpreter Core messages: 145002 nosy: telmich priority: normal severity: normal status: open title: Wrong error message on class instance, when giving too little positional arguments type: behavior versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue13113> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14228] SIGINT (Ctrl-C) not caught at startup
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 cdist project (http://www.nico.schottelius.org/software/cdist/), where we call a shell via subprocess.check_call() which calls us again (under a different name and thus different behaviour. So the call chain is like this: cdist => /bin/sh -e script => cdist_as_different_name (i.e. __file) A simple test case to reproduce the problem needs the two files caller.py and shellpart.sh in a directory: % ln -s caller.py __testpython % chmod a+x * % ./caller.py Indirect child being called Indirect child being called Indirect child being called Indirect child being called ^Ccaught signint in parent Traceback (most recent call last): File "/usr/lib/python3.2/site.py", line 58, in import traceback File "/usr/lib/python3.2/traceback.py", line 3, in import linecache File "/usr/lib/python3.2/linecache.py", line 10, in import tokenize File "/usr/lib/python3.2/tokenize.py", line 28, in import re File "/usr/lib/python3.2/re.py", line 121, in [10:02] brief:python-traceback-test% import functools File "/usr/lib/python3.2/functools.py", line 2, in """ KeyboardInterrupt Pressing Ctrl-C results in various different tracebacks and I don't see any way to catch the SIGINT reliably currently, as the code executed seems to be *before* my code is being executed. There is another related bug at debian that references the same problem: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652926 -- files: shellpart.sh messages: 155152 nosy: telmich priority: normal severity: normal status: open title: SIGINT (Ctrl-C) not caught at startup type: crash versions: Python 3.2 Added file: http://bugs.python.org/file24755/shellpart.sh ___ Python tracker <http://bugs.python.org/issue14228> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14228] SIGINT (Ctrl-C) not caught at startup
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/issue14228> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14228] SIGINT (Ctrl-C) not caught at startup
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\\n]*|([bB]?[rR]?\'\'\'|[bB]?[rR]?"""))|(([0-9]+[jJ]|(([0-9]+\\.[0-9]*|\\.[0-9]+)([eE][-+]?[0-9]+)?|[0-9]+[eE][-+]?[0-9]+)[jJ])|(([0-9]+\\.[0-9]*|\\.[0-9]+)([eE][-+]?[0-9]+)?|[0-9]+[eE][-+]?[0-9]+)|(0[xX][0-9a-fA-F]+|0[bB][01]+|0[oO][0-7]+|(?:0+|[1-9][0-9]*)))|((\\*\\*=?|>>=?|<<=?|!=|//=?|->|[+\\-*/%&|^=<>]=?|~)|[][(){}]|(\\r?\\n|\\.\\.\\.|[:;.,@]))|([bB]?[rR]?\'[^\\n\']*(?:.[^\\n\']*)*(\'|\\r?\\n)|[bB]?[rR]?"[^\\n"]*(?:.[^\\n"]*)*("|\\r?\\n))|\\w+)',
32)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3.2/site.py", line 58, in
import traceback
File "/usr/lib/python3.2/traceback.py", line 3, in
import linecache
File "/usr/lib/python3.2/linecache.py", line 10, in
import tokenize
File "/usr/lib/python3.2/tokenize.py", line 118, in
[19:02] brief:python-traceback-test% _compile, (Token, PseudoToken,
Single3, Double3))
File "/usr/lib/python3.2/tokenize.py", line 115, in _compile
return re.compile(expr, re.UNICODE)
File "/usr/lib/python3.2/re.py", line 206, in compile
return _compile(pattern, flags)
File "/usr/lib/python3.2/re.py", line 255, in _compile
return _compile_typed(type(pattern), pattern, flags)
File "/usr/lib/python3.2/functools.py", line 180, in wrapper
result = user_function(*args, **kwds)
File "/usr/lib/python3.2/re.py", line 267, in _compile_typed
return sre_compile.compile(pattern, flags)
File "/usr/lib/python3.2/sre_compile.py", line 495, in compile
code = _code(p, flags)
File "/usr/lib/python3.2/sre_compile.py", line 480, in _code
_compile(code, p.data, flags)
File "/usr/lib/python3.2/sre_compile.py", line 101, in _compile
_compile(code, av[1], flags)
File "/usr/lib/python3.2/sre_compile.py", line 142, in _compile
_compile(code, av, flags)
File "/usr/lib/python3.2/sre_compile.py", line 101, in _compile
_compile(code, av[1], flags)
File "/usr/lib/python3.2/sre_compile.py", line 142, in _compile
_compile(code, av, flags)
File "/usr/lib/python3.2/sre_compile.py", line 101, in _compile
_compile(code, av[1], flags)
File "/usr/lib/python3.2/sre_compile.py", line 142, in _compile
_compile(code, av, flags)
File "/usr/lib/python3.2/sre_compile.py", line 57, in _compile
_compile_charset(av, flags, code, fixup)
File "/usr/lib/python3.2/sre_compile.py", line 183, in _compile_charset
for op, av in _optimize_charset(charset, fixup):
File "/usr/lib/python3.2/sre_compile.py", line 253, in _optimize_charset
data = _mk_bitmap(charmap)
File "/usr/lib/python3.2/sre_compile.py", line 270, in _mk_bitmap
if m > MAXCODE:
KeyboardInterrupt
[19:03] brief:python-trace
--
Added file: http://bugs.python.org/file24758/caller.py
___
Python tracker
<http://bugs.python.org/issue14228>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14228] SIGINT (Ctrl-C) not caught at startup
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 should not be possible. Instead python could do the standard sigint behaviour, before reading python code (= exit). When starting to read "python shipped code" (i.e. stuff that comes with python and is always loaded), it should either implement a handler for sigint OR have sigint signal handler set to ignore. As soon as control flow is passed over to user code, raising KeyboardInterrupt is fine and I can catch that by enclosing all parts (including import statements) into a try: ... block that does what I want. -- ___ Python tracker <http://bugs.python.org/issue14228> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14228] SIGINT (Ctrl-C) not caught at startup
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's not possible currently in python 3.2.2. -- ___ Python tracker <http://bugs.python.org/issue14228> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14228] SIGINT (Ctrl-C) not caught at startup
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 called many (some thousand) times, depending on the configuration, thus you see the problem very often. This is indeed a general problem, but you cannot easily trigger it in one python process, because the race condition is hard to trigger manually. Thus the provided use case (running python 1000 times from shell scripts) is very realistic in a typical cdist run. For demonstration, you can run ./shellpart.sh directly, press ctrl-c and see that you'll get a traceback, although all possible code is protected from the exception. But (in that's the point) it is possible in user code to catch this exception. I should probably rephrase the title to "It is impossible to catch sigint on startup in python code" Hope this makes things more clear. -- ___ Python tracker <http://bugs.python.org/issue14228> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14228] It is impossible to catch sigint on startup in python code
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 is not used to python must have the impression that something must be really broken, if random errors appear on pressing the de-facto standard key kombination to exit a program. The problem here is that the user is confronted with unwanted output, produced by the interpreter, which is not possible to be caught by a programmer to prevent this situation happening. It is like the Windows 3.11 error message boxes, which never made sense to you, but appeared way too often and made you feel bad (hope this makes the problem more clear). -- ___ Python tracker <http://bugs.python.org/issue14228> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14228] It is impossible to catch sigint on startup in python code
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
^Ccaught signint in parent
Traceback (most recent call last):
File "/usr/lib/python3.2/functools.py", line 176, in wrapper
result = cache[key]
KeyError: (, '[ \\f\\t]*(\\r?\\n[
\\f\\t]*)*(#[^\\r\\n]*)?((([0-9]+[jJ]|(([0-9]+\\.[0-9]*|\\.[0-9]+)([eE][-+]?[0-9]+)?|[0-9]+[eE][-+]?[0-9]+)[jJ])|(([0-9]+\\.[0-9]*|\\.[0-9]+)([eE][-+]?[0-9]+)?|[0-9]+[eE][-+]?[0-9]+)|(0[xX][0-9a-fA-F]+|0[bB][01]+|0[oO][0-7]+|(?:0+|[1-9][0-9]*)))|((\\*\\*=?|>>=?|<<=?|!=|//=?|->|[+\\-*/%&|^=<>]=?|~)|[][(){}]|(\\r?\\n|\\.\\.\\.|[:;.,@]))|([bB]?[rR]?\'[^\\n\']*(?:.[^\\n\']*)*\'|[bB]?[rR]?"[^\\n"]*(?:.[^\\n"]*)*")|\\w+)',
32)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "./__testpython", line 4, in
import site
File "/usr/lib/python3.2/site.py", line 58, in
import traceback
File "/usr/lib/python3.2/traceback.py", line 3, in
import linecache
File "/usr/lib/python3.2/linecache.py", line 10, in
import tokenize
File "/usr/lib/python3.2/tokenize.py", line 118, in
_compile, (Token, PseudoToken, Single3, Double3))
File "/usr/lib/python3.2/tokenize.py", line 115, in _compile
return re.compile(expr, re.UNICODE)
File "/usr/lib/python3.2/re.py", line 206, in compile
[16:25] brief:python-traceback-test% return _compile(pattern, flags)
File "/usr/lib/python3.2/re.py", line 255, in _compile
return _compile_typed(type(pattern), pattern, flags)
File "/usr/lib/python3.2/functools.py", line 180, in wrapper
result = user_function(*args, **kwds)
File "/usr/lib/python3.2/re.py", line 267, in _compile_typed
return sre_compile.compile(pattern, flags)
File "/usr/lib/python3.2/sre_compile.py", line 495, in compile
code = _code(p, flags)
File "/usr/lib/python3.2/sre_compile.py", line 477, in _code
_compile_info(code, p, flags)
File "/usr/lib/python3.2/sre_compile.py", line 366, in _compile_info
lo, hi = pattern.getwidth()
File "/usr/lib/python3.2/sre_parse.py", line 163, in getwidth
i, j = av[1].getwidth()
File "/usr/lib/python3.2/sre_parse.py", line 153, in getwidth
l, h = av.getwidth()
File "/usr/lib/python3.2/sre_parse.py", line 163, in getwidth
i, j = av[1].getwidth()
File "/usr/lib/python3.2/sre_parse.py", line 153, in getwidth
l, h = av.getwidth()
File "/usr/lib/python3.2/sre_parse.py", line 163, in getwidth
i, j = av[1].getwidth()
File "/usr/lib/python3.2/sre_parse.py", line 153, in getwidth
l, h = av.getwidth()
File "/usr/lib/python3.2/sre_parse.py", line 163, in getwidth
i, j = av[1].getwidth()
File "/usr/lib/python3.2/sre_parse.py", line 153, in getwidth
l, h = av.getwidth()
File "/usr/lib/python3.2/sre_parse.py", line 147, in getwidth
REPEATCODES = (MIN_REPEAT, MAX_REPEAT)
KeyboardInterrupt
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "./__testpython", line 26, in
if re.match("__", os.path.basename(sys.argv[0])):
NameError: name 're' is not defined
--
Added file: http://bugs.python.org/file24993/caller.py
___
Python tracker
<http://bugs.python.org/issue14228>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14228] It is impossible to catch sigint on startup in python code
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 between initsigs(); would have been moved downwards? I'm asking, because if 'import site' is done, the maximum output seen that could occur is KeyboardInterrupt if there is no code around there. Which looks way more sane that what I see currently. -- ___ Python tracker <http://bugs.python.org/issue14228> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14228] It is impossible to catch sigint on startup in python code
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 probably fail again, because the user is still pressing ctrl-c: [17:05] brief:python-traceback-test% ./caller.py Indirect child being called Indirect child being called Indirect child being called Indirect child being called Indirect child being called Indirect child being called Indirect child being called Indirect child being called Indirect child being called Indirect child being called ^Ccaught signint in child [17:05] brief:python-traceback-test% ./caller.py Indirect child being called Indirect child being called Indirect child being called Indirect child being called Indirect child being called Indirect child being called Indirect child being called ^Ccaught signint in child Fatal Python error: Py_Initialize: can't initialize sys standard streams Traceback (most recent call last): File "/usr/lib/python3.2/io.py", line 60, in [17:05] brief:python-traceback-test% import _io File "/usr/lib/python3.2/os.py", line 22, in """ KeyboardInterrupt ./shellpart.sh: line 7: 23123 Aborted ./__testpython I'll change my production code to run with -S and restoring SIGINT and report back. In any case, I'd appreciate, if cpython would be changed to something more sane/less verbose by default. -- ___ Python tracker <http://bugs.python.org/issue14228> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14228] It is impossible to catch sigint on startup in python code
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 a software coded by a 12 years old, who is proud about it and does not accept an error being an error and insists on doing it right, although it's a common understanding that throwing errors in non error situations. I would have imagined a more mature understanding and broader view of python developers. If you're not willing to fix this bug but insist on doing it the wrong way by default, I'd recommened to reject this bug so that the problem, the reason and the reason why it continues to exists are cleanly documented. Cheers, Nico -- ___ Python tracker <http://bugs.python.org/issue14228> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14228] It is impossible to catch sigint on startup in python code
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 core problem. It's not about printing uncaught exceptions. And being the first to report is not something I feel is a bad sign. -- ___ Python tracker <http://bugs.python.org/issue14228> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16308] Undocumented (?) behaviour change in argparse from 3.2.3 to 3.3.0
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
Python 3.2.3
With python 3.3.0, this changed and thus the so far uncalled code block is
executed:
cdist% ./bin/cdist
Traceback (most recent call last):
File "./bin/cdist", line 237, in
commandline()
File "./bin/cdist", line 104, in commandline
args.func(args)
AttributeError: 'Namespace' object has no attribute 'func'
cdist% git describe
2.0.14-59-g5315c41
cdist% python3 -V
Python 3.3.0
Question:
What is the correct way now to abort, if no subparser or
no option was given (i.e. restore the previous behaviour)?
I tried to fix this problem by using
parser['main'].set_defaults(func=commandline_main)
to setup a default handler for main, but this overwrites the func= parameter
for all subparsers as well and thus renders this possibility useless (commits
b7a8a84 and 840dbc5 in cdist).
The source code for cdist using the subparsers is available at
http://git.schottelius.org/?p=cdist
--
components: Library (Lib)
messages: 173659
nosy: telmich
priority: normal
severity: normal
status: open
title: Undocumented (?) behaviour change in argparse from 3.2.3 to 3.3.0
versions: Python 3.3
___
Python tracker
<http://bugs.python.org/issue16308>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16308] Undocumented (?) behaviour change in argparse from 3.2.3 to 3.3.0
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.
-if positionals:
-self.error(_('too few arguments'))
-
[15:09] brief:cpython% hg grep "if positionals:" Lib/argparse.py
Lib/argparse.py:79016:if positionals:
And this seems to be the relevant change:
changeset: 70741:cab204a79e09
user:R David Murray
date:Thu Jun 09 12:34:07 2011 -0400
summary: #10424: argument names are now included in the missing argument
message
--
___
Python tracker
<http://bugs.python.org/issue16308>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16308] Undocumented (?) behaviour change in argparse from 3.2.3 to 3.3.0
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 to a bare minimum
(subparse.py) which shows the problem more clear:
% python3 -V
Python 3.2.3
% python3 ~/subparse.py
usage: subparse.py [-h] [-V] {banner} ...
subparse.py: error: too few arguments
versus
[15:44] brief:~% python3 -V
Python 3.3.0
[15:46] brief:~% python3 subparse.py
Traceback (most recent call last):
File "subparse.py", line 31, in
commandline()
File "subparse.py", line 25, in commandline
args.func(args)
AttributeError: 'Namespace' object has no attribute 'func'
--
Added file: http://bugs.python.org/file27694/subparse.py
___
Python tracker
<http://bugs.python.org/issue16308>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16308] Undocumented (?) behaviour change in argparse from 3.2.3 to 3.3.0
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 however understand from a logical point that this
does not work:
* no subparsers are required
* no argument is required
=> args.func is never setup
One could check for this situation using getattr:
try:
a = getattr(args, "func")
except AttributeError:
parser['main'].print_help()
sys.exit(0)
Though this look quite manual compared to the usual way of using argparse.
--
Added file: http://bugs.python.org/file27695/subparse2.py
___
Python tracker
<http://bugs.python.org/issue16308>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16308] Undocumented (?) behaviour change in argparse from 3.2.3 to 3.3.0
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
main: Namespace(func=, x=2, y=1.0)
main: Namespace(func=, z='XYZYX')
main: Namespace(func=)
Added lines to the original documentation are:
def main(args):
print('main: %s' % args)
...
parser.set_defaults(func=main)
...
args = parser.parse_args('')
args.func(args)
--
Added file: http://bugs.python.org/file27696/subparse3.py
___
Python tracker
<http://bugs.python.org/issue16308>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16308] Undocumented (?) behaviour change in argparse from 3.2.3 to 3.3.0
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. - Change implementation in such a way that using parser.set_defaults() on the main parser does not affect the sub parsers: Sub parsers are not related to the main parser like parent parsers and thus should not be affected by changes in the main parser. The second change would allow catching the case of no subcommands given and can be used to catch the empty arguments case. -- ___ Python tracker <http://bugs.python.org/issue16308> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16308] Undocumented (?) behaviour change in argparse from 3.2.3 to 3.3.0
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 proposal to the original issue 9523, though the other way round: in #9523 the required case was proposed to be the default. As 3.3.0 now defaults to optional, my proposal was to keep this behaviour and allow passing required=True. - Change implementation in such a way that using parser.set_defaults() on the main parser does not affect the sub parsers: As set_defaults() already exists, I think this is the cleaner method to implement this feature instead of using the default='' variant specified in #9523. Besides that I think the current behaviour of set_defaults changing the functions of the sub parsers is definitely a bug on its own. So summarised / compared: - Python 3.3.0 seems to treat subcommands as optional, compared to the original issue 9523 - set_defaults(func=x) on the main parsers affects sub parsers, which renders using set_defaults() useless - If requiring the behaviour of set_defaults() to pass the func= arguments to other parsers, the parents=[] argument already exists - To fix this issue, only correcting the set_defaults() call would be necessary - It makes sense though, to add the 'required' parameter, as the need has also been spotted by others already. -- ___ Python tracker <http://bugs.python.org/issue16308> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16308] Undocumented (?) behaviour change in argparse from 3.2.3 to 3.3.0
telmich added the comment: s/9523/9253/g in my previous post -- ___ Python tracker <http://bugs.python.org/issue16308> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14228] It is impossible to catch sigint on startup in python code
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 -- -z -z : initialise signals after 'import site' [15:20] brief:cpython% Using shellpart.sh (the original one) and using the newly compiled python binary (with -z), works fine: [15:18] brief:python-traceback-test% ./shellpart.sh Indirect child being called Indirect child being called Indirect child being called Indirect child being called Indirect child being called Indirect child being called Indirect child being called Indirect child being called Indirect child being called Indirect child being called Indirect child being called Indirect child being called Indirect child being called Indirect child being called Indirect child being called Indirect child being called Indirect child being called Indirect child being called ^C It would be great if you apply either patch: the static one is fine for me, but changes the behaviour => may not be suited for everyone. Otoh, it feels pretty clean to do a late signal change anyway. the parameter based one lets the user choose whether to use traceback'd version or the "unix default" version -> choose this, if you want to ensure backwards compatibility. -- keywords: +patch Added file: http://bugs.python.org/file27924/init_sigs_after_site_static.diff ___ Python tracker <http://bugs.python.org/issue14228> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14228] It is impossible to catch sigint on startup in python code
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/issue14228> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14228] It is impossible to catch sigint on startup in python code
telmich added the comment: And sorry for the long delay... -- ___ Python tracker <http://bugs.python.org/issue14228> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16308] Undocumented (?) behaviour change in argparse from 3.2.3 to 3.3.0
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 -- ___ Python tracker <http://bugs.python.org/issue16308> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16308] Undocumented (?) behaviour change in argparse from 3.2.3 to 3.3.0
telmich added the comment: Anyone alive at bugs.python.org? -- ___ Python tracker <http://bugs.python.org/issue16308> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19430] argparse replaces \$ to is passed
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
parser = argparse.ArgumentParser()
parser.add_argument('test', nargs='*')
result = parser.parse_args(sys.argv[1:])
print("args = %s" % " ".join(sys.argv))
print("result = %s" % result)
Reproduce problem:
[10:41] bento:~% python3 argparse-test.py ps1 "PS1='[\t]
\[\033[1m\]\h\[\033[0m\]:\w\$ '"
] \[\]\h\[\]:\w\$ '"args = argparse-test.py ps1 PS1='[\t]
\[\033[1m\]\h\[\033[0m\]:\w$ '
result = Namespace(test=['ps1', "PS1='[\\t]
\\[\\033[1m\\]\\h\\[\\033[0m\\]:\\w$ '"])
[10:40] bento:cdist% python --version
Python 3.3.2
--
components: Library (Lib)
messages: 201614
nosy: telmich
priority: normal
severity: normal
status: open
title: argparse replaces \$ to is passed
type: behavior
versions: Python 3.3
___
Python tracker
<http://bugs.python.org/issue19430>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19430] argparse replaces \$ with $ (if in commandline)
Changes by telmich : -- title: argparse replaces \$ to is passed -> argparse replaces \$ with $ (if in commandline) ___ Python tracker <http://bugs.python.org/issue19430> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19430] argparse replaces \$ with $ (if in commandline)
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 "PS1='[\t] \[\033[1m\]\h\[\033[0m\]:\w\$ '" which should have ensured that the line is found in /etc/bash.bashrc. But in reality we found PS1='[\t] \[\033[1m\]\h\[\033[0m\]:\w$ ' instead of PS1='[\t] \[\033[1m\]\h\[\033[0m\]:\w\$ ' This is a rather nasty bug, as you would not suspect argparse doing that and dig through all your code looking for errors. -- ___ Python tracker <http://bugs.python.org/issue19430> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19430] argparse replaces \$ with $ (if in commandline)
telmich added the comment: sorry for the noise, it was too early in the morning! -- ___ Python tracker <http://bugs.python.org/issue19430> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14228] It is impossible to catch sigint on startup in python code
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 debugging and should be treated as such, but not presented to an end user by default. But I as a developer, who wants to prevent the user seeing a backtrace while she does the most normal thing, this places a huge burden on me and I need to use undocumented workarounds to try to prevent this - in the case of a try... except block around my whole program even without suceess. The point is that no programming language should shout its internals to an end user and prevent the developer from cushion it easily. Think about "ls -lR" that throws debugging symbols at you, because you interrupted it - you would not want to see them, nor what you be happy if you had to cushion and especially not if this was not documented and hard to do. So in short my request is to make python more user friendly by cushion the unnecessary backtrace of a Ctrl-C printed out. -- ___ Python tracker <http://bugs.python.org/issue14228> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
