Mailman 3 November 2014 - docs

[issue8350] Document lack of support for keyword arguments in C functions
by Yongzhi Pan 03 Nov '14

03 Nov '14

Changes by Yongzhi Pan <panyongzhi(a)gmail.com>: ---------- nosy: +fossilet _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue8350> _______________________________________

1 0

Re: [docs] There is no standard TestCase.runTest implementation (issue 22153)
by robertc＠robertcollins.net 03 Nov '14

03 Nov '14

http://bugs.python.org/review/22153/diff/12734/Doc/library/unittest.rst File Doc/library/unittest.rst (right): http://bugs.python.org/review/22153/diff/12734/Doc/library/unittest.rst#new… Doc/library/unittest.rst:657: In most uses of :class:`TestCase`, you will neither change On 2014/10/31 18:00:26, ezio.melotti wrote: > This line is indented wrong. I can fix this up at commit time. http://bugs.python.org/review/22153/diff/12734/Doc/library/unittest.rst#new… Doc/library/unittest.rst:1561: If no methods with the usual name prefix are found, but the ``runTest()`` method is implemented, there will be a single test case using that method. On 2014/10/31 18:00:26, ezio.melotti wrote: > This line is too long, and also not too clear to me. > What is the usual name prefix? "test_"? > Does "a single test case" refers to *testCaseClass*? What are test cases should > use runTest? What does "using" mean here? TestClass('runTest') rather than TestClass('test_something'). It seems clear enough to me, but I am probably too close to the implementation. Do you have some suggested improvement to the prose? The name prefix is indeed test_, but thats covered elsewhere I think. http://bugs.python.org/review/22153/

1 0

improve documentation for enumerate() (built-in function) (issue 22725)
by ezio.melotti＠gmail.com 03 Nov '14

03 Nov '14

http://bugs.python.org/review/22725/diff/13194/Doc/library/functions.rst File Doc/library/functions.rst (right): http://bugs.python.org/review/22725/diff/13194/Doc/library/functions.rst#ne… Doc/library/functions.rst:361: Return an enumerate object which when :term`iterated <iterable>` yields a "which when iterated" sounds a bit weird to me. Would it be better if commas were added before and after "when iterated"? The link to "iterable" could also be moved to "enumerate object", even though it might be somewhat misleading if one expects it to link to the documentation of the actual enumerate object. http://bugs.python.org/review/22725/

1 0

[issue21759] URL Typo in Documentation FAQ
by are-you-watching-closely 03 Nov '14

03 Nov '14

New submission from are-you-watching-closely: Under this question (https://docs.python.org/2/faq/programming.html#my-program-is-too-slow-how-d…) in the 2.7 programming FAQ, it gives a link to an anecdote that Guido van Rossum wrote. The URL it gives: http://www.python.org/doc/essays/list2str.html The correct URL (no .html): http://www.python.org/doc/essays/list2str I'm sure there are some people who didn't think to remove the '.html', and couldn't find the story. Just a quick typo fix. ---------- assignee: docs@python components: Documentation messages: 220575 nosy: are-you-watching-closely, docs@python priority: normal severity: normal status: open title: URL Typo in Documentation FAQ versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue21759> _______________________________________

5 5

[issue22344] Reorganize unittest.mock docs into linear manner
by py.user 02 Nov '14

02 Nov '14

New submission from py.user: Now, it's very inconvenient to learn this documentation. It's not compact (could be reduced in 2 or even 3 times). It repeats itself: many examples copy-pasted unchangeably. And it cites to terms that placed under those cites, so people should start at the bottom to anderstand what it's talking about on the top. Remember Zen "If the implementation is hard to explain, it's a bad idea." - Move the MagicMock description to the point between Mock and PropertyMock descriptions - Remove "copy-paste" examples - Rename print to print() and StringIO to io - Split the Autospecing section to several chunks ---------- assignee: docs@python components: Documentation messages: 226456 nosy: docs@python, py.user priority: normal severity: normal status: open title: Reorganize unittest.mock docs into linear manner type: enhancement versions: Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue22344> _______________________________________

4 3

[issue22388] Unify style of "Contributed by" notes
by Serhiy Storchaka 02 Nov '14

02 Nov '14

New submission from Serhiy Storchaka: Here is a patch which converts "Contributed by" notes in whatsnews to most prevalent style. This means: * Previous sentence ends by a period and the "Contributed" is titled. * The note ends by a period and it is placed before closing parent. * The note is separated from previous sentence by two spaces or newline (as any sentences). Overwhelming majority of "Contributed by" notes are written in this style (except of unfinished 3.5 whatsnews). ---------- assignee: docs@python components: Documentation files: doc_contributed_by_style.patch keywords: patch messages: 226767 nosy: docs@python, r.david.murray, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Unify style of "Contributed by" notes type: enhancement versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file36598/doc_contributed_by_style.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue22388> _______________________________________

5 7

[issue22525] ast.literal_eval() doesn't do what the documentation says
by Ezio Melotti 02 Nov '14

02 Nov '14

Changes by Ezio Melotti <ezio.melotti(a)gmail.com>: ---------- nosy: +ezio.melotti stage: -> patch review type: -> enhancement _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue22525> _______________________________________

1 0

Re: [docs] open() declared deprecated in python 3 docs (issue 22695)
by berker.peksag＠gmail.com 02 Nov '14

02 Nov '14

http://bugs.python.org/review/22695/diff/13186/Doc/tools/extensions/pyspeci… File Doc/tools/extensions/pyspecific.py (right): http://bugs.python.org/review/22695/diff/13186/Doc/tools/extensions/pyspeci… Doc/tools/extensions/pyspecific.py:182: node[0].insert(0, nodes.inline('', '%s: ' % text, On 2014/11/01 20:54:30, storchaka wrote: > Should not this line be unindented? Done. http://bugs.python.org/review/22695/

1 0

Re: [docs] open() declared deprecated in python 3 docs (issue 22695)
by berker.peksag＠gmail.com 01 Nov '14

01 Nov '14

http://bugs.python.org/review/22695/diff/13186/Doc/tools/extensions/pyspeci… File Doc/tools/extensions/pyspecific.py (right): http://bugs.python.org/review/22695/diff/13186/Doc/tools/extensions/pyspeci… Doc/tools/extensions/pyspecific.py:182: node[0].insert(0, nodes.inline('', '%s: ' % text, On 2014/11/01 20:54:30, storchaka wrote: > Should not this line be unindented? Good catch! Will update the patch. Thanks. http://bugs.python.org/review/22695/

1 0

open() declared deprecated in python 3 docs (issue 22695)
by storchaka＠gmail.com 01 Nov '14

01 Nov '14

http://bugs.python.org/review/22695/diff/13186/Doc/tools/extensions/pyspeci… File Doc/tools/extensions/pyspecific.py (right): http://bugs.python.org/review/22695/diff/13186/Doc/tools/extensions/pyspeci… Doc/tools/extensions/pyspecific.py:182: node[0].insert(0, nodes.inline('', '%s: ' % text, Should not this line be unindented? http://bugs.python.org/review/22695/

1 0