Mailman 3 May 2019 - docs

[issue36879] bug with round() and "numpy floats"
by Mark Dickinson 11 May '19

11 May '19

Mark Dickinson <dickinsm(a)gmail.com> added the comment: BTW, there are various issues already open in the NumPy bug tracker, for example https://github.com/numpy/numpy/issues/11557 I propose closing this as "third party". ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue36879> _______________________________________

1 0

[issue36879] bug with round() and "numpy floats"
by Mark Dickinson 11 May '19

11 May '19

Mark Dickinson <dickinsm(a)gmail.com> added the comment: > Maybe we should add something in the docs regarding the no-restriction point. IMO, the docs are clear enough (and also long enough) already here. Just as with most other magic methods, classes from third-party packages can return whatever they like. It doesn't seem worth adding specific disclaimers about this everywhere that a magic method might be used. Otherwise, we should also add corresponding disclaimers about `__floor__`, `__ceil__`, `__trunc__`, `__pow__`, and so on, and I think that would just introduce an increase in documentation size without any overall increase in clarity or usefulness. I'd prefer to stick to documenting that there _is_ a restriction where that's true (e.g., `__index__` or `__hash__`). ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue36879> _______________________________________

1 0

[issue36879] bug with round() and "numpy floats"
by Mark Dickinson 11 May '19

11 May '19

Change by Mark Dickinson <dickinsm(a)gmail.com>: ---------- nosy: +mark.dickinson _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue36879> _______________________________________

1 0

[issue36879] bug with round() and "numpy floats"
by SilentGhost 11 May '19

11 May '19

Change by SilentGhost <ghost.adh(a)runbox.com>: ---------- resolution: not a bug -> stage: -> needs patch _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue36879> _______________________________________

1 0

[issue36620] Documentation missing parameter for Itertools.zip_longest
by Charles Merriam 10 May '19

10 May '19

New submission from Charles Merriam <charles.merriam(a)gmail.com>: On page: https://docs.python.org/3.8/library/itertools.html In the heading summary, in the "Iterators terminating on the shortest input sequence:" section, in the "zip_longest()" table row, in the "Arguments" column, the text "p, q, ..." should be "p, q, ... [, fillvalue=None]" ---------- assignee: docs@python components: Documentation messages: 340107 nosy: CharlesMerriam, docs@python priority: normal severity: normal status: open title: Documentation missing parameter for Itertools.zip_longest type: enhancement versions: Python 3.8 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue36620> _______________________________________

7 10

[issue36879] bug with round() and "numpy floats"
by Pablo Galindo Salgado 10 May '19

10 May '19

Change by Pablo Galindo Salgado <pablogsal(a)gmail.com>: ---------- assignee: -> docs@python components: +Documentation nosy: +docs@python resolution: -> not a bug versions: +Python 3.7, Python 3.8 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue36879> _______________________________________

1 0

[issue30939] Sphinx 1.6.3 deprecation warning for sphinx.util.compat.Directive in docs builds
by Ned Deily 10 May '19

10 May '19

New submission from Ned Deily: [..]/sphinx/util/compat.py:40: RemovedInSphinx17Warning: sphinx.util.compat.Directive is deprecated and will be removed in Sphinx 1.7, please use docutils' instead. RemovedInSphinx17Warning) The solution is to import Directive directly from docutils. PR to follow for master, needs to be cherrypicked to all maintenance branches and, ideally, all current security-only branches. ---------- assignee: docs@python components: Documentation messages: 298401 nosy: brett.cannon, docs@python, larry, ned.deily priority: normal severity: normal stage: patch review status: open title: Sphinx 1.6.3 deprecation warning for sphinx.util.compat.Directive in docs builds versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue30939> _______________________________________

3 16

[issue29254] Documentation Error
by Suraj Kumar 10 May '19

10 May '19

