Mailman 3 December 2010 - docs

[issue10676] Confusing note in Numeric Types
by Philip Bober Dec. 11, 2010

Dec. 11, 2010

New submission from Philip Bober <pdbober(a)gmail.com>: In the Python Standard Library reference, section 5.4: Numeric Types, the table of operators/functions has the following unclear note: (4)Complex floor division operator, modulo operator, and divmod(). Deprecated since version 2.3: Instead convert to float using abs() if appropriate. The intention of this note is to indicate that //,%, and divmod shouldn't be used with complex numbers, but the phrasing is bad and the note being on generic operators makes it sound like the operators themselves are deprecated, not just for complex numbers. There was an earlier bugfix (621708, on the previous tracker. Archive: http://mail.python.org/pipermail/python-bugs-list/2002-October/013913.html) which fixed this bad wording elsewhere in the docs (Section 5.6 Binary arithmetic operations in the Python Reference Manual) but it seems the same wording was in both documents and it was only patched in one of them. It was replaced with: "Deprecated since version 2.3: The floor division operator, the modulo operator, and the divmod() function are no longer defined for complex numbers. Instead, convert to a floating point number using the abs() function if appropriate." ---------- assignee: docs@python components: Documentation messages: 123750 nosy: Philip.Bober, docs@python priority: normal severity: normal status: open title: Confusing note in Numeric Types versions: Python 2.5, Python 2.6, Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10676> _______________________________________

2 1

Bug on http://docs.python.org/tutorial/introduction.html#numbers
by Wonjohn Choi Dec. 11, 2010

Dec. 11, 2010

7/3 should result in the exact value. 7//3 will output a floor value.

2 1

[issue10669] Document Deprecation Warnings and how to fix
by Ezio Melotti Dec. 11, 2010

Dec. 11, 2010

Ezio Melotti <ezio.melotti(a)gmail.com> added the comment: The deprecation notes in the doc should be quite easy to find and can be more verbose, but there are a few cases where the deprecation is not about a specific function but something more "abstract" (e.g. some syntax change, or the "Overriding __eq__ blocks inheritance of __hash__ in 3.x" reported by the OP). Listing new deprecations in the what's new it's a good idea, but otherwise a clear message (that also suggests how to fix the problem) and a deprecation note in the doc (using the '.. deprecated::' directive) should be enough. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10669> _______________________________________

1 0

[issue10669] Document Deprecation Warnings and how to fix
by Terry J. Reedy Dec. 10, 2010

Dec. 10, 2010

Terry J. Reedy <tjreedy(a)udel.edu> added the comment: The issue is not the specific warnings Rusi got but how, in general, one can get more information when the warnings are too cryptic to deal with. One response might be that DeprecationWarnings should be much wordier than they are -- a paragraph of a few sentences rather than just a minimal sentence. Another might be that each release have a HOW-TO doc or What's New section with a paragraph for each one added to that release. Currently, information is scattered among pydev posts, tracker issues, commit messages, News entries, and maybe What's new. ---------- nosy: +rhettinger, terry.reedy title: Remove Deprecation Warnings -> Document Deprecation Warnings and how to fix versions: +Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10669> _______________________________________

1 0

[issue10669] Remove Deprecation Warnings
by Ezio Melotti Dec. 10, 2010

Dec. 10, 2010

Changes by Ezio Melotti <ezio.melotti(a)gmail.com>: ---------- assignee: -> docs@python components: +Documentation nosy: +docs@python, ezio.melotti _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10669> _______________________________________

1 0

[issue10672] ["with"] new in version 2.6 instead of 2.5
by Mayweed Dec. 10, 2010

Dec. 10, 2010

New submission from Mayweed <norman.denayer(a)atosorigin.com>: In the documentation, the statement "with" is marked as: "New in version 2.5." (http://docs.python.org/reference/compound_stmts.html#the-with-statement) This new statement is new in version 2.6 ! ---------- assignee: docs@python components: Documentation messages: 123731 nosy: docs@python, karmaguedon priority: normal severity: normal status: open title: ["with"] new in version 2.6 instead of 2.5 versions: Python 2.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10672> _______________________________________

2 1

[issue10658] Link to source code is broken
by anatoly techtonik Dec. 9, 2010

Dec. 9, 2010

New submission from anatoly techtonik <techtonik(a)gmail.com>: http://docs.python.org/library/queue.html ---------- assignee: docs@python components: Documentation messages: 123677 nosy: docs@python, techtonik priority: normal severity: normal status: open title: Link to source code is broken versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10658> _______________________________________

2 1

[issue10546] UTF-16-LE and UTF-16-BE support non-BMP characters
by STINNER Victor Dec. 8, 2010

Dec. 8, 2010

New submission from STINNER Victor <victor.stinner(a)haypocalc.com>: Python3 doc tells that UTF-16-LE and UTF-16-BE only support BMP characters. What? I think that it is wrong. It was maybe wrong with Python2 and narrow build (unichr() only supports BMP characters), but it is no more true in Python3. ---------- assignee: docs@python components: Documentation files: utf_16_bmp.patch keywords: patch messages: 122479 nosy: docs@python, haypo priority: normal severity: normal status: open title: UTF-16-LE and UTF-16-BE support non-BMP characters versions: Python 3.1, Python 3.2 Added file: http://bugs.python.org/file19830/utf_16_bmp.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10546> _______________________________________

3 7

[issue10545] remove or rewrite "Using Backslash to Continue Statements" anti-idiom
by rurpy the second Dec. 8, 2010

Dec. 8, 2010

New submission from rurpy the second <rurpy(a)yahoo.com>: The Python HOWTOs->Idioms and Anti-Idioms has a section "Using Backslash to Continue Statements". It says that line continuation is "dangerous" and gives two reasons. 1. Hard to see a space after the backslash. This is not "dangerous" as it cause an impossible-to-miss syntax error (as pointed out in the following sentence.) 2. It can cause other "subtle" errors. It gives a code example purporting to demonstrate this but without saying what the input data to the code is or what the resulting problem is. I spent a while trying to figure it out unsuccessfully. In http://www.mail-archive.com/python-list@python.org/msg249344.html a number of c.l.p regulars did not figure it out either. I also note related bug http://bugs.python.org/issue7391 that points out that avoinding backslashed continuations with parens is not always possible. So I suggest... 1. If the the given example actually illustrates a real problem, document clearly what it is. This is a reference manual, not a quiz book. 2. If not, then remove that argument. Now the only reason for not using backslashes is that a hard-to-see space after the backslash will cause a syntax error. That is neither dangerous or a strong reason not to do it. An unstated reason is that PEP-8 recommends against it but its recommendation is not absolute and is based only on aethtetics. With no real arguments against using it other than style, it should not be documented as an anti-idiom, recommendations against it should remain only in PEP-8 with other such style guidelines, and this section should be removed from the Anti-Idioms chapter. ---------- assignee: docs@python components: Documentation messages: 122477 nosy: docs@python, rurpy2 priority: normal severity: normal status: open title: remove or rewrite "Using Backslash to Continue Statements" anti-idiom _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10545> _______________________________________

2 1

[issue8910] Write a text file explaining why Lib/test/data exists
by Martin v. Löwis Dec. 5, 2010

Dec. 5, 2010

Martin v. Löwis <martin(a)v.loewis.de> added the comment: All README files are automatically packages, and so is this one. ---------- status: open -> closed _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue8910> _______________________________________

1 0