Mailman 3 November 2015 - docs

[issue25732] functools.total_ordering does not correctly implement not equal behaviour
by R. David Murray 25 Nov '15

25 Nov '15

Changes by R. David Murray <rdmurray(a)bitdance.com>: ---------- assignee: -> docs@python components: +Documentation nosy: +docs@python stage: -> needs patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue25732> _______________________________________

1 0

[issue25697] Fix rough alphabetical order in Misc/ACKS
by Serhiy Storchaka 25 Nov '15

25 Nov '15

New submission from Serhiy Storchaka: the list in Misc/ACKS is intended to be in rough alphabetical order by last names. But some lines breaks this order. Proposed patch restores ordering. It also removes duplicates for Richard Oudkerk. Correct sorting is not easy due to different letter order in different alphabets and different collation rules in different languages. I tried to take it into account, but can make a mistake. ---------- assignee: docs@python components: Documentation files: acks_order-3.6.patch keywords: patch messages: 255106 nosy: docs@python, georg.brandl, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Fix rough alphabetical order in Misc/ACKS Added file: http://bugs.python.org/file41125/acks_order-3.6.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue25697> _______________________________________

4 7

Docs.python.org/3/download.html no-go
by Marc Tofsted 25 Nov '15

25 Nov '15

Gentlemen, None of the links on this page are working today. Thanks for your help. Marc Tofsted

2 1

[issue25730] invisible sidebar content with code snippets
by Ezio Melotti 25 Nov '15

25 Nov '15

Changes by Ezio Melotti <ezio.melotti(a)gmail.com>: ---------- assignee: -> docs@python components: +Documentation nosy: +docs@python, ezio.melotti, georg.brandl, terry.reedy stage: -> needs patch type: -> behavior _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue25730> _______________________________________

1 0

Document that tp_setattro and tp_setattr are used for deleting attributes (issue 25701)
by victor.stinner＠gmail.com 25 Nov '15

25 Nov '15

http://bugs.python.org/review/25701/diff/16034/Doc/c-api/object.rst File Doc/c-api/object.rst (right): http://bugs.python.org/review/25701/diff/16034/Doc/c-api/object.rst#newcode… Doc/c-api/object.rst:72: otherwise set it to *v* (``o.attr_name = v``). Returns ``-1`` on failure. I know that it's not a common Python doc, but I prefer to explicitly say that an exception is raised in case of error. I suggest: Raise an exception and returns -1 on failure, return 0 on success. (Same change for other functions below) http://bugs.python.org/review/25701/diff/16034/Include/abstract.h File Include/abstract.h (right): http://bugs.python.org/review/25701/diff/16034/Include/abstract.h#newcode196 Include/abstract.h:196: (o.attr_name=v). Returns -1 on failure. Raise an exception and returns -1 on failure, return 0 on success. http://bugs.python.org/review/25701/

1 0

[issue20923] ConfigParser should nested [] in section names.
by STINNER Victor 25 Nov '15

25 Nov '15

STINNER Victor added the comment: > It would be good if ConfigParser supported angled brackets in section names by being greedy when parsing. I agree with Terry, it's the opposite: we must explicitly reject them to be compatible with other applications. Please move the discussion to issue #25723. ---------- nosy: +haypo resolution: -> fixed status: open -> closed _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue20923> _______________________________________

1 0

[issue10796] Improve doc for readline.set_completer_delims()
by Martin Panter 25 Nov '15

25 Nov '15

Martin Panter added the comment: I propose to address this with the general documentation bug, Issue 6953 ---------- dependencies: +readline documenation needs work nosy: +martin.panter title: readline completion flaw -> Improve doc for readline.set_completer_delims() _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10796> _______________________________________

1 0

[issue25576] Remove “Content-Type: application/x-www-form-urlencoded; charset” advice
by Martin Panter 24 Nov '15

24 Nov '15

