Mailman 3 February 2020 - docs

[issue20582] socket.getnameinfo() does not document flags
by Roy Smith Nov. 20, 2020

Nov. 20, 2020

New submission from Roy Smith: http://docs.python.org/2/library/socket.html The description for getnameinfo() says, "... Depending on the settings of flags, the result can contain a fully-qualified domain name or numeric address representation in host.", but does not say what to pass for flags to get those behaviors. ---------- assignee: docs@python components: Documentation messages: 210838 nosy: docs@python, roysmith priority: normal severity: normal status: open title: socket.getnameinfo() does not document flags versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue20582> _______________________________________

9 12

[issue38320] Clarify unittest expectedFailure behaviour in the documentation
by Kit Choi Nov. 18, 2020

Nov. 18, 2020

New submission from Kit Choi <kchoi(a)enthought.com>: Following discussion in https://bugs.python.org/issue38296 The docstring of unittest.expectedFailure is misleading for people who differentiate "error" and "failure" when they read the sentence. This has a consequence of developers using the decorator without noticing unexpected errors are also silenced, which mean running a risk of their tests becoming unmaintained and invalid in the future. I suggest updating the documentation to include a mention of the current behaviour of silencing unexpected errors, so that developers are aware of this. Something like this?: Mark the test such that unexpected success results in a failure. If an exception (BaseException excluding KeyboardInterrupt) occurs, the test will be considered a success. If the test passes, it will be considered a failure. ---------- assignee: docs@python components: Documentation, Tests messages: 353557 nosy: Kit Choi2, docs@python priority: normal severity: normal status: open title: Clarify unittest expectedFailure behaviour in the documentation type: behavior versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue38320> _______________________________________

4 7

[issue17854] symmetric difference operation applicable to more than two sets
by Amit Saha Nov. 17, 2020

Nov. 17, 2020

