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>
_______________________________________
New submission from Frank Griswold <py.griswolf(a)spamgourmet.com>:
This chunk of docs has bad info in both Python2 and Python3 docs:
4.1.3. Configuration
Python on OS X honors all standard Unix environment variables such as PYTHONPATH, but setting these variables for programs started from the Finder is non-standard as the Finder does not read your .profile or .cshrc at startup. You need to create a file ~/.MacOSX/environment.plist. See Apple’s Technical Document QA1067 for details.
If you search for QA1067, you are informed that the document is legacy and unsupported, with a suggestion for where to look now. That suggested link leads to a 404.
Searching the apple site, I find that at least some thoughtful developers think that configuring the environment isn't even possible, generally; and isn't considered good form even if so. Here:
https://forums.developer.apple.com/message/217422
I have no problem setting things for my terminal, as a longtime (unix) user, but for others, this section probably needs a complete examination with an eye toward making it current. quite possibly by reorganizing it.
----------
assignee: docs@python
components: Documentation
messages: 312023
nosy: docs@python, griswolf
priority: normal
severity: normal
status: open
title: Docs: Using Python on a Macintosh has bad info per Apple site
type: enhancement
_______________________________________
Python tracker <report(a)bugs.python.org>
<https://bugs.python.org/issue32824>
_______________________________________
New submission from Marcin Kowalczyk <qrczakmk(a)gmail.com>:
The documentation is silent whether PyUnicode_AsUTF8AndSize() or PyUnicode_AsUTF8String() is preferred.
We are under the assumption that both are acceptable for the given caller, i.e. the caller wants to access just the sequence of UTF-8 code units (e.g. for calling a C++ function which takes std::string_view or std::string as a parameter), and the caller either will copy the UTF-8 code units immediately or is willing to own a temporary object to ensure a lifetime of the UTF-8 code units.
File comments in unicodeobject.h about PyUnicode_AsUTF8AndSize() have a warning:
*** This API is for interpreter INTERNAL USE ONLY and will likely
*** be removed or changed in the future.
*** If you need to access the Unicode object as UTF-8 bytes string,
*** please use PyUnicode_AsUTF8String() instead.
The discrepancy between these comments and the documentation should be fixed. Either the documentation is correct and the comment is outdated, or the comment is correct and the documentation is lacking guidance.
It is not even clear which function is better technically:
- PyUnicode_AsUTF8String() always allocates the string. PyUnicode_AsUTF8AndSize() does not allocate the string if the unicode object is ASCII-only (this is common) or if PyUnicode_AsUTF8AndSize() was already called before.
- If conversion must be performed, then PyUnicode_AsUTF8String() makes a single allocation, while PyUnicode_AsUTF8AndSize() first calls PyUnicode_AsUTF8String() and then copies the string.
- If the string is converted multiple times, then PyUnicode_AsUTF8AndSize() caches the result - faster. If the string is converted once, then the result persists as long as the string persists - wastes memory.
I see the following possible resolutions:
1a. Declare both functions equally acceptable. Remove comments claiming that PyUnicode_AsUTF8AndSize() should be avoided.
1b. 1a, and change the implementation of PyUnicode_AsUTF8AndSize() to avoid allocating the string twice if it needs to be materialized, so that PyUnicode_AsUTF8AndSize() is never significantly slower than PyUnicode_AsUTF8String().
2a. Declare PyUnicode_AsUTF8String() preferred. Indicate this in the documentation.
2b. 2a, and provide a public interface to check and access UTF-8 code units without allocating a new string in case this is possible (I think PyUnicode_READY() + PyUnicode_IS_ASCII() + PyUnicode_DATA() + PyUnicode_GET_LENGTH() would work, but they are not documented; or possibly also check if the string has a cached UTF-8 representation without populating that cached representation), so that a combination of the check with PyUnicode_AsUTF8String() is rarely or never significantly slower than PyUnicode_AsUTF8AndSize().
----------
assignee: docs@python
components: Documentation, Interpreter Core, Unicode
messages: 330249
nosy: Marcin Kowalczyk, docs@python, ezio.melotti, vstinner
priority: normal
severity: normal
status: open
title: Please clarify whether PyUnicode_AsUTF8AndSize() or PyUnicode_AsUTF8String() is preferred
type: performance
versions: Python 3.8
_______________________________________
Python tracker <report(a)bugs.python.org>
<https://bugs.python.org/issue35295>
_______________________________________
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 Steven D'Aprano <steve+python(a)pearwood.info>:
(Apologies if this is the wrong place for reporting website bugs.)
The website is not rendering doctest directives or comments, either that or the comments have been stripped from the examples.
On the doctest page itself, all the comments are missing:
https://docs.python.org/3/library/doctest.html#directives
The first example says:
>>> print(list(range(20)))
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9,
10, 11, 12, 13, 14, 15, 16, 17, 18, 19]
but without the directive, the test would fail. Screen shot attached.
Doctest directives are also missing from here:
https://docs.python.org/3/library/ctypes.html
My browser: Firefox 45.1.1
Also checked with text browser "lynx".
----------
assignee: docs@python
components: Documentation
files: missing_directives.png
messages: 340570
nosy: docs@python, steven.daprano
priority: normal
severity: normal
status: open
title: Doctest directives and comments not visible or missing from code samples
type: behavior
Added file: https://bugs.python.org/file48277/missing_directives.png
_______________________________________
Python tracker <report(a)bugs.python.org>
<https://bugs.python.org/issue36675>
_______________________________________