Mailman 3 October 2011 - docs

[issue12842] Docs: first parameter of tp_richcompare() always has the correct type
by Stefan Krah July 3, 2014

July 3, 2014

New submission from Stefan Krah <stefan-usenet(a)bytereef.org>: I've noticed that assumptions about the operand types in tp_richcompare() are not always consistent. As far as I can see, the first parameter in tp_richcompare() is guaranteed to be of the correct type. But in some places the first parameter's type is still checked: Objects/cellobject.c: if (!PyCell_Check(a) || !PyCell_Check(b)) { The attached patch makes it clear that the first parameter has the correct type. ---------- assignee: docs@python components: Documentation files: tp_richcompare.diff keywords: patch messages: 142991 nosy: docs@python, skrah priority: normal severity: normal status: open title: Docs: first parameter of tp_richcompare() always has the correct type type: feature request versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file23047/tp_richcompare.diff _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12842> _______________________________________

4 3

[issue11389] unittest: no way to control verbosity of doctests from cmd
by anatoly techtonik July 2, 2014

July 2, 2014

New submission from anatoly techtonik <techtonik(a)gmail.com>: I can't find a way to execute DocTests contained in a separate README.txt file using unittest.main() function. That doesn't allow to control verbosity for debugging. I am doing it this way in the tests.py import doctest import unittest if __name__ == '__main__': runner = unittest.TextTestRunner() runner.run(doctest.DocFileSuite('README.txt', optionflags=doctest.ELLIPSIS)) I could find a way to subclass TestLoader.loadTestsFromNames() by looking at the source code of undocumented TestProgram. I'd like to see this use case at least covered by documentation if not properly developed for stdlib of Python4. ---------- assignee: docs@python components: Documentation, Tests messages: 130001 nosy: docs@python, techtonik priority: normal severity: normal status: open title: unittest: no way to control verbosity of doctests from cmd _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue11389> _______________________________________

4 6

[issue11762] Ast doc: warning and version number
by Terry J. Reedy June 30, 2014

June 30, 2014

New submission from Terry J. Reedy <tjreedy(a)udel.edu>: Two related proposals. 1. Add a warning similar to the one for the dis module. As modified: "CPython implementation detail: The ast definition is specific to the CPython interpreter! Ast nodes may be added, removed, or changed between versions. Use *ast.__version__* to work across versions." I omitted " Use of this module should not be considered to work across Python VMs or Python releases." as redundant and too legalistic. *ast.__version__* should link to its (new) entry). 2. Add a full entry for __version__. Currently (3.2): "The module defines a string constant __version__ which is the decimal Subversion revision number of the file shown below." Proposed replacement (with hidden reference point): ast.__version__ [__version__ in normal entry boldface] String constant with version number of abstract grammar file. 3.1: 67616; 3.2: 82163; 3.3: xxxxxxxxx ---------- assignee: docs@python components: Documentation messages: 132951 nosy: docs@python, terry.reedy priority: normal severity: normal stage: needs patch status: open title: Ast doc: warning and version number versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue11762> _______________________________________

6 9

[issue11385] TextTestRunner methods are not documented
by anatoly techtonik June 27, 2014

June 27, 2014

New submission from anatoly techtonik <techtonik(a)gmail.com>: TextTestRunner has a run method, which is not documented. It is also is not clear how to add suite to TextTestRunner to be executed later by unittest.main() ---------- assignee: docs@python components: Documentation, Tests messages: 129988 nosy: docs@python, techtonik priority: normal severity: normal status: open title: TextTestRunner methods are not documented versions: Python 2.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue11385> _______________________________________

6 10

[issue12617] Mutable Sequence Type can work not only with iterable in slice[i:j] = t
by py.user June 14, 2014

June 14, 2014

