Mailman 3 October 2011 - docs

[issue13139] multiprocessing.map skips finally blocks
by Antoine Pitrou 15 Oct '11

15 Oct '11

Antoine Pitrou <pitrou(a)free.fr> added the comment: As mentioned in http://docs.python.org/dev/library/multiprocessing#multiprocessing.pool.Asy… “If the remote call raised an exception then that exception will be reraised by get().” map() is just map_async() followed by a get() call on the result. Also, worker processes are called in daemon mode, which explains that children get killed as soon as the parent exits. If you rephrase your example as: try: Pool(3).map(Process, ['1','2','3']) finally: sleep(1) then all the children's finally clauses get a chance to be executed before the parent exits. I would therefore call it "not a bug", although you might add a sentence in the map() documentation stating that an exception is raised as soon as one of the worker fails. ---------- assignee: -> docs@python components: +Documentation nosy: +docs@python, pitrou _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13139> _______________________________________

1 0

[issue13171] Bug in file.read(), can access unknown data.
by Terry J. Reedy 15 Oct '11

15 Oct '11

Terry J. Reedy <tjreedy(a)udel.edu> added the comment: This issue has come up enough (tracker and python-list) that I think adding a mild adaptation of the C standard paragraph might be a good idea. Changing to a doc issue. ---------- assignee: -> docs@python components: +Documentation -IO, Library (Lib), Windows nosy: +docs@python, terry.reedy _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13171> _______________________________________

1 0

[issue13176] Broken link in bugs.rst
by Berker Peksag 14 Oct '11

14 Oct '11

New submission from Berker Peksag <berker.peksag(a)gmail.com>: http://www.python.org/dev/workflow/ is missing in 3.2 documentation. See: http://docs.python.org/py3k/bugs.html It works with latest version of the documentation: http://docs.python.org/dev/bugs.html ---------- assignee: docs@python components: Documentation files: broken_link_v1.patch keywords: patch messages: 145499 nosy: berkerpeksag, docs@python priority: normal severity: normal status: open title: Broken link in bugs.rst versions: Python 3.2 Added file: http://bugs.python.org/file23402/broken_link_v1.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13176> _______________________________________

3 4

[issue12602] Missing cross-references in Doc/using
by Éric Araujo 14 Oct '11

14 Oct '11

Éric Araujo <merwok(a)netwok.org> added the comment: BTW, I’ve done nothing about #1739468 because I don’t see why you wanted to add a link. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12602> _______________________________________

1 0

[issue12602] Missing cross-references in Doc/using
by Éric Araujo 14 Oct '11

14 Oct '11

Éric Araujo <merwok(a)netwok.org> added the comment: [Terry] > It may suggest a meta-issue though - perhaps 'Documenting Python' > should grow a devguide-style description of the Docs layout in source > control I would just describe the layout of the Doc subtree in the same devguide page. Care to open another bug for that? > If we consistently applied the "italicize non-literal symbolic parameter names" > rule to command line examples, we would italicize 'command', 'module-name', > 'script', and 'args' in > > python [-BdEiOQsStuUvVWxX3?] [-c command | -m module-name | script | - ] [args] > > just like in function signatures. I actually would like that as it would > similarly diffentiate them from the literal constants meant to be entered as > written. Has that ever been discussed by the doc group? Not that I recall. Currently the “python [-Bd etc.]” line is currently a code block, and as such cannot gain inline markup (:file:), but this is not insurmountable. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12602> _______________________________________

1 0

[issue12602] Missing cross-references in Doc/using
by Éric Araujo 14 Oct '11

14 Oct '11

Éric Araujo <merwok(a)netwok.org> added the comment: Attached path adds these links: > Missing incoming: > - from "Invoking the Interpreter" in the tutorial > - direct link from runpy.run_module to -m switch > Missing outgoing: > - direct link from <script> to runpy.run_path I couldn’t add this one: > - direct link from runpy.run_path to <script> I tried adding a standard reST link target (.. _using-on-script:) but that didn’t seem to work with the describe item. I added a link to the nearest heading instead, but maybe it is after all redundant: the seealso section of library/runpy already points to using/cmdline. ---------- keywords: +patch Added file: http://bugs.python.org/file23405/using-links.diff _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12602> _______________________________________

1 0

typo in argparse docs
by Joseph Reagle 13 Oct '11

13 Oct '11

"So, a single positional argument with dest='bar' will that argument will be referred to as bar." "So, a single positional argument with dest='bar' WITH that argument will be referred to as bar."

3 2

[issue13154] pep-0000.txt doesn't build anymore
by Antoine Pitrou 13 Oct '11

13 Oct '11

New submission from Antoine Pitrou <pitrou(a)free.fr>: $ make make: Dépendance circulaire pep-0000.txt <- pep-0000.txt abandonnée. python genpepindex.py . Traceback (most recent call last): File "genpepindex.py", line 67, in <module> main(sys.argv) File "genpepindex.py", line 64, in main write_pep0(peps, pep0_file) File "/home/antoine/cpython/peps/pep0/output.py", line 195, in write_pep0 authors_dict = verify_email_addresses(peps) File "/home/antoine/cpython/peps/pep0/output.py", line 104, in verify_email_addresses "listed:\n" + '\n'.join(err_output)) ValueError: some authors have more than one email address listed: Gregory Ewing: [u'greg(a)cosc.canterbury.ac.nz', u'greg.ewing(a)canterbury.ac.nz'] make: *** [pep-0000.txt] Erreur 1 ---------- assignee: docs@python components: Documentation messages: 145370 nosy: docs@python, pitrou priority: normal severity: normal status: open title: pep-0000.txt doesn't build anymore type: compile error _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13154> _______________________________________

3 4

[issue12602] Missing cross-references in Doc/using
by Terry J. Reedy 12 Oct '11

12 Oct '11

Terry J. Reedy <tjreedy(a)udel.edu> added the comment: Since *script* is a file -- that is all variable -- that seems appropriate. Bold italic tends to be more notably different from bold italic than the normal pair. In any case, italic is the doc standard for function parameter names. It seems more sensible than introducing a unique occurrence of angle brackets. An alternative is to simply delete the angle brackets. If we consistently applied the "italicize non-literal symbolic parameter names" rule to command line examples, we would italicize 'command', 'module-name', 'script', and 'args' in python [-BdEiOQsStuUvVWxX3?] [-c command | -m module-name | script | - ] [args] just like in function signatures. I actually would like that as it would similarly diffentiate them from the literal constants meant to be entered as written. Has that ever been discussed by the doc group? ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12602> _______________________________________

1 0

[issue12602] Missing cross-references in Doc/using
by Ezio Melotti 12 Oct '11

12 Oct '11

Ezio Melotti <ezio.melotti(a)gmail.com> added the comment: The italics parts are easier to recognize when they are within regular text (e.g. :file:`path/with/python{XY}/file`). If the whole text is in italic people might not notice the difference. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12602> _______________________________________

1 0