New submission from Roy Smith:
For background, see:
https://mail.python.org/pipermail/python-list/2014-August/676291.html
In a nutshell, the iglob() docs say, "Return an iterator which yields the same values as glob() without actually storing them all simultaneously." The problem is, internally, it calls os.listdir(), which apparently *does* store the entire list internally, defeating the whole purpose of iglob()
I recognize that iglob() is not going to get fixed in 2.7, but at least the documentation should be updated to point out that it doesn't really do what it says it does. Or rather, it doesn't really not do what it says it doesn't :-)
----------
assignee: docs@python
components: Documentation
messages: 225048
nosy: docs@python, roysmith
priority: normal
severity: normal
status: open
title: iglob() has misleading documentation (does indeed store names internally)
type: enhancement
versions: Python 2.7
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue22167>
_______________________________________
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 Jon Shemitz:
The tutorial says "Each value is an object, and therefore has a class (also called its type). It is stored as object.__class__."
So, I tried
>>> 3.__class__
File "<stdin>", line 1
3.__class__
^
SyntaxError: invalid syntax
Yet, "foo".__class__ worked, as did 3j.__class__ and 3.5.__class__.
When my son (!) suggested that I try (3).__class__, I did indeed get <type 'int'>, while (3,).__class__ gave <type 'tuple'>.
This *looks like* a minor error in the parser, where seeing \d+\. puts it in a state where it expects \d+ and it can't handle \w+
This may be the sort of thing that only a newbie would even think to try, so may not be worth fixing. If so, it may be worth mentioning in the tutorial.
----------
assignee: docs@python
components: Documentation, Interpreter Core
messages: 211670
nosy: Jon.Shemitz, docs@python
priority: normal
severity: normal
status: open
title: Tutorial section 9.4
type: behavior
versions: Python 2.7
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue20692>
_______________________________________
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 bob gailer:
Inconsistencies / confusion with documentation Index Tab. Example (line numbers added for comments that follow):
1 max
2 built-in function
3 max (datetime.date attribute)
4 (datetime.datetime attribute)
5 (datetime.time attribute)
6 max() built-in function
7 (decimal.Context method)
8 (decimal.Decimal method)
9 (in module audioloop)
The following all lead to confusion and frustration:
Having 3 rows (1, 3, 6)that begin with max.
Having an entry (1) that does nothing when double-clicked.
double-clicking (2) takes us to a reference rather than a definition.
RECOMMENDATION:
change to:
max() built-in function
(sequence operation)
(decimal.Context method)
(decimal.Decimal method)
max
(datetime.date attribute)
(datetime.datetime attribute)
(datetime.time attribute)
where double-clicking the first line goes to the max() definition
in 2. Built-in Functions
These comments apply, with a number of variations, to most built-in functions index entries.
----------
assignee: docs@python
components: Documentation
messages: 217170
nosy: bgailer, docs@python
priority: normal
severity: normal
status: open
title: improve indexing
type: enhancement
versions: 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/issue21352>
_______________________________________
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 Frank van Dijk:
stackoverflow.com has a zillion answers recommending the use of codecs.open() as a unicode capable drop in replacement for open(). This probably means that there is still a lot of code being written that uses codecs.open(). That's bad thing because of codecs.open()'s lack of newline conversion. A lot of that code will
- have compatibility issues when it is moved between unix and windows
- silently break text files on windows, leading to issues further downstream (confusing other tools, messing up revision control histories)
The problem has been fixed with io.open() in 2.x and open() in 3.x. Unfortunately the 2.7 unicode HOWTO still recommends the use of codecs.open(). The 2.7 and the 3.x documentation of codecs.open() doesn't refer the reader to better alternatives.
The attached patches fix that.
The only downside I see is that newly written code that uses the better alternatives would be incompatible with 2.5 and older. However croaking on a small minority of systems is better than silently disrupting workflows, causing platform incompatibilities, and inviting flaky workarounds.
The 2.7 patch makes the unicode HOWTO recommend io.open() instead of codecs.open(). Both patches change the codecs.open() documentation to refer to io.open() or (on 3.x) open().
Additionally I removed the "data loss" explanation from codecs.open()'s note about its lack of newline conversion. It is not particularly helpful information and it is not entirely correct (data loss could also have been avoided by doing newline conversion before encoding and after decoding)
----------
assignee: docs@python
components: Documentation
files: codecsopen2.patch
keywords: patch
messages: 224632
nosy: Frank.van.Dijk, docs@python
priority: normal
severity: normal
status: open
title: patch: steer people away from codecs.open
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36234/codecsopen2.patch
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue22128>
_______________________________________
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 Daniel Andersson:
Regarding the `skipinitialspace` parameter to the different CSV reader dialects in the `csv` module, the official documentation asserts:
When True, whitespace immediately following the delimiter is ignored.
and the `help(csv)` style module documentation says:
* skipinitialspace - specifies how to interpret whitespace which
immediately follows a delimiter. It defaults to False, which
means that whitespace immediately following a delimiter is part
of the following field.
"Whitespace" is a bit too general in both cases (at least a red herring in the second case), since it only skips spaces and not e.g. tabs [1].
In `Modules/_csv.c`, it more correctly describes the parameter. At line 81:
int skipinitialspace; /* ignore spaces following delimiter? */
and the actual implementation at line 638:
else if (c == ' ' && dialect->skipinitialspace)
/* ignore space at start of field */
;
No-one will probably assume that the whole UTF-8 spectrum of "whitespace" is skipped, but at least I initially assumed that the tab character was included.
[1]: http://en.wikipedia.org/wiki/Whitespace_character
----------
assignee: docs@python
components: Documentation, Library (Lib)
messages: 216780
nosy: Daniel.Andersson, docs@python
priority: normal
severity: normal
status: open
title: skipinitialspace in the csv module only skips spaces, not "whitespace" in general
type: behavior
versions: 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/issue21297>
_______________________________________