New submission from py.user <port139(a)yandex.ru>: 1) 4.6.4 Mutable Sequence Types | s[i:j] = t | slice of s from i to j is replaced | | | by the contents of the iterable t | >>> lst = list('abc') >>> barr = bytearray(b'abc') >>> lst[:1] = 4 Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: can only assign an iterable >>> barr[:1] = 4 >>> barr bytearray(b'\x00\x00\x00\x00bc') >>> there is no info about this feature in the documentation 2) 4.6.4 Mutable Sequence Types | s.extend(x) | same as s[len(s):len(s)] = x | >>> lst = list('abc') >>> barr = bytearray(b'abc') >>> lst.extend(4) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: 'int' object is not iterable >>> barr.extend(4) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: 'int' object is not iterable >>> lst[len(lst):len(lst)] = 4 Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: can only assign an iterable >>> barr[len(barr):len(barr)] = 4 >>> barr bytearray(b'abc\x00\x00\x00\x00') >>> barr.extend(x) != barr[len(barr):len(barr)] = x ---------- assignee: docs@python components: Documentation, Interpreter Core messages: 140924 nosy: docs@python, py.user priority: normal severity: normal status: open title: Mutable Sequence Type can work not only with iterable in slice[i:j] = t type: behavior versions: Python 3.1 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12617> _______________________________________

6 5

[issue10503] os.getuid() documentation should be clear on what kind of uid it is referring
by Giampaolo Rodola' June 7, 2014

June 7, 2014

New submission from Giampaolo Rodola' <g.rodola(a)gmail.com>: http://docs.python.org/library/os.html#os.getuid os.getuid() documentation just states: > Return the current process’s user id. It is not clear, however, whether "user id" refers to real, effective or saved user id. As per: http://linux.about.com/library/cmd/blcmdl2_getuid.htm ...it should refer to _real_ user id. ---------- assignee: docs@python components: Documentation messages: 122117 nosy: docs@python, giampaolo.rodola priority: normal severity: normal status: open title: os.getuid() documentation should be clear on what kind of uid it is referring versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10503> _______________________________________

5 6

[issue13030] Be more generic when identifying the Windows main dir in installation doc
by Sandro Tosi May 6, 2014

May 6, 2014

New submission from Sandro Tosi <sandro.tosi(a)gmail.com>: Given I have no knowledge of the windows system, I'm just proxying http://mail.python.org/pipermail/docs/2011-September/005793.html : >>> Under: http://docs.python.org/install/index.html#inst-how-install-works It notes "Windows prefix\Lib\site-packages C:\PythonXY\Lib\site-packages" for default values on Windows. In the paragraph following the table is the text: "prefix and exec-prefix stand for the directories that Python is installed to, and where it finds its libraries at run-time. They are always the same under Windows, and very often the same under Unix and Mac OS X. " I don't know if it's hardcoded into Python distributions to use C, but it's not correct. The correct way to identify what most people think of as C is via the %SYSTEMROOT% environment variable, so the path described would be "%SYSTEMROOT%\PythonXY\Lib\site-packages" (This is still not the correct way to do things on Windows, but it at least shouldn't break on systems with a %SYSTEMROOT% other than C. I've seen configurations like that on systems which boot multiple versions of Windows.) <<< ---------- assignee: docs@python components: Documentation messages: 144422 nosy: brian.curtin, docs@python, sandro.tosi, tim.golden priority: normal severity: normal stage: needs patch status: open title: Be more generic when identifying the Windows main dir in installation doc type: behavior versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13030> _______________________________________

4 5

[issue9307] Py_TPFLAGS_LONG_SUBCLASS is not documented
by Alexander Belopolsky April 28, 2014

April 28, 2014

New submission from Alexander Belopolsky <belopolsky(a)users.sourceforge.net>: Is there a reason for not documenting Py_TPFLAGS_LONG_SUBCLASS (Py_TPFLAGS_INT_SUBCLASS in 2.x)? This flag is used in PyLong_Check, but neither this flag or its inheritance properties are explained anywhere in the docs. See also issue5476. ---------- assignee: docs@python components: Documentation messages: 110787 nosy: belopolsky, docs@python priority: normal severity: normal stage: needs patch status: open title: Py_TPFLAGS_LONG_SUBCLASS is not documented type: feature request _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue9307> _______________________________________

