New submission from Jonas H. <jonas(a)lophus.org>:
Intersphinx-ing of int, list, float, ... should work with ":class:`int`" (list, float, ...). Also, intersphinx-ing list methods, e.g. ":meth:`list.insert`", should work.
----------
assignee: docs@python
components: Documentation
messages: 134923
nosy: docs@python, jonash
priority: normal
severity: normal
status: open
title: Fix intersphinx-ing of built-in types (list, int, ...)
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue11975>
_______________________________________
New submission from Jonas H. <jonas(a)lophus.org>:
Various `int` attributes and methods seem undocumented (at least it does not work to intersphinx them):
* .conjugate
* .denominator
* .imag
* .numerator
* .real
----------
assignee: docs@python
components: Documentation
messages: 134926
nosy: docs@python, jonash
priority: normal
severity: normal
status: open
title: Document int.conjugate, .denominator, ...
versions: Python 2.7
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue11977>
_______________________________________
New submission from Baruch Sterin <python(a)bsterin.com>:
In addition to the description text, most C API functions have a one-line, emphasized specification whether they return a new or a borrowed reference. (e.g. 'Return value: New reference.').
The following API functions are missing that. Some of them, like PyMemoryView_FromBuffer(), have descriptions that are clear, but it would still be nice to have an unambiguous statement like most other API functions have.
The list has been generated automatically, so it might contain some errors.
Doc/c-api/arg.rst: Py_VaBuildValue
Doc/c-api/buffer.rst: PyMemoryView_FromBuffer
Doc/c-api/buffer.rst: PyMemoryView_FromObject
Doc/c-api/buffer.rst: PyMemoryView_GetContiguous
Doc/c-api/bytearray.rst: PyByteArray_Concat
Doc/c-api/bytearray.rst: PyByteArray_FromObject
Doc/c-api/bytearray.rst: PyByteArray_FromStringAndSize
Doc/c-api/code.rst: PyCode_New
Doc/c-api/codec.rst: PyCodec_BackslashReplaceErrors
Doc/c-api/codec.rst: PyCodec_Decode
Doc/c-api/codec.rst: PyCodec_Decoder
Doc/c-api/codec.rst: PyCodec_Encode
Doc/c-api/codec.rst: PyCodec_Encoder
Doc/c-api/codec.rst: PyCodec_IgnoreErrors
Doc/c-api/codec.rst: PyCodec_IncrementalDecoder
Doc/c-api/codec.rst: PyCodec_IncrementalEncoder
Doc/c-api/codec.rst: PyCodec_LookupError
Doc/c-api/codec.rst: PyCodec_ReplaceErrors
Doc/c-api/codec.rst: PyCodec_StreamReader
Doc/c-api/codec.rst: PyCodec_StreamWriter
Doc/c-api/codec.rst: PyCodec_StrictErrors
Doc/c-api/codec.rst: PyCodec_XMLCharRefReplaceErrors
Doc/c-api/exceptions.rst: PyUnicodeDecodeError_Create
Doc/c-api/exceptions.rst: PyUnicodeDecodeError_GetEncoding
Doc/c-api/exceptions.rst: PyUnicodeDecodeError_GetObject
Doc/c-api/exceptions.rst: PyUnicodeDecodeError_GetReason
Doc/c-api/exceptions.rst: PyUnicodeEncodeError_Create
Doc/c-api/exceptions.rst: PyUnicodeTranslateError_Create
Doc/c-api/float.rst: PyFloat_GetInfo
Doc/c-api/import.rst: PyImport_GetImporter
Doc/c-api/import.rst: PyImport_ImportModuleNoBlock
Doc/c-api/import.rst: _PyImport_FindExtension
Doc/c-api/import.rst: _PyImport_FixupExtension
Doc/c-api/init.rst: PyEval_GetCallStats
Doc/c-api/int.rst: PyInt_FromSize_t
Doc/c-api/long.rst: PyLong_FromSize_t
Doc/c-api/long.rst: PyLong_FromSsize_t
Doc/c-api/number.rst: PyNumber_Index
Doc/c-api/number.rst: PyNumber_ToBase
Doc/c-api/object.rst: PyObject_Bytes
Doc/c-api/object.rst: PyObject_GenericGetAttr
Doc/c-api/unicode.rst: PyUnicode_AsUTF32String
Doc/c-api/unicode.rst: PyUnicode_DecodeMBCSStateful
Doc/c-api/unicode.rst: PyUnicode_DecodeUTF32
Doc/c-api/unicode.rst: PyUnicode_DecodeUTF32Stateful
Doc/c-api/unicode.rst: PyUnicode_DecodeUTF7
Doc/c-api/unicode.rst: PyUnicode_DecodeUTF7Stateful
Doc/c-api/unicode.rst: PyUnicode_EncodeUTF32
Doc/c-api/unicode.rst: PyUnicode_EncodeUTF7
Doc/c-api/veryhigh.rst: PyEval_EvalCodeEx
Doc/c-api/veryhigh.rst: PyEval_EvalFrame
Doc/c-api/veryhigh.rst: PyEval_EvalFrameEx
----------
assignee: docs@python
components: Documentation
messages: 154877
nosy: baruch.sterin, docs@python
priority: normal
severity: normal
status: open
title: Documentation for some C APIs is missing clear specification of the type of reference they return
type: behavior
versions: Python 2.7
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue14189>
_______________________________________
New submission from Chris Jerdonek:
The sentence describing Popen()'s cwd argument in the subprocess documentation seems reversed to me:
http://docs.python.org/dev/library/subprocess.html#subprocess.Popen
It says, "If cwd is not None, the child’s current directory will be changed to cwd before it is executed. Note that this directory is not considered when searching the executable, so you can’t specify the program’s path relative to cwd."
However, when cwd is not None, it seems like you *must* specify the program's path relative to cwd. For example, when running a script containing the following using `./python.exe` from a source checkout--
p = Popen(['./python.exe', '-V'], stdout=PIPE, stderr=PIPE, cwd='temp')
you get an: "OSError: [Errno 2] No such file or directory."
In contrast, when you *do* specify the program's path relative to cwd, it works--
p = Popen(['../python.exe', '-V'], stdout=PIPE, stderr=PIPE, cwd='temp')
Issue 6374 seems to have made the same point in its second bullet, but the issue was closed without addressing that part of it.
----------
assignee: docs@python
components: Documentation
keywords: easy
messages: 167194
nosy: cjerdonek, docs@python
priority: normal
severity: normal
status: open
title: subprocess.Popen(cwd) documentation
versions: Python 2.7, Python 3.3
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue15533>
_______________________________________
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>
_______________________________________
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 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 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 Julian <python_org(a)somethinkodd.com>:
Since Python 2.6, httplib has offered a timeout parameter for fetches. As the documentation explains, if this parameter is not provided, it uses the global default.
What the document doesn't explain is httplib builds on top of the socket library. The socket library has a default timeout of None (i.e. forever). This may be an appropriate default for general sockets, but it is a poor default for httplib; typical http clients would use a timeout in the 2-10 second range.
This problem is propagated up to urllib2, which sits on httplib, and further obscures that the default might be unsuitable.
>From an inspection of the manuals, Python 3.0.1 suffers from the same problem except, the names have changed. urllib.response sits on http.client.
I, for one, made a brutal mistake of assuming that the "global default" would be some reasonable default for fetching web pages; I didn't have any specific timeout in mind, and was happy for the library to take care of it. Several million successful http downloads later, my server application thread froze waiting forever when talking to a recalcitrant web-server. I imagine others have fallen for the same trap.
While an ideal solution would be for httplib and http.client to use a more generally acceptable default, I can see it might be far too late to make such a change without breaking existing applications. Failing that, I would recommend that the documentation for httplib, urllib, urllib2, http.client and urllib.request (+ any other similar libraries sitting on socket? FTP, SMTP?) be changed to highlight that the default global timeout, sans deliberate override, is to wait a surprisingly long time.
----------
assignee: docs@python
components: Documentation, Library (Lib)
messages: 104763
nosy: docs@python, oddthinking
priority: normal
severity: normal
status: open
title: Unexpected default timeout in http-client-related libraries
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue8595>
_______________________________________
