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>
_______________________________________
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>
_______________________________________
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>
_______________________________________
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>
_______________________________________
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>
_______________________________________
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>
_______________________________________
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>
_______________________________________
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>
_______________________________________
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>
_______________________________________