docs January 2015

docs@python.org

23 participants
551 discussions

[issue8557] subprocess portability issue

by Dave Abrahams

New submission from Dave Abrahams <dave(a)boostpro.com>: On POSIX systems, the PATH environment variable is always used to look up directory-less executable names passed as the first argument to Popen(...), but on Windows, PATH is only considered when shell=True is also passed. Actually I think it may be slightly weirder than that when shell=False, because the following holds for me: C:\>rem ##### Prepare minimal PATH ##### C:\>set "PATH=C:\Python26\Scripts;C:\Python26;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem" C:\>rem ##### Prepare a minimal, clean environment ##### C:\>virtualenv --no-site-packages e:\zzz New python executable in e:\zzz\Scripts\python.exe Installing setuptools................done. C:\>rem ##### Show that shell=True makes the difference in determining whether PATH is respected ##### C:\>python Python 2.6.5 (r265:79096, Mar 19 2010, 18:02:59) [MSC v.1500 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import subprocess >>> subprocess.Popen(['python', '-c', 'import sys; print sys.executable']) <subprocess.Popen object at 0x0000000001DBE080> >>> C:\Python26\python.exe >>> subprocess.Popen(['python', '-c', 'import sys; print sys.executable'], env={'PATH':r'e:\zzz\Scripts'}) <subprocess.Popen object at 0x0000000001F05A90> >>> C:\Python26\python.exe >>> subprocess.Popen(['python', '-c', 'import sys; print sys.executable'], env={'PATH':r'e:\zzz\Scripts'}, shell=True) <subprocess.Popen object at 0x0000000001F05B00> >>> e:\zzz\Scripts\python.exe That is, it looks like the environment at the time Python is invoked is what counts unless I pass shell=True. I don't even seem to be able to override this behavior by changing os.environ: you can clear() it and pass env={} and subprocess.Popen(['python']) still succeeds. This is a very important problem for portable code and one that took me hours to suss out. I think: a) the current behavior needs to be documented b) it needs to be fixed if possible c) otherwise, shell=True should be the default ---------- assignee: docs@python components: Documentation messages: 104422 nosy: dabrahams, docs@python priority: normal severity: normal status: open title: subprocess portability issue type: behavior versions: Python 2.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue8557> _______________________________________

2 days, 3 hours

[issue16272] C-API documentation clarification for tp_dictoffset

by Chris Colbert

New submission from Chris Colbert: The documentation of the tp_dictoffset is a bit unclear when describing the responsibilities of a base type with a nonzero tp_dictoffset. http://docs.python.org/c-api/typeobj.html I feel there should some statement to the effect of: """ If a type defines a nonzero tp_dictoffset, that type is responsible for defining a `__dict__` slot as part of the tp_getset structures. Failure to do so will result in the dict being inaccesible from Python via `obj.__dict__` from instances of the type or subtypes. """ The reasoning is twofold: 1) `PyType_Ready` does not add the default getset members like `type_new` does. This prevents the instances of the type itself from retrieving `obj.__dict__` 2) `type_new` will provide the default `subtype_dict` getset member for subclasses, but this calls `get_builtin_base_with_dict` which will resolve to the most base type which is not heap allocated; in this case, the C type. Since this type has no `__dict__` getset member, the lookup fails. Adding a bit of verbage about this "gotcha" would likely save some headaches in the future. ---------- assignee: docs@python components: Documentation messages: 173222 nosy: Chris.Colbert, docs@python priority: normal severity: normal status: open title: C-API documentation clarification for tp_dictoffset versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16272> _______________________________________

2 days, 5 hours

[issue12594] Docs for py3k still refer to "MacPython 2.5 folder"

by Christoph Schindler

New submission from Christoph Schindler <hop(a)30hopsmax.at>: In http://docs.python.org/py3k/using/mac.html#getting-and-installing-macpython and http://docs.python.org/py3k/using/mac.html#distributing-python-applications… . ---------- assignee: docs@python components: Documentation messages: 140744 nosy: docs@python, hop priority: normal severity: normal status: open title: Docs for py3k still refer to "MacPython 2.5 folder" versions: Python 3.1, Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12594> _______________________________________

3 days, 7 hours

[issue13368] Possible problem in documentation of module subprocess, method send_signal

by Eli Bendersky

