docs May 2019

docs@python.org

17 participants
554 discussions

[issue32523] inconsistent spacing in changelog.html

by Ned Deily

New submission from Ned Deily <nad(a)python.org>: The rendered changelog.html files produced "make html" have inconsistent spacing between items. Usually, the first changelog topic section (e.g. Security) starts with no blank lines between items but occasionally some subsequent sections will render with a blank link between items; this seems to be often true for the Library section, but not always. This is visible across the recent 3.x branches; here's an example with the stable 3.5 docs: Library section has blank line separator: https://docs.python.org/3.5/whatsnew/changelog.html#id5 Library section has no blank separators: https://docs.python.org/3.5/whatsnew/changelog.html#id11 ---------- assignee: docs@python components: Documentation messages: 309711 nosy: docs@python, ned.deily priority: normal severity: normal status: open title: inconsistent spacing in changelog.html versions: Python 3.6, Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue32523> _______________________________________

2 years, 5 months

[issue36864] Double Spaces in the documentation

by Jules Lasne

New submission from Jules Lasne <jules.lasne(a)gmail.com>: Hello, I've come to open this issue today because of the apparent split there is in the documentation about double spaces after a period. Here is a link to an article explaining some of the issue https://www.writing-skills.com/one-space-two-full-stop Anyway, the opinion isn't really important here but, when translating the documentation we waste a lot of time removing the double spaces that are ugly and useless in French. I'd like to propose a PR to remove all double spaces after a period from the documentation as they serve no apparent purpose. I'm open for discussion of course ---------- assignee: docs@python components: Documentation messages: 341977 nosy: docs@python, seluj78 priority: normal severity: normal status: open title: Double Spaces in the documentation _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue36864> _______________________________________

2 years, 5 months

[issue12188] PEP 7, C style: add ++ policy and explanation

by Terry J. Reedy

New submission from Terry J. Reedy <tjreedy(a)udel.edu>: In response to a discussion of a patch removing 'useless' post-increments, (which issue has apparently come up before) Guido posted "> Sorry to butt in here, but I agree with Eric that it was better > before. There is a common idiom, *pointer++ =<something>, and > whenever you see that you know that you are appending something to an > output buffer. Perhaps the most important idea here is that this > maintains the *invariant* "pointer points just after the last thing in > the buffer". Always maintaining the invariant is better than trying to > micro-optimize things so as to avoid updating dead values. The > compiler is better at that." A condensed version of the above added to PEP 7 would help new developers see the usage as local idiom rather than style bug. ---------- assignee: docs@python components: Documentation messages: 136991 nosy: docs@python, terry.reedy priority: normal severity: normal status: open title: PEP 7, C style: add ++ policy and explanation _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12188> _______________________________________

2 years, 5 months

[issue31873] Inconsistent capitalization of proper noun - Unicode.

by David Antonini

New submission from David Antonini <davidantonini(a)hotmail.com>: Make 'unicode'/'Unicode' capitalization consistent. 'Unicode' is a proper noun, and as such should be capitalized. I submitted a pull request correcting the inconsistent capitalization in the Unicode page of the Documentation - Doc/c-api/unicode.rst - capitalizing 12 errant instances to reflect the correct capitalization in most of the document. I was then requested to open an issue here for discussion. ---------- assignee: docs@python components: Documentation messages: 305050 nosy: docs@python, toonarmycaptain priority: normal pull_requests: 4096 severity: normal status: open title: Inconsistent capitalization of proper noun - Unicode. type: enhancement _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue31873> _______________________________________

2 years, 5 months

[issue24712] Docs page's sidebar vibrates on mouse wheel scroll on Chrome.

by Biwin John

New submission from Biwin John: The sidebar on the documentation pages ex. https://docs.python.org/2/library/collections.html vibrates/flashes on mouse wheel scroll. The sidebar with class sphinxsidebar, works okay when scrolling with the scrollbar, Firefox but not with mouse wheel on Chrome. please consider fixing it. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue24712> _______________________________________

2 years, 5 months

[issue33948] doc truncated lines in PDF

by Mikhail

