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>
_______________________________________
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>
_______________________________________
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>
_______________________________________
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>
_______________________________________
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>
_______________________________________
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>
_______________________________________
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>
_______________________________________
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>
_______________________________________
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>
_______________________________________
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>
_______________________________________