Mailman 3 November 2013 - docs

bug in pydoc documentation
by don fong Nov. 13, 2013

Nov. 13, 2013

on this page, http://docs.python.org/2/library/pydoc.html, there is no mention of nor explanation of what a docstring is. there is no mention of what formatting conventions docstrings should follow in order for pydoc to work. if there's no single standard then the page should say so explicitly and give pointers to a few of the competing conventions.

1 0

[issue19290] Clarify compile and eval interaction.
by Terry J. Reedy Nov. 12, 2013

Nov. 12, 2013

New submission from Terry J. Reedy: This issue was stimulated by #17294 where there seems to be some confusion over the purpose of the compile modes with regards to return values. I then noticed that the eval doc starts wrong and later corrects itself. I think the following sentence from the compile doc could be improved. The current version: "The mode argument specifies what kind of code must be compiled; it can be 'exec' if source consists of a sequence of statements, 'eval' if it consists of a single expression, or 'single' if it consists of a single interactive statement (in the latter case, expression statements that evaluate to something other than None will be printed)." My suggestion: "The mode argument specifies the allowed source and the return value when the result is passed to eval(). It can be 'exec' for any source (a sequence of 0 to many statements); the return value will be None. It can be 'eval' if the source is a single expression; the return value will be the value of the expression. It can be 'single' if the source is a single non-empty interactive statement; the return value will be None, as with 'exec', but if the statement is an expression that evaluates to something other than None, the value will be printed." (#13677 is about changing the doc and docstring for the compile flags argument. Patches for that and this should be disjoint.) The eval(expression, ..) doc say that expression is a string. It much later says that it can also be a code object. I think the eval doc should follow the exec doc and call the first positional-only arg 'object' and then say the same thing: 'object must be either a string or a code object.' I don't have a complete suggested revision yet. ---------- assignee: docs@python components: Documentation messages: 200318 nosy: docs@python, terry.reedy priority: normal severity: normal stage: needs patch status: open title: Clarify compile and eval interaction. versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue19290> _______________________________________

2 1

[issue19560] PEP 8 operator precedence across parens
by Tom Lynn Nov. 12, 2013

Nov. 12, 2013

New submission from Tom Lynn: PEP 8 currently has:: Yes:: ... c = (a+b) * (a-b) No:: ... c = (a + b) * (a - b) That looks wrong to me -- surely the parens are a sufficient precedence hint, and don't need further squashing inside? This will be worse with any non-trivial example. I suspect it may also lead to silly complications in code formatting tools. This was changed by Guido as part of a reversion in issue 16239, but I wonder whether that example was intended to be included? ---------- assignee: docs@python components: Documentation messages: 202687 nosy: docs@python, tlynn priority: normal severity: normal status: open title: PEP 8 operator precedence across parens type: enhancement _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue19560> _______________________________________

4 5

[issue12828] xml.dom.minicompat is not documented
by Sandro Tosi Nov. 12, 2013

Nov. 12, 2013

New submission from Sandro Tosi <sandro.tosi(a)gmail.com>: There's no documentation for xml.dom.minicompat - it's a public module and it should have (even a brief) doc. ---------- assignee: docs@python components: Documentation messages: 142845 nosy: docs@python, sandro.tosi priority: normal severity: normal status: open title: xml.dom.minicompat is not documented versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12828> _______________________________________

3 3

[issue19539] The 'raw_unicode_escape' codec buggy + not appropriate for Python 3.x
by Marc-Andre Lemburg Nov. 11, 2013

Nov. 11, 2013

Marc-Andre Lemburg added the comment: Jan, the codec implements an encoding which has certain characteristics just like any other codec. It works both in Python 2 and 3 without problems. The documentation is no longer true, though. Ever since we added encoding markers to source files, the raw Unicode string literals depended on this encoding setting. Before this change the docs were fine, since Unicode literals were interpreted as Latin-1 encoded. More correct would be: "Produce a string that uses Unicode escapes to encode non-Latin-1 code points. It is used in the Python pickle protocol." ---------- nosy: +lemburg title: The 'raw_unicode_escape' codec buggy + not apropriate for Python 3.x -> The 'raw_unicode_escape' codec buggy + not appropriate for Python 3.x _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue19539> _______________________________________

1 0

[issue19539] The 'raw_unicode_escape' codec buggy + not apropriate for Python 3.x
by Serhiy Storchaka Nov. 11, 2013

Nov. 11, 2013

Changes by Serhiy Storchaka <storchaka(a)gmail.com>: ---------- components: -Library (Lib) nosy: -serhiy.storchaka stage: -> needs patch type: -> enhancement versions: -Python 3.2, Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue19539> _______________________________________

1 0

Global variables at the interpreter level?
by Michael Rothstein Nov. 11, 2013

Nov. 11, 2013

There seems to be a total disconnect between interpreter level variables and global variables. Is that correct? The attached code illustrates the issue: the global count changes values, but the interpreter level count remains steadfastly at 0. Also, it does not reset to 0 if I set: count = 0 at the interpreter level. Is this a bug or a feature, or am I doing something wrong? Thanks for the help! Michael Rothstein -- --------------------------------------------------------------------------- Michael Rothstein Ph D | Office (at 268 MSB) (330)-672-9065 Dept. of Computer Science | Fax: (330)-672-0737 Kent State University | Email: rothstei(a)cs.kent.edu PO Box 5190 | http://www.cs.kent.edu/~rothstei Kent, OH 44242-0001 | ---------------------------------------------------------------------------

1 0

2.7.6 release has a headline that says 2.6.9!!! Looks like a copy/paste error
by cclauss Nov. 11, 2013

Nov. 11, 2013

Python 2.6.9 released Python 2.7.6 is now available. Published: Sun, 10 November 2013, 02:30 -0500 Python 2.6.9 final available The final release of Python 2.6.9 (and the final release of the 2.6 series) is now available.

1 0

[issue19539] The 'raw_unicode_escape' codec buggy + not apropriate for Python 3.x
by Jan Kaliszewski Nov. 10, 2013

Nov. 10, 2013

Jan Kaliszewski added the comment: Which means that the description "Produce a string that is suitable as raw Unicode literal in Python source code" is (in Python 3.x) no longer true. So, if change/removal is not possible because of internal significance of the codec, I believe that the description should be changed to something like: "For internal use. This codec *does not* produce anything suitable as a raw string literal in Python 3.x source code." ---------- assignee: -> docs@python components: +Documentation nosy: +docs@python versions: +Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue19539> _______________________________________

1 0

little mistake in PEP 373
by Jean-Claude Arbaut Nov. 10, 2013

Nov. 10, 2013

Hello, I'm not sure it's the right place to post this, but on page http://www.python.org/dev/peps/pep-0373/ There is a mistake in the release date of 2.7.6, which is given as "2.7.6 2012-11-10" I'm not sure for the day (*), but the year is certainly wrong. Jean-Claude Arbaut (*) It's today, except in Alaska, where it's still saturday right know :-)

1 0