Mailman 3 September 2011 - docs

[issue12951] List behavior is different
by शंतनू 10 Sep '11

10 Sep '11

New submission from शंतनू <shantanoo(a)gmail.com>: URL: http://docs.python.org/library/stdtypes.html Following example is given. >>> lists = [[]] * 3 >>> lists [[], [], []] >>> lists[0].append(3) >>> lists [[3], [3], [3]] Behavior is as follows. >>> a = [[]] * 3 >>> a [[], [], []] >>> a[0] = 1 >>> a [1, [], []] >>> Python interpreter details: $ python Python 2.7.2 (default, Aug 22 2011, 13:53:27) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. ---------- assignee: docs@python components: Documentation messages: 143793 nosy: docs@python, शंतनू priority: normal severity: normal status: open title: List behavior is different type: behavior versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12951> _______________________________________

3 2

[issue12940] Cmd example using turtle left vs. right doc-bug
by Tim Chase 10 Sep '11

10 Sep '11

New submission from Tim Chase <python.list(a)tim.thechases.com>: The Turtle example for the cmd module as documented at http://docs.python.org/py3k/library/cmd.html#cmd-example In the left() method, it calls turtle.right() instead of turtle.left(). Easy fix: /def left/+2s/left/right/ Likely exists in most 3.x documentation. ---------- assignee: docs@python components: Documentation messages: 143746 nosy: Gumnos, docs@python priority: normal severity: normal status: open title: Cmd example using turtle left vs. right doc-bug type: behavior versions: Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12940> _______________________________________

4 7

[issue12902] help("modules") executes module code
by Ezio Melotti 10 Sep '11

10 Sep '11

Ezio Melotti <ezio.melotti(a)gmail.com> added the comment: > "Warning: gathering the results for the topic 'modules' can take > considerable time and have side effects as it imports *every* module > available to get at its doc string." http://docs.python.org/documenting/style.html#affirmative-tone ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12902> _______________________________________

1 0

[issue12902] help("modules") executes module code
by Terry J. Reedy 09 Sep '11

09 Sep '11

Terry J. Reedy <tjreedy(a)udel.edu> added the comment: The immediate issue is improvement of the entries for help and help(): In builtin functions section: Expand "Invoke the built-in help system." to "Invoke the built-in help system, which uses *pydoc*." where *pydoc* is linked to the pydoc section. Add to the end of the entry something like "As needed, pydoc imports modules to get their doc strings." The special string 'modules' is not documented in the manual entry for help() itself. That is fine. It does appear in the longer text that appears for 'help()'. That text, where ever it is, could and should have a warning. "Warning: gathering the results for the topic 'modules' can take considerable time and have side effects as it imports *every* module available to get at its doc string." A separate issue would be a feature request to not do that (assuming it really does). Given that 'modules' just produces a list of (incomplete) module names, I do not see the point of importing until one requests help on a particular name. There seems to be a bug. In a fresh 3.2.2 IDLE window, help('modules') produces about 300 names. If I repeat, I get a reduced list of 58 names. These seem to just be the builtin C-coded modules, like 'math', with all Python-coded modules, like 'random', omitted. ---------- assignee: -> docs@python components: +Documentation nosy: +docs@python, terry.reedy stage: -> needs patch versions: +Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12902> _______________________________________

1 0

[issue12896] Recommended location of the interpreter for Python 3
by Lennart Regebro 09 Sep '11

09 Sep '11

New submission from Lennart Regebro <regebro(a)gmail.com>: The documentation on Using Python, 2.3. Python-related paths and files says that "exec_prefix/bin/python" is the recommended location for the interpreter, while for Python 3 it's "exec_prefix/bin/python3". http://docs.python.org/py3k/using/unix.html#python-related-paths-and-files ---------- assignee: docs@python components: Documentation messages: 143508 nosy: docs@python, lregebro priority: normal severity: normal status: open title: Recommended location of the interpreter for Python 3 versions: Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12896> _______________________________________

3 3

[issue12779] Update packaging documentation
by Ezio Melotti 07 Sep '11

07 Sep '11

Ezio Melotti <ezio.melotti(a)gmail.com> added the comment: 1) sounds good; 2) would be fine too if it makes your life easier; 3) doesn't seem too useful. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12779> _______________________________________

1 0

[issue7798] Make generally useful pydoc functions public
by Éric Araujo 06 Sep '11

06 Sep '11

Éric Araujo <merwok(a)netwok.org> added the comment: I’ve looked hard at pydoc and opened distinct bug reports so that each piece of maybe-useful functionality can be discussed independently: #12918 New module for terminal utilities #12917 Make visiblename and allmethods functions public #12916 Add inspect.splitdoc #12915 Add inspect.locate and inspect.resolve #12914 Add cram function to textwrap ---------- resolution: -> invalid stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue7798> _______________________________________

1 0

[issue12906] Slight error in logging module's yaml config
by Derrick Petzold 06 Sep '11

06 Sep '11

New submission from Derrick Petzold <dpetzold(a)gmail.com>: Hello, format: format=%(asctime)s - %(name)s - %(levelname)s - %(message)s Should be: format: %(asctime)s - %(name)s - %(levelname)s - %(message)s Regards, btw I have to say the logging module is just excellent. What a truly great work. ty. ---------- assignee: docs@python components: Documentation messages: 143579 nosy: Derrick.Petzold, docs@python priority: normal severity: normal status: open title: Slight error in logging module's yaml config versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12906> _______________________________________

4 5

[issue12779] Update packaging documentation
by Éric Araujo 05 Sep '11

05 Sep '11

Éric Araujo <merwok(a)netwok.org> added the comment: To make commit review possible, I thought I’d make two patches for this: the first would be only markup fixes and minimal updates to match the reality of the code (i.e. convert setup.py examples to setup.cfg or pysetup, remove obsolete parts, etc.) and a second one with more rephrasing and reorganization (i.e. file deletions, moving chunks of docs, etc.). I’m not finished on the first patch and the diff already contains 1026 insertions and 921 deletions. So, as potential commit reviewers, do you think I should - 1) go ahead with my initial plan of a huge boring commit and a more interesting commit - 2) just make one commit - 3) one commit per file (with boring markup changes + non-boring changes) ---------- nosy: +ezio.melotti, sandro.tosi _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12779> _______________________________________

1 0

[issue11155] multiprocessing.Queue's put() signature differs from docs
by Erik Cederstrand 05 Sep '11

05 Sep '11

New submission from Erik Cederstrand <ec(a)1calendar.dk>: In Python 2.6.6 on OSX: >>> import inspect >>> from multiprocessing import Queue >>> q = Queue() >>> print(inspect.getargspec(q.put)) ArgSpec(args=['self', 'obj', 'block', 'timeout'], varargs=None, keywords=None, defaults=(True, None)) >>> from Queue import Queue >>> q = Queue() >>> print(inspect.getargspec(q.put)) ArgSpec(args=['self', 'item', 'block', 'timeout'], varargs=None, keywords=None, defaults=(True, None)) Notice the 'obj' argument in the multiprocessing version and the 'item' argument in the Queue version. I think 'obj' should be renamed to 'item' to be in line with the other implementation and to agree with the docs: (http://docs.python.org/library/multiprocessing.html?highlight=multiprocessi…): put(item[, block[, timeout]]) ---------- assignee: docs@python components: Documentation messages: 128200 nosy: Erik.Cederstrand, docs@python priority: normal severity: normal status: open title: multiprocessing.Queue's put() signature differs from docs versions: Python 2.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue11155> _______________________________________

6 14