New submission from Martin Panter: I understand using a “charset” parameter with “Content-Type: application/x-www-form-urlencoded” is not standardized. Since Issue 11082, the documentation advises to use it, but I propose to remove this advice. HTML 5 mentions setting a _charset_ parameter, and mentions decoding with a default of UTF-8 (not Latin-1!), but does not mention any Content-Type parameters. There seems to be confusion about what encoding it actually represents. According to <https://bugzilla.mozilla.org/show_bug.cgi?id=7533>, Mozilla briefly set this “charset” parameter a long time ago, but it would have corresponded to the urlencode(encoding=...) argument. The Python documentation currently suggests calling data.encode("utf-8"), which is misleading, because the urlencode() output is already guaranteed to be ASCII text. Any non-ASCII characters and bytes will already be character-encoded and percent-encoded by urlencode(). So I also propose to change the examples to data.encode("ascii"). ---------- assignee: docs@python components: Documentation files: urlencoded-charset.patch keywords: patch messages: 254263 nosy: docs@python, martin.panter, orsenthil priority: normal severity: normal stage: patch review status: open title: Remove “Content-Type: application/x-www-form-urlencoded; charset” advice versions: Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file40970/urlencoded-charset.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue25576> _______________________________________

3 6

[issue20923] ConfigParser should nested [] in section names.
by Terry J. Reedy 24 Nov '15

24 Nov '15

Terry J. Reedy added the comment: Discussion continues because my close message was, I now realize, incomplete and therefore unsatisfying. Ditto for the doc. So I complete my close message here and reopen issue to augment the doc. The discussion has so far has glossed over the key question: "What is a legal section name?" Pulling the answer from the doc was a challenge. It uses 'legal section name', once, as if one should already know. Reading further, I found the answer: there is no (fixed) answer! The legal section name for a particular parser is determined by its .SECTCRE class attribute. '''configparser.SECTCRE A compiled regular expression used to parse section headers. The default matches [section] to the name "section".''' (This neglects to say whether the closing ']' is the first or last ']' on the line after the opening '['.) A non-verbose version of the default is re.compile(r"\[(?P<header>[^]]+)\]"). I propose adding near the top of the doc: "By default, a legal section name can be any string that does not contain '\n' or ']'. To change this, see configparser.SECTCRE." So my response to Miloš should have been to set SECTCRE to something like p below. >>> p = re.compile(r"\[(?P<header>.*)\]") >>> m = p.search("[Test[2]_foo]") >>> m.group('header') 'Test[2]_foo' Additional note: Postel's principle was formulated for internet protocols, which .ini files are not. In any case, it is not a Python design principle. Neither is "always check user input", which amounts to 'look before you leap'. So I will not debate these. However, "Errors should never pass silently." is #10 on the Zen of Python ('import this') and that I do attend to. ---------- assignee: -> docs@python components: +Documentation nosy: +docs@python resolution: rejected -> stage: test needed -> needs patch status: closed -> open versions: +Python 2.7, Python 3.4, Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue20923> _______________________________________

1 0

[issue25700] namedtuple documentation
by Laur Joost 24 Nov '15

24 Nov '15

New submission from Laur Joost: collections.namedtuple documentation has an example about changing the resulting class docstrings: Docstrings can be customized by making direct assignments to the ``__doc__`` fields: >>> Book = namedtuple('Book', ['id', 'title', 'authors']) >>> Book.__doc__ += ': Hardcover book in active collection' This seems to work for the resulting class, but not the field names: MsgPacket = namedtuple('MsgPacket', ['sender', 'target', 'sig', 'ser_msg']) MsgPacket.__doc__ = '. Message packet format. This is the data added to client queues.' MsgPacket.sender.__doc__ = 'Sender public key.' gives Traceback (most recent call last): File "C:/UTCloud/UT/DS/S11/server.py", line 42, in <module> MsgPacket.sender.__doc__ = 'Sender public key.' AttributeError: readonly attribute ---------- assignee: docs@python components: Documentation messages: 255121 nosy: Laur Joost, docs@python priority: normal severity: normal status: open title: namedtuple documentation versions: Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue25700> _______________________________________

3 3