New submission from Suraj Kumar: Hi, I have found one documentation mistake in section 3.1.2. Strings saying """Note how the start is always included, and the end always excluded. This makes sure that s[:i] + s[i:] is always equal to s: >>>word = 'Python' >>> word[:2] + word[2:] 'Python' """ I think instead of 'the end always excluded' it should be 'the end always included'. If my observation is correct, please do the needful change. Thanks & Regards, Suraj ---------- assignee: docs@python components: Documentation messages: 285331 nosy: Suraj Kumar, docs@python priority: normal severity: normal status: open title: Documentation Error type: behavior versions: Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue29254> _______________________________________

4 3

[issue36873] http.server: Document explicitly that symbolic links are followed
by STINNER Victor 10 May '19

10 May '19

New submission from STINNER Victor <vstinner(a)redhat.com>: http.server documentation starts with a red warning: "Warning: http.server is not recommended for production. It only implements basic security checks." https://docs.python.org/dev/library/http.server.html It would help to be even more explicit on what it means. For example, document that symbolic links are followed and SimpleHTTPRequestHandler directory can be "escaped" following symbolic links. ---------- assignee: docs@python components: Documentation messages: 342054 nosy: docs@python, vstinner priority: normal severity: normal status: open title: http.server: Document explicitly that symbolic links are followed type: security versions: Python 3.8 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue36873> _______________________________________

1 0

[issue10536] Enhancements to gettext docs
by Éric Araujo 09 May '19

09 May '19

New submission from Éric Araujo <merwok(a)netwok.org>: A patch made for #2504 revealed a bug in gettext.rst, and I’ve found a number of other things to change in the file. This is the first patch of a series of two or three. Barry, as the original author of the module and doc, I’d like your opinion on points 3, a, and b particularly. Patch is also uploaded to Rietveld for greater convenience: http://codereview.appspot.com/3333042/ (upload.py rocks) Summary: 1) Markup: Use modern class/method directives combo (yay DRY). Mark up variable parts in :file: constructs (e.g. :file:`{domain}.mo` will cause the HTML output to use var to indicate replaceable text). Also change some ``gettext`` to :program:`gettext` for consistency. 2) Fix a typo in lngettext doc (originally included in patch by Franz Glasner for #2504). 3) I had started to remove information about private attributes (_info, _charset), advertising public getter methods instead. Then I read the description of NullTranslations and realized the information was needed for subclasses. I’ve reverted my removals, but I still think the private attributes should be listed in a specific section for people writing subclasses and not in the rest of the text. If you’re okay, I’ll make a second patch. 4) Assorted wording changes, missing periods and hyphens, and other very small touch-ups: Turned a broken bare link into a working link with nice text; used the with statement in an example (we all love the with statement!); used two spaces after periods throughout (hello Fred Drake). Final note: lines have not been rewrapped, for diff clarity. When I commit part or all of this patch, I’ll make another commit to rewrap. Not addressed: a) The current docs is currently POSIX-specific. b) The docs take great care to explain that Unicode strings will be returned in different places, but this should not be so accented in 3.x docs IMO. I would just put a note somewhere near the top that all strings are str and remove the redundant sentences. Following that line of thought, I could group all l*gettext variants at the end of the list of methods, explaining that regular usage should just be happy with str objects and that l*gettext are available if people really want bytes. c) The file uses “built-in namespace” and “builtins namespace”, sometimes in neighbor paragraphs. :mod:`builtins` is not used, even in explanations of the install function/method. I don’t know if I should change that. d) Some capitalization patterns look strange to me: I have seen “I18N” and “L10N” in upper case nowhere else. Similarly, lower-case “id” looks stranger than “ID”. The latter is used for example in official GNU gettext docs. Am I going into foolish consistency territory or not? Thanks in advance for reviews and opinions. ---------- assignee: eric.araujo components: Documentation files: gettext-docs-1.diff keywords: needs review, patch messages: 122420 nosy: barry, docs@python, eric.araujo priority: normal severity: normal stage: patch review status: open title: Enhancements to gettext docs versions: Python 2.7, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file19819/gettext-docs-1.diff _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10536> _______________________________________

8 17