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 Brett Cannon <brett(a)python.org>:
The question on how best to get an absolute path from a pathlib.Path object keeps coming up (see https://bugs.python.org/issue29688, https://discuss.python.org/t/add-absolute-name-to-pathlib-path/2882/, and https://discuss.python.org/t/pathlib-absolute-vs-resolve/2573 as examples).
As pointed out across those posts, getting the absolute path is surprisingly subtle and varied depending on your needs. As such we should probably add a section somewhere in the pathlib docs explaining the various ways and why you would choose one over the other.
----------
assignee: docs@python
components: Documentation
messages: 358638
nosy: brett.cannon, docs@python
priority: normal
severity: normal
stage: needs patch
status: open
title: Document various options for getting the absolute path from pathlib.Path objects
type: enhancement
_______________________________________
Python tracker <report(a)bugs.python.org>
<https://bugs.python.org/issue39090>
_______________________________________
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 Terry J. Reedy:
https://docs.python.org/3/reference/expressions.html#yield-expressions says
"When yield from <expr> is used, it treats the supplied expression
as a subiterator. All values produced by that subiterator ...".
To me "treats..expression as a subiterator" means that the expression must *be* an iterator, such as returned by iter or calling a generator function. Hence I was surprised upon reading "yield from <non-iterator iterable>" in stdlib code.
I confirmed that this usage is correct by trying
>>> def g():
yield from (1,2)
>>> i = g()
>>> next(i), next(i)
(1, 2)
and then reading the PEP380 Formal Semantics, which begins with "_i = iter(EXPR)". Hence I suggest the following replacement for the quote above:
"When yield from <expr> is used, the expression must be an iterable.
A subiterator is obtained with iter(<expr>). All values produced
by that subiterator ...".
Note that 'subiterator' is spelled in the following sentences 'underlying iterable' (which I am not sure I like) and 'sub-iterator' (and 'sub-generator'). I think we should be consistent for at least the two short 'yield from' paragraphs.
----------
assignee: docs@python
components: Documentation
messages: 271577
nosy: docs@python, terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: yield from expression can be any iterable
type: behavior
versions: Python 3.5, Python 3.6
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue27646>
_______________________________________
New submission from Dan Merillat <dan.merillat(a)gmail.com>:
"The interpretation of the flags and the speeds as well as the indexing in the cc array must be done using the symbolic constants defined in the |termios| module." (termios links to itself)
These constants are not listed in the documentation and the termios module is installed as a shared library so you can't read it without going to the source.
Furthermore the example in the documentation uses the following example:
new = termios.tcgetattr(fd)
new[3] = new[3] & ~termios.ECHO # lflags
Which is explicitly against the documentation on the same page.
This has led to most searches on the net turning up people using magic numbers in places instead of symbolic values.
Inserting a list of constants with an extremely brief description would improve the module documentation dramatically.
----------
assignee: docs@python
components: Documentation
messages: 381393
nosy: dan.merillat, docs@python
priority: normal
severity: normal
status: open
title: Termios module documentation is extremely lacking
versions: Python 3.9
_______________________________________
Python tracker <report(a)bugs.python.org>
<https://bugs.python.org/issue42402>
_______________________________________
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 Serhiy Storchaka:
>From the documentation:
https://docs.python.org/3/c-api/stable.html
In the C API documentation, API elements that are not part of the limited API are marked as "Not part of the limited API."
But they don't.
Following sample patch adds the notes to Unicode Objects and Codecs C API. I'm going to add them to all C API.
What are your though about formatting the note? Should it be before the description, after the description, but before the "deprecated" directive (as in the patch), or after the first paragraph of the description? Should it be on the separate line or be appended at the end of the previous paragraph, or starts the first paragraph (if before the description)? May be introduce a special directive for it?
----------
assignee: docs@python
components: Documentation
files: unicode-not-part-of-the-limited-api.patch
keywords: patch
messages: 284125
nosy: docs@python, georg.brandl, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Document C API that is not part of the limited API
type: enhancement
versions: Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file46057/unicode-not-part-of-the-limited-api.patch
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue29086>
_______________________________________
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 George Fischhof <george(a)fischhof.hu>:
Winreg's documentation lacks mentioning required permission at some points
Hi there,
on page
https://docs.python.org/3/library/winreg.html
it is not mentioned in the description of the following functions:
winreg.DeleteKey
winreg.DeleteKeyEx
winreg.DeleteValue
that they require KEY_SET_VALUE when the registry key is opened.
It is mentioned for example at:
winreg.SetValue
with the following text:
The key identified by the key parameter must have been opened with KEY_SET_VALUE access.
BR,
George
----------
assignee: docs@python
components: Documentation
messages: 328034
nosy: docs@python, georgefischhof
priority: normal
severity: normal
status: open
title: Winreg's documentation lacks mentioning required permission at some points
type: enhancement
versions: Python 3.7
_______________________________________
Python tracker <report(a)bugs.python.org>
<https://bugs.python.org/issue35026>
_______________________________________