Mailman 3 February 2013 - docs

[issue17108] import silently prefers package over module when both available
by R. David Murray 08 Feb '13

08 Feb '13

R. David Murray added the comment: It has to be that way to preserve backward compatibility, since IIUC before the PEP there was no such thing as "an initless package", it was just a directory that was ignored by import. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue17108> _______________________________________

1 0

[issue17108] import silently prefers package over module when both available
by Éric Araujo 08 Feb '13

08 Feb '13

Éric Araujo added the comment: I knew that a package would win over a module, but an initless package does not? Yuck :( ---------- nosy: +eric.araujo _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue17108> _______________________________________

1 0

[issue15580] fix True/False/None reST markup
by Chris Jerdonek 08 Feb '13

08 Feb '13

New submission from Chris Jerdonek: The Dev Guide says not to markup True, False, and None in the documentation in a way that generates a link (e.g. ":const:`True`") because "they’re fundamental to the language and should be known to any programmer": http://docs.python.org/devguide/documenting.html#documenting Rather, it says to use "``True``" (and similarly for False and None): This issue is to update the documentation to conform to this guidance. While working on the documentation, I noticed many occurrences of ":const:`True`", for example. See here for some examples, where you can see the hyperlinks: http://docs.python.org/dev/library/tarfile.html#tarfile.TarFile.add ---------- assignee: docs@python components: Documentation messages: 167648 nosy: cjerdonek, docs@python priority: normal severity: normal status: open title: fix True/False/None reST markup _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15580> _______________________________________

5 14

[issue17145] memoryview(array.array)
by Demian Brecht 07 Feb '13

07 Feb '13

Demian Brecht added the comment: Strike that patch, this needs a little more love than during-my-first-coffee-of-the-day work. I'll work on it more and submit a follow-up for review. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue17145> _______________________________________

1 0

[issue4395] Document auto __ne__ generation; provide a use case for non-trivial __ne__
by Mark Dickinson 07 Feb '13

07 Feb '13

Changes by Mark Dickinson <dickinsm(a)gmail.com>: ---------- priority: low -> normal _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue4395> _______________________________________

1 0

[issue4395] Document auto __ne__ generation; provide a use case for non-trivial __ne__
by Mark Dickinson 07 Feb '13

07 Feb '13

Mark Dickinson added the comment: Issue #17151 closed as a duplicate of this one. ---------- nosy: +kushou, mark.dickinson _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue4395> _______________________________________

1 0

[issue17151] Python 3 changement of behavior with __ne__: documentation not updated
by Franck Michea 07 Feb '13

07 Feb '13

New submission from Franck Michea: Hi. As of python 3, behavior of object.__ne__ changed to call (not object.__eq__) if implemented. This changement can be seen in function object_richcompare in file Objects/typeobject.c. Documentation didn't change though, still saying[1] that "There are no implied relationships among the comparison operators. [...] Accordingly, when defining __eq__(), one should also define __ne__()". Maybe a paragraph about this new behavior would be fine? I am not sure if last sentence of last paragraph is what it means, but it was already there in python 2 doc so guess no. I am not sure about how to write it so no patch, sorry. [1] http://docs.python.org/3.3/reference/datamodel.html#object.__eq__ ---------- assignee: docs@python components: Documentation messages: 181620 nosy: docs@python, kushou priority: normal severity: normal status: open title: Python 3 changement of behavior with __ne__: documentation not updated versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue17151> _______________________________________

2 1

[issue17145] memoryview(array.array)
by Demian Brecht 07 Feb '13

07 Feb '13

Demian Brecht added the comment: Here's a patch for the docs that adds a little clarity. ---------- keywords: +patch Added file: http://bugs.python.org/file28986/buffer.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue17145> _______________________________________

1 0

[issue17145] memoryview(array.array)
by Stefan Krah 06 Feb '13

06 Feb '13

Stefan Krah added the comment: Changing array.array would be a new feature, so it cannot go into 2.7. The documentation could be improved, see also #14198. ---------- assignee: -> docs@python components: +Documentation -None nosy: +docs@python, skrah _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue17145> _______________________________________

1 0

Typo in threading.Thread.join docstring
by Lev Levitsky 06 Feb '13

06 Feb '13

Hello, this is super minor, but: in the doc for threading.Thread.join<http://docs.python.org/library/threading.html#threading.Thread.join> there is a typo/grammatical mistake: It is also an error to join()<http://docs.python.org/2/library/threading.html#threading.Thread.join> a thread before it has been started and *attempts to do so raises* the same exception. Best regards, Lev -- Lev Levitsky Institute for Energy Problems of Chemical Physics RAS Laboratory of Physical and Chemical Methods for Structure Analysis Leninsky pr. 38, bld. 2 119334 Moscow Russia tel: +7 499 1378257 fax: +7 499 1378257, +7 499 1378258

1 0