New submission from Mikhail <mikhail.domanov(a)gmail.com>: Hello, Python Team, In reference.pdf I came across truncated lines in Python syntax that are not wrapped and carried forward to the next line, but instead run across the right margin. Examples "2.3 Identifiers and keywords" line contains "id_start ::= <all characters in general categories" "8.8.1 Coroutine function definition" line contains "async_funcdef ::= [decorators] "async" "def" funcname "(" [parameter_list] ")" ["->" expression" It would be VERY convenient to fix this for printing. Thank you ---------- assignee: docs@python components: Documentation messages: 320313 nosy: Mikhail_D, docs@python priority: normal severity: normal status: open title: doc truncated lines in PDF versions: Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue33948> _______________________________________

2 years, 5 months

[issue32393] nav menu jitter in old documentation

by Joseph Hendrey

New submission from Joseph Hendrey <jhendrey(a)condense.com.au>: The sidebar navigation menu jitters when scrolling on the 2.7 documentation pages (at least in Chrome). A seemingly unrelated issue is that the collapse symbol '<<' is a fixed distance from the top of the page rather than staying in the centre (height-wise) of the screen (it should always be visible). It seems it has been fixed for newer documentation, but since the fix is so simple it would be nice to fix it for the old documentation too. Setting the position property of the span element seems to fix both issues for me (see attached screenshot) ---------- assignee: docs@python components: Documentation files: screenshot.JPG messages: 308834 nosy: Joseph Hendrey, docs@python priority: normal severity: normal status: open title: nav menu jitter in old documentation type: behavior versions: Python 2.7 Added file: https://bugs.python.org/file47343/screenshot.JPG _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue32393> _______________________________________

2 years, 5 months

[issue20709] os.utime(path_to_directory): wrong documentation for Windows.

by Jan-Philip Gehrcke

New submission from Jan-Philip Gehrcke: The os.utime() docs for Python 2 (http://docs.python.org/2/library/os.html#os.utime) and 3 (http://docs.python.org/3/library/os.html#os.utime) both contain the sentence "Whether a directory can be given for path depends on whether the operating system implements directories as files (for example, *Windows does not*)" "Windoes does not" is wrong. CPython 2.7 on Windows 7: >>> os.utime(".", (100, 100)) >>> os.stat(".").st_mtime 100.0 We should - either name a specific system for which this does not work - or remove this example. Windows XP and newer support this operation via SetFileTime (http://msdn.microsoft.com/en-us/library/windows/desktop/ms724933%28v=vs.85%…): "Sets the date and time that the specified file or directory was created, last accessed, or last modified." I have grepped myself through a couple of CPython source trees and found posixmodule.c: if (!SetFileTime(hFile, NULL, &atime, &mtime) in 2.5, 2.6, 2.7. I guess the statement comes from 2.4 times, where `SetFileTime` only appears in `PC/bdist_wininst/extract.c`. So, do we just remove the hint or does someone have an example at hand for which combination of Python and platform this does not work for directories? Once we have a decision, I will be happy to provide the mini patch. ---------- assignee: docs@python components: Documentation messages: 211760 nosy: docs@python, jgehrcke priority: normal severity: normal status: open title: os.utime(path_to_directory): wrong documentation for Windows. versions: Python 2.7, 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/issue20709> _______________________________________

2 years, 5 months

[issue36830] Typo in collections.deque

by keroru

New submission from keroru <jmdtqj(a)gmail.com>: https://docs.python.org/ja/3/library/collections.html#collections.deque has a typo in description of "rotate(n=1)" in Japanese. I suppose that "d.appendleft(d.popleft())" should be "d.append(d.popleft())". Thank you! ---------- assignee: docs@python components: Documentation messages: 341715 nosy: docs@python, keroru priority: normal severity: normal status: open title: Typo in collections.deque versions: Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue36830> _______________________________________

2 years, 5 months

[issue11001] Various obvious errors in cookies documentation

by Luke Plant

New submission from Luke Plant <L.Plant.98(a)cantab.net>: Docs for SimpleCookie, BaseCookie.value_encode and BaseCookie.value_decode are obviously incorrect. Attempt at patch attached. The error has existed in every Python version I've seen, I've tagged the ones I believe can receive fixes, sorry if I've made a mistake. Thanks. ---------- assignee: docs@python components: Documentation files: http_cookies_doc_corrections.diff keywords: patch messages: 126962 nosy: docs@python, spookylukey priority: normal severity: normal status: open title: Various obvious errors in cookies documentation versions: Python 2.7, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file20507/http_cookies_doc_corrections.diff _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue11001> _______________________________________

2 years, 5 months

Jump to page:

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

docs May 2019