6 8

[issue9364] some problems with the documentation of pydoc
by Eli Bendersky April 19, 2014

April 19, 2014

New submission from Eli Bendersky <eliben(a)gmail.com>: The first paragraph in its documentation says: """ In the Python interpreter, do "from pydoc import help" to provide online help. Calling help(thing) on a Python object documents the object. """ Which is no longer accurate, because the help() function has long ago become a built-in. Below is an excerpt from Terry Reedy in a private email discussion on this subject, that raises more issues. --------------------------------------------- 1. The output from help(help) could be made more clear. The nature of 'help' has been a point of confusion. A recent python-list post asked something like "What is 'help'?" Now (with some parallel examples: >>> help(int) Help on class int in module builtins: class int(object) [snip] >>> help(1) Help on int object: class int(object) [snip] >>> help(help) Help on _Helper in module site object: class _Helper(builtins.object) | Define the built-in 'help'. | This is a wrapper around pydoc.help (with a twist). | | Methods defined here: | | __call__(self, *args, **kwds) | a. 'module site object' is nonsense, it should just be 'module site', except that to be parallel to what is done for other instances, it should be 'Help on _Helper object'. Why should help special-case itself (with a slightly garbled line?) Is that done in site._Helper or pydoc.help? However, it would be more helpful for all instances to give the location of the class when one asks for help on an instance, just as when one asks for help on the class itself. It is annoying to to have to repeat help(<classname>) just to get that info. So I would like to see "Help on instance of class int in module builtins:" "Help on instance of class _Helper in module site:" This would be a code patch to pydoc.help b. "This is a wrapper around pydoc.help" good so far "(with a twist)" thanks a lot. I think the comment should be either removed or explained. A reference manual should explain, not tease. Replace "Define the built-in 'help'." with something clearer and more accurate, such as "The name 'help' is injected in module builtins after being bound to an instance of this class.". Put this after, not before, the 'wrapper' line. A patch for site._Helper doc string. 2. Improve manual chapter for site module. a. It currently starts "Importing this module will append site-specific paths to the module search path." Add "inject 'help' into builtins and " after append. Then add a short explanation paragraph before the search path stuff. Something like "This module contains a class (_Helper) that wraps function pydoc.help. An instance of the class is bound to name 'help' in the builtins module." A recent discussion on pydev or maybe python-list (in the thread mentioned above?) implied that one could usefully make another instance of _Helper or maybe a subclass thereof. I did not pay enough attention, though, to really get it. b. It currently ends with "XXX Update documentation XXX document python -m site –user-base –user-site" ---------- assignee: docs@python components: Documentation messages: 111426 nosy: docs@python, eli.bendersky, tjreedy priority: normal severity: normal status: open title: some problems with the documentation of pydoc type: behavior versions: Python 3.1, Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue9364> _______________________________________

9 21

[issue10481] subprocess PIPEs are byte streams
by Glenn Linderman April 14, 2014

April 14, 2014

New submission from Glenn Linderman <v+python(a)g.nevcal.com>: While http://bugs.python.org/issue2683 did clarify the fact that the .communicate API takes a byte stream as input, it is easy to miss the implication. Because Python programs start up with stdin as a text stream, it might be good to point out that some action may need to be taken to be sure that the receiving program expects a byte stream, or that the byte stream supplied should be in an encoding that the receiving program is expecting and can decode appropriately. No mention is presently made in the documentation for .communicate that its output is also a byte stream, and if text will correspond to whatever encoding is used by the sending program. ---------- assignee: docs@python components: Documentation messages: 121869 nosy: docs@python, v+python priority: normal severity: normal status: open title: subprocess PIPEs are byte streams versions: Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10481> _______________________________________

4 5