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 Jan Duzinkiewicz:
quote from http://docs.python.org/3/library/imp.html#imp.find_module:
"...on some systems some other places are looked in as well (on Windows, it looks in the registry which may point to a specific file)."
I actually didn't know the registry key is listed in "using Python on Window" guide until I grepped for PythonCore (which kind of requires to know the key already) - so I'm submitting a patch that cross references find_module docs and using Python on Windows guide.
----------
assignee: docs@python
components: Documentation
files: import_nt_reg.patch
keywords: patch
messages: 174508
nosy: dhgmgn, docs@python
priority: normal
severity: normal
status: open
title: imp.find_module does not specify registry key it searches on windows
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file27843/import_nt_reg.patch
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue16386>
_______________________________________
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 Sye van der Veen:
In the ctypes documentation, there's mention of a BigEndianUnion/LittleEndianUnion that isn't actually implemented, and the "Arrays and pointers" section just reads "Not yet written".
The attached patch adds the (Big|Little)EndianUnion classes (with tests), finishes the Array/_Pointer class docs (and adds missing cases to the tests), and makes some stylistic improvements to docs.
The patch was made against default, but it's quite likely it could be back-ported all the way to Python 3.1.
----------
assignee: docs@python
components: Documentation, Tests, ctypes
hgrepos: 209
messages: 197764
nosy: docs@python, syeberman
priority: normal
severity: normal
status: open
title: ctypes docs: Unimplemented and undocumented features
type: enhancement
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue19023>
_______________________________________
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 Marc Brünink:
The documentation for is not very clear regarding the usage of CDLL and PyDLL. Especially it is not obvious that you should use PyDLL whenever you call any function of the Python/C API. Since calling a Python/C API function without owning the GIL will most likely cause latent segfaults, I think it warrants a warning box in section 16.17.2.2 and maybe also somewhere prominent in http://docs.python.org/dev/c-api/intro.html.
For section 16.17.2.2 I would put a box next the decription of CDLL saying something like: "The Python GIL is released before a function call. It is not safe to call any Pyhon/C API function within the loaded library without acquiring the GIL first. Thus, if the loaded library calls functions of the Python/C API, for example in case it creates and returns a new Python object, and does not manually acquire and release the GIL, use PyDLL instead."
----------
assignee: docs@python
components: Documentation
messages: 189629
nosy: Marc.Brünink, docs@python
priority: normal
severity: normal
status: open
title: ctypes.PyDLL documentation
versions: Python 3.5
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue18017>
_______________________________________
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>
_______________________________________
