[issue26011] Document necesities for cmp argument of sorted
New submission from Karl Richter: The docstring of `sorted` doesn't explain what can be passed to the `cmp` and `key` argument of `sorted`. -- assignee: docs@python components: Documentation messages: 257505 nosy: docs@python, krichter priority: normal severity: normal status: open title: Document necesities for cmp argument of sorted type: enhancement versions: Python 2.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26011> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25946] configure should pick /usr/bin/g++ automatically if present
New submission from Karl Richter: `./configure` both prints `checking for g++... no` and WARNING: By default, distutils will build C++ extension modules with "g++". If this is not intended, then set CXX on the configure command line. if `/usr/bin/g++` is present and executable which doesn't seem to be constructive because it's quite common that one wants to use `/usr/bin/g++` as CXX compiler if available. In case incompatibilities exists with other C++ compilers there should a check and more detailed error message. Furthermore the error message doesn't explain if a part of distutils won't be build because the message sounds like the C++ extension is built, but does it work without a C++ compiler? Specifying `CXX` environment variable or `--with-cxx-main=/usr/bin/g++` `configure` option works fine. experienced with 8a2e735 (on branch 2.7) -- components: Build messages: 256977 nosy: krichter priority: normal severity: normal status: open title: configure should pick /usr/bin/g++ automatically if present versions: Python 2.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25946> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25787] Add an explanation what happens with subprocess parent and child processes when signals are sent
Karl Richter added the comment: Please also explain how to deal with process replacement in child processes (assuming that http://stackoverflow.com/questions/34059576/how-to-register-a-signal-handler-for-a-subprocess/34065587#34065587 is correct). -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25787> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25787] Add an explanation what happens with subprocess parent and child processes when signals are sent
New submission from Karl Richter: The [documentation of subprocess](https://docs.python.org/3.6/library/subprocess.html) doesn't contain a substantial statement how signals are handled which are send to the python interpreter. After reading the referenced docs it should be clear * whether a signal is passed to both the parent and the child (If yes in which order? What happens if the child process spawns a process which isn't controlled by python?) * whether signal handlers are inherited (judging from the `restore_signals` parameter some are overwritten -> what's the purpose of this?). Are changes of a signal handler in the parent reflected in the child? -- assignee: docs@python components: Documentation messages: 255802 nosy: docs@python, krichter priority: normal severity: normal status: open title: Add an explanation what happens with subprocess parent and child processes when signals are sent versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25787> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24506] make fails with gcc 4.9 due to fatal warning of unused variable and empty macro in Parser/pgen.c
New submission from Karl Richter: `gcc` 4.9 is more restictive and recognizes that the empty definition of the `REQN` macro doesn't use some variables. It's more suitable to wrap the usage of the macro in the same preprocessor conditionals like the macro definition. experienced with 41fbc222af8c503e1659250a36f4e293d864a92b Patch attached. Tests pass (see https://semaphoreci.com/krichter/cpython/branches/empty_macro/builds/1 for details). -- components: Build files: 0001-removed-empty-definition-of-REQN-preprocessor-macro-.patch keywords: patch messages: 245781 nosy: krichter priority: normal severity: normal status: open title: make fails with gcc 4.9 due to fatal warning of unused variable and empty macro in Parser/pgen.c versions: Python 2.7 Added file: http://bugs.python.org/file39806/0001-removed-empty-definition-of-REQN-preprocessor-macro-.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24506 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24506] make fails with gcc 4.9 due to fatal warning of unused variable and empty macro in Parser/pgen.c
Karl Richter added the comment: It's a fatal warning of `gcc 4.9.2`, not an error (my bad) for `int i;` in `Parser/pgen.c` line 227. It might be ignored as well, but I think my approach is more elegant and deals with issues sooner than later. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24506 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24331] *** Error in `/usr/bin/python': double free or corruption (!prev): 0x0000000000f5c760 *** when cloning hg repository into directory on cifs
New submission from Karl Richter: I experience the error in the title exclusive when invoking `hg clone` (e.g. `hg clone https://bitbucket.org/Coin3D/coin` or `hg clone http://hg.netbeans.org/main-golden/ netbeans-main-golden`) when the target directory is on a cifs mount. `gdb` backtrace: #0 0x7761c267 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55 #1 0x7761deca in __GI_abort () at abort.c:89 #2 0x7765fc53 in __libc_message (do_abort=do_abort@entry=1, fmt=fmt@entry=0x777781a8 *** Error in `%s': %s: 0x%s ***\n) at ../sysdeps/posix/libc_fatal.c:175 #3 0x77667c69 in malloc_printerr (ptr=optimized out, str=0x777782d8 double free or corruption (!prev), action=1) at malloc.c:4965 #4 _int_free (av=optimized out, p=optimized out, have_lock=0) at malloc.c:3834 #5 0x7766b89c in __GI___libc_free (mem=optimized out) at malloc.c:2950 #6 0x7130ce11 in lfree (a=a@entry=0xecde10) at mercurial/mpatch.c:67 #7 0x7130d2e7 in decode (len=196, bin=0x1037ee8 ) at mercurial/mpatch.c:228 #8 fold (bins=[buffer at remote 0x710d40b0], start=start@entry=0, end=end@entry=1) at mercurial/mpatch.c:296 #9 0x7130d3d3 in patches (self=optimized out, args=optimized out) at mercurial/mpatch.c:327 #10 0x004ccd05 in call_function (oparg=optimized out, pp_stack=optimized out) at ../Python/ceval.c:4035 #11 PyEval_EvalFrameEx () at ../Python/ceval.c:2681 ---Type return to continue, or q return to quit--- #12 0x004cd4e2 in fast_function (nk=optimized out, na=optimized out, n=optimized out, pp_stack=optimized out, func=optimized out) at ../Python/ceval.c:4121 #13 call_function (oparg=optimized out, pp_stack=optimized out) at ../Python/ceval.c:4056 #14 PyEval_EvalFrameEx () at ../Python/ceval.c:2681 #15 0x004cb6b1 in PyEval_EvalCodeEx () at ../Python/ceval.c:3267 #16 0x004ce7d3 in fast_function (nk=optimized out, na=optimized out, n=optimized out, pp_stack=optimized out, func=optimized out) at ../Python/ceval.c:4131 #17 call_function (oparg=optimized out, pp_stack=optimized out) at ../Python/ceval.c:4056 #18 PyEval_EvalFrameEx () at ../Python/ceval.c:2681 #19 0x004cb6b1 in PyEval_EvalCodeEx () at ../Python/ceval.c:3267 #20 0x004ce7d3 in fast_function (nk=optimized out, na=optimized out, n=optimized out, pp_stack=optimized out, func=optimized out) at ../Python/ceval.c:4131 #21 call_function (oparg=optimized out, pp_stack=optimized out) at ../Python/ceval.c:4056 #22 PyEval_EvalFrameEx () at ../Python/ceval.c:2681 #23 0x004cb6b1 in PyEval_EvalCodeEx () at ../Python/ceval.c:3267 #24 0x004ce7d3 in fast_function (nk=optimized out, na=optimized out, n=optimized out, pp_stack=optimized out, ---Type return to continue, or q return to quit--- func=optimized out) at ../Python/ceval.c:4131 #25 call_function (oparg=optimized out, pp_stack=optimized out) at ../Python/ceval.c:4056 #26 PyEval_EvalFrameEx () at ../Python/ceval.c:2681 #27 0x004cb6b1 in PyEval_EvalCodeEx () at ../Python/ceval.c:3267 #28 0x004cd217 in fast_function (nk=optimized out, na=optimized out, n=optimized out, pp_stack=optimized out, func=optimized out) at ../Python/ceval.c:4131 #29 call_function (oparg=optimized out, pp_stack=optimized out) at ../Python/ceval.c:4056 #30 PyEval_EvalFrameEx () at ../Python/ceval.c:2681 #31 0x004cd4e2 in fast_function (nk=optimized out, na=optimized out, n=optimized out, pp_stack=optimized out, func=optimized out) at ../Python/ceval.c:4121 #32 call_function (oparg=optimized out, pp_stack=optimized out) at ../Python/ceval.c:4056 #33 PyEval_EvalFrameEx () at ../Python/ceval.c:2681 #34 0x004cb6b1 in PyEval_EvalCodeEx () at ../Python/ceval.c:3267 #35 0x004cd217 in fast_function (nk=optimized out, na=optimized out, n=optimized out, pp_stack=optimized out, func=optimized out) at ../Python/ceval.c:4131 #36 call_function (oparg=optimized out, pp_stack=optimized out) at ../Python/ceval.c:4056 ---Type return to continue, or q return to quit--- #37 PyEval_EvalFrameEx () at ../Python/ceval.c:2681 #38 0x004cb6b1 in PyEval_EvalCodeEx () at ../Python/ceval.c:3267 #39 0x004cd217 in fast_function (nk=optimized out, na=optimized out, n=optimized out, pp_stack=optimized out, func=optimized out) at ../Python/ceval.c:4131 #40 call_function (oparg=optimized out, pp_stack=optimized out) at ../Python/ceval.c:4056 #41 PyEval_EvalFrameEx () at ../Python/ceval.c:2681 #42
[issue24143] Makefile in tarball don't provide make uninstall target
Changes by Karl Richter krichter...@aol.de: -- components: Build nosy: krichter priority: normal severity: normal status: open title: Makefile in tarball don't provide make uninstall target versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24143 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24060] Clearify necessities for logging with timestamps
New submission from Karl Richter: The `Formatter` section of the `logging` module at https://docs.python.org/2/library/logging.html#formatter-objects reads like it's sufficient to create an instance of `Formatter` with default arguments (and set it as formatter of the `Handler` of a `Logger`) to have add timestamps to logging output. -- assignee: docs@python components: Documentation messages: 242024 nosy: docs@python, krichter priority: normal severity: normal status: open title: Clearify necessities for logging with timestamps versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24060 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24021] document urllib.urlretrieve
Karl Richter added the comment: I suspect the complaint might be about the lack of doc string Exactly. It'd be helpful to figure out the return value and the means of the function arguments in a more compact form than the referenced website docs and to have it available in the interpreter (with `help`), i.e. with docstring documentation. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24021 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24021] document urllib.urlretrieve
Changes by Karl Richter krichter...@aol.de: -- assignee: docs@python components: Documentation nosy: docs@python, krichter priority: normal severity: normal status: open title: document urllib.urlretrieve versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24021 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23174] shelve.open fails with error anydbm.error: db type could not be determined
Karl Richter added the comment: For example, it should be clear why `shelve.open(tempfile.mkstemp()[1])` fails with the mentioned exception and `shelve.open(/tmp/bla)` fails. I still haven't figured out the constraints to create a working `shelve.Shelve` at all. It should be clear why `shelve.open(/tmp/tmphTTQLd)` fails and `shelve.open(/tmp/tmphTTQLda)` succeeds. There has to be something unrelated to extensions. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23174 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23174] shelve.open fails with error anydbm.error: db type could not be determined
Karl Richter added the comment: After checking the code, I think that it'd make more sense to document `whichdb.py`. It needs to be enhanced with references to criteria for the determination of the database type. Currently there're only function comments and the fact that some variables are named magic speaks for itself, i.e. it's ok for the implementation of the module to be a black box, but the requirements for the input, i.e. the potential database file, which is per se not part of the black box, needs to be specified. Then just link that in the `shelve` docs stating that `shelve.open` is basically a wrapper around `whichdb`. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23174 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23163] pdb docs need to contain a statement on threads/multithreaded debugging
Karl Richter added the comment: Sorry, I mean #!/usr/bin/python import threading def debugging(): def __a_thread__(): print(2) a_thread = threading.Thread(target=__a_thread__) a_thread.start() a_thread.join() print(1) if __name__ == __main__: debugging() It's very uncommon to set the current debugging thread in the source. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23163 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23163] pdb docs need to contain a statement on threads/multithreaded debugging
Karl Richter added the comment: My initial description was imprecise. Clearification: The fact that in #!/usr/bin/python import threading def debugging(): def __a_thread__(): print(2) a_thread = threading.Thread(target=__a_thread__) print(1) if __name__ == __main__: debugging() when invoked with `python -m pdb` the breakpoint at line 7 is ignored, like in $ python -m pdb multithreaded_debugging.py /mnt/DATA/richter/examples/python/multithreaded_debugging/multithreaded_debugging.py(3)module() - import threading (Pdb) break 7 Breakpoint 1 at /mnt/DATA/richter/examples/python/multithreaded_debugging/multithreaded_debugging.py:7 (Pdb) c 1 The program finished and will be restarted /mnt/DATA/richter/examples/python/multithreaded_debugging/multithreaded_debugging.py(3)module() - import threading (Pdb) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23163 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23174] shelve.open fails with error anydbm.error: db type could not be determined
Karl Richter added the comment: That's nice, thanks. Considering your last comment, some points * If the issue can't go into the error message, than the essence of the discussion here should go into the docs (in 0.5 to 1.5 sentences). * It'd be nice if it was clear from the error message that shelve or underlying modules check the extension in filename, i.e. do `anydbm.error: db type could not be determined by file extension '%s' in filename '%s'` rather than `anydbm.error: db type could not be determined`. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23174 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23174] shelve.open fails with error anydbm.error: db type could not be determined
Karl Richter added the comment: Then, let the error message say You are opening a just-created empty file. The db type of the file cannot, therefore, be determined. which is much clearer than anydbm.error: db type could not be determined which sounds like a generic fallback error message in an error occured-style. It seems to be necessary that the filename passed to `shelve.open` has a suffix which is not very intuitive for Linux users. It'd be great to have validation of the suffix and raise a `ValueError` with an error message like `filename '%s' doesn't contain a suffix % (filename,)` when it isn't supplied. If there's another issue regarding the fact that the file is just-created and empty, this is independent of the issue above. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23174 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23174] shelve.open fails with error anydbm.error: db type could not be determined
New submission from Karl Richter: `shelve.open(tempfile.mkstemp()[1])` fails with error anydbm.error: db type could not be determined which is not explainable with the docs. Traceback is Traceback (most recent call last): File ./cudaminer_param_checker.py, line 720, in module plac.call(cudaminer_param_checker) File /usr/local/lib/python2.7/dist-packages/plac_core.py, line 309, in call cmd, result = parser_from(obj).consume(arglist) File /usr/local/lib/python2.7/dist-packages/plac_core.py, line 195, in consume return cmd, self.func(*(args + varargs + extraopts), **kwargs) File ./cudaminer_param_checker.py, line 715, in cudaminer_param_checker visualize_cudaminer_param_checker_results_wxpython_gui() File ./cudaminer_param_checker.py, line 365, in visualize_cudaminer_param_checker_results_wxpython_gui frame = CudaminerParamChecker(None, ) File ./cudaminer_param_checker.py, line 378, in __init__ self.generator = CudaminerParamCheckerGenerator() File ./cudaminer_param_checker.py, line 160, in __init__ self.result_dict= shelve.open(storage_file_path) File /usr/lib/python2.7/shelve.py, line 239, in open return DbfilenameShelf(filename, flag, protocol, writeback) File /usr/lib/python2.7/shelve.py, line 223, in __init__ Shelf.__init__(self, anydbm.open(filename, flag), protocol, writeback) File /usr/lib/python2.7/anydbm.py, line 82, in open raise error, db type could not be determined anydbm.error: db type could not be determined -- assignee: docs@python components: Documentation messages: 233488 nosy: docs@python, krichter priority: normal severity: normal status: open title: shelve.open fails with error anydbm.error: db type could not be determined type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23174 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23174] shelve.open fails with error anydbm.error: db type could not be determined
Karl Richter added the comment: EDIT 1: other examples, e.g. import os import shelve curdir = os.path.dirname(__file__) passwords = shelve.open(os.path.join(curdir, 'password_db')) work, so there's need for usable error messages. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23174 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23163] pdb docs need to contain a statement on threads/multithreaded debugging
New submission from Karl Richter: Due to the fact that `pdb` currently simply ignores breakpoints which are set and hit in another than the main thread the docs need to contain a statement on behavior in a multithreaded environment. -- components: Library (Lib) messages: 233409 nosy: krichter priority: normal severity: normal status: open title: pdb docs need to contain a statement on threads/multithreaded debugging type: enhancement versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23163 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21885] shutil.copytree hangs (on copying root directory of a lxc container) (should succeed or raise exception nested)
New submission from Karl Richter: reproduction (on Ubuntu 14.04 amd64 with lxc 1.0.4) (with python 2.7.6 and 3.4.0) # as root/with privileges lxc-create -n ubuntu-trusty-amd64 -t ubuntu -- --arch amd64 --release trusty lxc-stop -n ubuntu-trusty-amd64 # assert container isn't running cd /var/lib/lxc python import shutil shutil.copytree(ubuntu-trusty-amd64, ubuntu-trusty-amd64-orig) # never returns (after a multiple of the time rsync needs (see below) no more I/O operations) verify behavior of rsync (3.1.0): # as root/with privileges rsync -a ubuntu-trusty-amd64/ ubuntu-trusty-amd64-orig/ # succeeds If the container is shutdown it should no longer point to system resources, and thus be able to get stuck on reading from a device file (and should rsync get stuck as well in this case?). It would be nice if python fails with an exception (or succeeds, of course) instead of getting stuck. -- messages: 221960 nosy: krichter priority: normal severity: normal status: open title: shutil.copytree hangs (on copying root directory of a lxc container) (should succeed or raise exception nested) versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21885 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21889] https://docs.python.org/2/library/multiprocessing.html#process-and-exceptions doesn't explain exception
New submission from Karl Richter: Although the section https://docs.python.org/2/library/multiprocessing.html#process-and-exceptions (of the multiprocessing module documentation) is titled ... and exceptions it doesn't say anything about exceptions. I assume that it behaves like the thread API (as stated and referenced in the introduction of the module doc). This implies though that either the reference is limited to that statement (- remove and exceptions from the header as there's no special section on them because everything can be found in thread API) or add an explicit reference to the thread API. If this assumption is wrong the section is badly organized or doesn't make any sense at all. I'm not yet sure about exception handling in the multiprocessing module in case it's different from threads, but that shouldn't matter for this doc issue report. I'd also like to suggest a more detailed section on exceptions with usage of queues to pass them as objects to the parent or another process. -- assignee: docs@python components: Documentation messages: 221987 nosy: docs@python, krichter priority: normal severity: normal status: open title: https://docs.python.org/2/library/multiprocessing.html#process-and-exceptions doesn't explain exception type: enhancement versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21889 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21739] Add hint about expression in list comprehensions (https://docs.python.org/2/tutorial/datastructures.html#list-comprehensions)
New submission from Karl Richter: It would be useful to have a short statement in the docs (https://docs.python.org/2/tutorial/datastructures.html#list-comprehensions) that the expression in a list comprehension isn't put into a block, but evaluated against the same block where it is located because intuitively one might think that variables can be overridden in the statement. This applies to both 2.7 and 3.4.1. -- assignee: docs@python components: Documentation messages: 220374 nosy: docs@python, krichter priority: normal severity: normal status: open title: Add hint about expression in list comprehensions (https://docs.python.org/2/tutorial/datastructures.html#list-comprehensions) type: enhancement versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21739 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21208] Change default behavior of arguments with type bool when options are specified
Karl Richter added the comment: @paul.j3 That's interesting [1]. Documenting argparse.register seems crucial to me (- reopen or file a new request?). After dealing more with the very sophisticated and complex functionality of argparse I'm sure that this is the only use case where such an unintuitive result may happen, so it's worth adding an explicit negative example in the docs of argparse.add_argument with a hint to the docs about way that argparse handles types. -- [1] (and a very good example for missing capabilities of QA sites with regard to the relation of votes of your much better answer and the one with the highest number of votes) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21208 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21208] Change default behavior of arguments with type bool when options are specified
Karl Richter added the comment: That's a pity, I still think it's confusing. Thanks for your feedback! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21208 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21208] Change default behavior of arguments with type bool when options are specified
New submission from Karl Richter: As arguments with type bool are the only ones whose values can be manipulated without passing an option to the argument on CLI, the default behavior for those should be changed from ignoring options to failing when options are specified. Consider the following example: code import argparse cache_size_default=1000 cache_size_option = c cache_size_option_long = cache-size start_db_default = False start_db_option = t start_db_option_long = start-db parser = argparse.ArgumentParser(description='Process some integers.') parser.add_argument(-%s % start_db_option, --%s % start_db_option_long, default=start_db_default, type=bool, nargs='?', help='@TODO', dest=start_db_option_long) parser.add_argument(-%s % cache_size_option, --%s % cache_size_option_long, type=int, nargs='?', default=cache_size_default, help='size of osm2pgsql cache', dest=cache_size_option_long) def osm_postgis_transform(cache_size=cache_size_default, start_db=start_db_default): print(start_db, cache_size) if __name__ == __main__: args = vars(parser.parse_args()) osm_postgis_transform(cache_size=args[cache_size_option_long], start_db=args[start_db_option_long]) /code When the script is invoked with code python issue-argparse.py --start-db False --cache-size 2000 /code The value for start-db is True which is not really intuitive. Changing the default behavior to either fail at argument parsing or overwrite the argument value would be an improvement in my opinion. -- components: Library (Lib) messages: 215983 nosy: krichter priority: normal severity: normal status: open title: Change default behavior of arguments with type bool when options are specified type: behavior versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21208 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21208] Change default behavior of arguments with type bool when options are specified
Karl Richter added the comment: I've been mistaken about the behavior if no argument is specified (then the argument value is None), so this is a bug! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21208 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20683] [doc] Ease comprehension of section 9.2 of docs for Python 2 and 3 with example
New submission from Karl Richter: The explanation of namespaces in section 9.2 in documentation (http://docs.python.org/3/tutorial/classes.html#python-scopes-and-namespaces) is just so complicated without (at least one tiny) example. The example would ease the comprehension of the section by a high factor. -- assignee: docs@python components: Documentation messages: 211607 nosy: docs@python, krichter priority: normal severity: normal status: open title: [doc] Ease comprehension of section 9.2 of docs for Python 2 and 3 with example type: enhancement versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20683 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