New submission from Eli Bendersky <eliben(a)gmail.com>: docs@ list report by Daniel Dieterle: in the documentation (http://docs.python.org/library/subprocess.html#subprocess.Popen.send_signal) is a bug. CTRL_C_EVENT can not be sent to processes started with a creationflags parameter which includes CREATE_NEW_PROCESS_GROUP. Why can be read in the msdn documentation http://msdn.microsoft.com/en-us/library/windows/desktop/ms683155%28v=vs.85%… . A workaround using CTRL_C_EVENT nevertheless is described here: http://stackoverflow.com/questions/7085604/sending-c-to-python-subprocess-o… -- I do not know why the subprocess.CREATE_NEW_PROCESS_GROUP parameter was introduced. But it is useless for terminating a process with os.kill() in combination with signal.SIGTERM, which corresponds to a CTRL-C-EVENT. A CTRL-C-EVENT is only forwarded to the process if the process group is zero. Therefore the Note in the documentation on Popen.send_signal() is wrong. ---------- assignee: docs@python components: Documentation messages: 147272 nosy: docs@python, eli.bendersky priority: normal severity: normal status: open title: Possible problem in documentation of module subprocess, method send_signal versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13368> _______________________________________

1 week, 3 days

[issue16954] Add docstrings for ElementTree module

by Serhiy Storchaka

New submission from Serhiy Storchaka: Perhaps almost all Doxygen comments in ElementTree module should be converted to docstrings. ---------- assignee: docs@python components: Documentation, XML messages: 179881 nosy: docs@python, eli.bendersky, serhiy.storchaka priority: normal severity: normal stage: needs patch status: open title: Add docstrings for ElementTree module type: enhancement versions: Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16954> _______________________________________

2 weeks

[issue13433] String format documentation contains error regarding %g

by Christian Iversen

New submission from Christian Iversen <ci(a)sikkerhed.org>: The documentation for string format options state that both %f, %g and %e default to 6 digits after the decimal point. In fact, %g always seems to use 5 digits by default: >>> "%g" % 2.1234567 '2.12346' >>> "%f" % 2.1234567 '2.123457' >>> "%e" % 2.1234567 '2.123457e+00' But something much more insidious is wrong, because even when explicitly told how many digits to have, %g is one off: >>> "%.6g" % 2.1234567 '2.12346' >>> "%.6f" % 2.1234567 '2.123457' >>> "%.6e" % 2.1234567 '2.123457e+00' This can't be right? ---------- assignee: docs@python components: Documentation messages: 147940 nosy: Christian.Iversen, docs@python priority: normal severity: normal status: open title: String format documentation contains error regarding %g type: behavior versions: Python 2.6, Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13433> _______________________________________

2 weeks, 3 days

[issue20364] Rename & explain sqlite3.Cursor.execute 'parameters' param

by Terry J. Reedy

New submission from Terry J. Reedy: "execute(sql[, parameters]) Executes an SQL statement. The SQL statement may be parametrized (i. e. placeholders instead of SQL literals). The sqlite3 module supports two kinds of placeholders: question marks (qmark style) and named placeholders (named style)." Experimental facts based on experiments with the code example in the doc, using 3.4.b2: 'parameters' is a single subscriptable collection parameter, sequence or dict, that might be called seq_dict. It is positional only, so whatever name is used is a dummy. Only one placeholder style can be used in a given SQL statement string. If question marks are used, seq_dict must be a sequence. If names are used, seq_dict can be either a sequence or dict or subclass thereof. A UserDict is treated as a sequence and raises KeyError(0). Possible text that encompasses the above, replacing the last sentence: "A statement may use one of two kinds of placeholders: question marks (qmark style) or named placeholders (named style). For qmark style, seq_dict must be a sequence. For named style, it can be either a sequence or dict instance. Len(seq_dict) must match the number of placeholders." After cleaning up the test file, I will verify on 2.7 and upload. ---------- assignee: docs@python components: Documentation, Library (Lib) messages: 208908 nosy: docs@python, terry.reedy priority: normal severity: normal stage: patch review status: open title: Rename & explain sqlite3.Cursor.execute 'parameters' param type: behavior versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue20364> _______________________________________

2 weeks, 5 days

[issue20464] Update distutils sample config file in Doc/install/index.rst

by Zachary Ware

New submission from Zachary Ware: >From docs@: On Thu, Jan 16, 2014 at 2:56 AM, Peter Bröcker <peter.broecker(a)uni-koeln.de> wrote: > Hi, > > I have tried to set up the distutils config files for a custom module > installation. Using the suggested snippet from > > http://docs.python.org/2/install/ > > [install] > install-base=$HOME/python > install-purelib=lib > install-platlib=lib.$PLAT > install-scripts=scripts > install-data=data did not work for me. > > Instead, I had to add install-headers and additionally modify all paths > to include $base: > > [install] > install-base=/some/dir > install-purelib=$base/lib > install-platlib=$base/lib.$PLAT > install-scripts=$base/scripts > install-headers=$base/include > install-data=$base/data > > > I'm unsure if this is actually a bug, but I could only resolve this with > the help of this answer on stackoverflow: > http://stackoverflow.com/a/12768721 > > Best regards, > Peter ---------- assignee: docs@python components: Distutils, Documentation messages: 209829 nosy: docs@python, zach.ware priority: normal severity: normal stage: test needed status: open title: Update distutils sample config file in Doc/install/index.rst type: behavior versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue20464> _______________________________________

1 month

[issue22401] argparse: 'resolve' conflict handler damages the actions of the parent parser

by paul j3

New submission from paul j3: When there's a conflict involving an argument that was added via 'parents', and the conflict handler is 'resolve', the action in the parent parser may be damaged, rendering that parent unsuitable for further use. In this example, 2 parents have the same '--config' argument: parent1 = argparse.ArgumentParser(add_help=False) parent1.add_argument('--config') parent2 = argparse.ArgumentParser(add_help=False) parent2.add_argument('--config') parser = argparse.ArgumentParser(parents=[parent1,parent2], conflict_handler='resolve') The actions of the 3 parsers are (from the ._actions list): (id, dest, option_strings) parent1: [(3077384012L, 'config', [])] # empty option_strings parent2: [(3076863628L, 'config', ['--config'])] parser: [(3076864428L, 'help', ['-h', '--help']), (3076863628L, 'config', ['--config'])] # same id The 'config' Action from 'parent1' is first copied to 'parser' by reference (this is important). When 'config' from 'parent2' is copied, there's a conflict. '_handle_conflict_resolve()' attempts to remove the first Action, so it can add the second. But in the process it ends up deleting the 'option_strings' values from the original action. So now 'parent1' has an action in its 'optionals' argument group with an empty option_strings list. It would display as an 'optionals' but parse as a 'positionals'. 'parent1' can no longer be safely used as a parent for another (sub)parser, nor used as a parser itself. The same sort of thing would happen, if, as suggested in the documentation: "Sometimes (e.g. when using parents_) it may be useful to simply override any older arguments with the same option string." In test_argparse.py, 'resolve' is only tested once, with a simple case of two 'add_argument' statements. The 'parents' class tests a couple of cases of conflicting actions (for positionals and optionals), but does nothing with the 'resolve' handler. ------------------------------ Possible fixes: - change the documentation to warn against reusing such a parent parser - test the 'resolve' conflict handler more thoroughly - rewrite this conflict handler so it does not modify the action in the parent - possibly change the 'parents' mechanism so it does a deep copy of actions. References: http://stackoverflow.com/questions/25818651/argparse-conflict-resolver-for-… http://bugs.python.org/issue15271 argparse: repeatedly specifying the same argument ignores the previous ones http://bugs.python.org/issue19462 Add remove_argument() method to argparse.ArgumentParser http://bugs.python.org/issue15428 add "Name Collision" section to argparse docs ---------- assignee: docs@python components: Documentation, Library (Lib), Tests messages: 226862 nosy: docs@python, paul.j3 priority: normal severity: normal status: open title: argparse: 'resolve' conflict handler damages the actions of the parent parser type: behavior versions: Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue22401> _______________________________________

1 month, 1 week

[issue15097] Improving wording on the thread-safeness of import

by Merlijn van Deen

New submission from Merlijn van Deen <valhallasw(a)gmail.com>: http://docs.python.org/library/threading.html#importing-in-threaded-code Currently, the documentation states "Firstly, other than in the main module, an import should not have the side effect of spawning a new thread and then waiting for that thread in any way. Failing to abide by this restriction can lead to a deadlock if the spawned thread directly or indirectly attempts to import a module." which, I think, fails to make the main point: a call to import acquires the import lock. A call to import from a second thread will thus block. As such, I would suggest rephrasing it to something like: "Firstly, an import acquires the import lock for that thread. Therefore, the import should not have the side effect of waiting for a different thread in any way, as this can lead to a deadlock if that thread directly or indirectly attempts to import a module." There are two additional points that might be interesting to note: (1) Any module can be imported. If the import causes a deadlock, that is a bad thing. Every module *will* be imported by tools such as nosetests. (1b) so: never, ever, have code that causes locks in a different thread in module level code witout 'if __name__=="__main__" ' blocks? (2) The lock is also acquired if a module has already been imported. For instance, in import sys # (1) def f(): import sys # (2) the import lock is acquired in (1) /and/ (2). Adding example code and/or a flow diagram might be a bit too much, but it does clarify how easy it is to make this mistake. See the attached for an example (both a simple example script, as well as a flow diagram explaining what happens). ---------- assignee: docs@python components: Documentation files: deadlock.py messages: 163068 nosy: docs@python, valhallasw priority: normal severity: normal status: open title: Improving wording on the thread-safeness of import type: enhancement Added file: http://bugs.python.org/file26037/deadlock.py _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15097> _______________________________________

2 months

Jump to page:

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

docs January 2015