New submission from Amit Saha: The description of the symmetric difference operation implies that it cannot be applied to more than two sets (http://docs.python.org/3/library/stdtypes.html#set.symmetric_difference). However, this is certainly possible: >>> s={1,2} >>> t={2,3} >>> u={3,4} >>> s^t^u {1, 4} >>> s.symmetric_difference(t).symmetric_difference(u) {1, 4} I am not sure how much of a "semantic" sense that makes, given that symmetric difference is by definition for two sets. (http://en.wikipedia.org/wiki/Symmetric_difference). So, either the operator should be fixed to allow only two sets or the description be updated. ---------- assignee: docs@python components: Documentation messages: 187899 nosy: Amit.Saha, docs@python priority: normal severity: normal status: open title: symmetric difference operation applicable to more than two sets type: behavior versions: Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue17854> _______________________________________

6 8

[issue17887] docs: summary page - generator vs iterator vs iterable
by anatoly techtonik Nov. 17, 2020

Nov. 17, 2020

New submission from anatoly techtonik: Docs lack a good summary page comparing three concepts. The main question is how do I tell if something is a sequence, generator, iterator or iterable? I found myself puzzled that range() is neither generator or iterator. ---------- assignee: docs@python components: Documentation messages: 188203 nosy: docs@python, techtonik priority: normal severity: normal status: open title: docs: summary page - generator vs iterator vs iterable _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue17887> _______________________________________

4 4

[issue13875] cmd: no user documentation
by anatoly techtonik Nov. 17, 2020

Nov. 17, 2020

New submission from anatoly techtonik <techtonik(a)gmail.com>: http://docs.python.org/library/cmd.html# Documentation for cmd module is poor to explain the value of this module to users. Intro is too abstract - phrase "simple framework for writing line-oriented command interpreters" doesn't mean much. Perhaps word "interactive" is missing? So, there is no part explaining the what cmd does exactly (intro fails) and no part explaining the main principle - How exactly does this framework allows to do this in a simple way? (I guess reference part under 'Cmd objects -> Cmd.cmdloop([intro]) -> p[4]` does that, but it is not the place you'd usually expect this info. At the very least what could be done is a link to Doug's tutorial http://www.doughellmann.com/PyMOTW/cmd/ ---------- assignee: docs@python components: Documentation messages: 152010 nosy: docs@python, techtonik priority: normal severity: normal status: open title: cmd: no user documentation _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13875> _______________________________________

4 6

[issue17939] Misleading information about slice assignment in docs
by Stefan Chrobot Nov. 17, 2020

Nov. 17, 2020

New submission from Stefan Chrobot: http://docs.python.org/3/reference/simple_stmts.html#assignment-statements The docs says: "If the target is a slicing: The primary expression in the reference is evaluated. It should yield a mutable sequence object (such as a list). The assigned object should be a sequence object of the same type." This seems wrong, because the assigned object can be any iterable: a = [4, 5, 6] a[0:0] = range(1, 4) # a is now [1, 2, 3, 4, 5, 6] ---------- assignee: docs@python components: Documentation messages: 188738 nosy: docs@python, stefanchrobot priority: normal severity: normal status: open title: Misleading information about slice assignment in docs type: enhancement versions: Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue17939> _______________________________________

4 3

[issue9538] Replace confusing pseudoname 'object' in special methods section.
by Terry J. Reedy Nov. 17, 2020

Nov. 17, 2020

New submission from Terry J. Reedy <tjreedy(a)udel.edu>: In 3.3. Special method names, 'object' is used as a pseudo class name to prefix all the special method entries. This conflicts with the usual two Python meanings. 1. 'object' is the name of a specific class. So the entry for object.__getattribute__(self, name) says to avoid circularity by calling object.__getattribute__(self, name), which looks circular and requires a bit a mental work by the reader to properly understand. Ditto for object.__setattr__(self, name, value) calling object.__setattr__(self, name, value) 2. Non-specifically, 'object' is usually understood to mean any Python object, not just a class. But the signatures as written require that 'object' specifically be a class and 'object' does not convey that. So for both reasons, I propose that the pseudoname 'object' be replaces with 'class' or 'someclass' ---------- assignee: docs@python components: Documentation messages: 113194 nosy: docs@python, georg.brandl, terry.reedy priority: normal severity: normal stage: needs patch status: open title: Replace confusing pseudoname 'object' in special methods section. versions: Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue9538> _______________________________________

5 8

[issue13561] os.listdir documentation should mention surrogateescape
by Michael Foord Nov. 16, 2020

Nov. 16, 2020

New submission from Michael Foord <michael(a)voidspace.org.uk>: Where os.listdir encounters undecodable bytes from the filesystem it uses the surrogateescape handler. As the resulting strings are invalid they can't be encoded without an errorhandler, and so can't be printed (for example). This should be documented. ---------- assignee: docs@python components: Documentation messages: 149070 nosy: docs@python, michael.foord priority: normal severity: normal stage: needs patch status: open title: os.listdir documentation should mention surrogateescape versions: Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13561> _______________________________________

5 6

[issue14338] urllib2 HowTo for overriding post/3xx behavior.
by beeNuts Nov. 15, 2020

Nov. 15, 2020

New submission from beeNuts <jeff.adams(a)linux.com>: Issue #14144, with the title "urllib2 HTTPRedirectHandler not forwarding POST data in redirect" was recently closed with these comments: "This could be cookbook recipe style example, if it's utility value is high. I am closing this issue as I feel that the requirement may not be addressed by a change. If there is patch for HowTo, we can tackle that in another issue. Thank you for contribution." The decision that documents on this issue were preferable to a patch seems like a fair compromise, especially considering that the RFC is decidedly ambiguous.I was wondering if the HowTo would be forthcoming? It seems to me that the value/utility would certainly be high. I'd submit it myself but I'm so new to Python that I don't trust my ability to do it correctly. It's something I would find highly useful, though. ---------- assignee: docs@python components: Documentation messages: 156080 nosy: beerNuts, docs@python priority: normal severity: normal status: open title: urllib2 HowTo for overriding post/3xx behavior. versions: Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue14338> _______________________________________

4 4

[issue17437] Difference between open and codecs.open
by Giampaolo Rodola' Nov. 15, 2020

Nov. 15, 2020

New submission from Giampaolo Rodola': In Python 2 the distinction between open() and codes.open() was clear because 'encoding' and 'errors' args were provided by codecs.open only. This is no longer the case in Python 3 since both args are provided also by open(). I'm probably missing something but regardless I think codecs.open doc [1] should be more clear as to when and why (say) codecs.open(file, encoding='utf8', errors='ignore') should be preferred over open(file, encoding='utf8', errors='ignore'). [1] http://docs.python.org/3/library/codecs.html#codecs.open ---------- assignee: docs@python components: Documentation messages: 184303 nosy: docs@python, ezio.melotti, giampaolo.rodola priority: normal severity: normal status: open title: Difference between open and codecs.open versions: Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue17437> _______________________________________

3 2