[issue26262] Cannot compile with /fp:strict with MSVC
Nathan Harold added the comment: Here's a patch with those three replacements and related comments. -- keywords: +patch nosy: +nharold Added file: http://bugs.python.org/file43379/constants.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26262> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22558] Missing doc links to source code for Python-coded modules.
Nathan Harold added the comment: I went over the sections I above called "Other/Smaller details" as addressed in mywork3.patch. I think they look fine. The patch applies seamlessly to both 3.5 and 3.6. For reference, since I noted them when I reviewed mywork2.patch last week, here are the packages at issue in the question about links to packages: Package docs in which the patch in this issue adds a link to __init__.py: dbm.rst, email.rst, importlib.rst, json.rst, msilib.rst, tkinter.rst, unittest.rst, xml.dom.rst, xml.sax.rst Package docs in which the patch in this issue adds a link to a directory: 2to3.rst, email.mime.rst, idle.rst, multiprocessing.rst, sqlite3.rst, urllib.rst, venv.rst, xml.rst Also, I noticed that asyncio.rst provides a precedent for linking to a source directory. So both ways have been done before. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22558> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22558] Missing doc links to source code for Python-coded modules.
Nathan Harold added the comment: I went through all the diffs in Rietveld, checking it against msg228576 as I went. There were (naturally) more source links added than there are in that list from 2014, and there were also many more files with slight header reorganizations for consistency. Anything in the diffs I don't mention here looked fine to me. I also built the docs to test links in general and to see how some specific things here looked. A number of the new links are to __init__.py files, and others are to folders rather than individual source files. I noticed a precedent for the former in the case of the http module; for the latter I'm less certain, but I can see that it makes sense in some cases, e.g. when __init__.py is empty. I think these are probably good. One thing I particularly noticed was that in imp.rst and optparse.rst, the deprecation notice occurred below the source link, whereas the versionadded notices are always above it. I think it would be more consistent and look more natural to have the deprecation notices above the source links. This could be taken a step farther by suggesting that the source link always be the last visible thing before the horizontal line. The two other cases this would affect here are asyncio.rst (the notice that the module is provisional is between the source link and line) and getopt.rst (the note, now moved above the line, is after the source link). But this is all fairly subjective. Other details for individual files: marshal.rst - Here an index block a bit farther down into the text was moved up into the header. I think these might have been intended to point right where they were, not to the module as a whole; those things occur only in the paragraph (or two, in the case of 'code object') immediately following where the index originally pointed. unittest.mock-examples.rst - A versionadded notice was completely removed from this file. In fact, that was the only change to this file. I think I can see why you did this, since the actual API documentation for the library is in unittest.mock.rst, which has that same version notice. Smaller details: array.rst - -- was inserted above .. index: fcntl.rst - Patch appears to apply correctly, but with fuzz. os.path.rst - It might be good to put a space in "WindowsNT" termios.rst - Patch fails to apply because some other text near the header has changed recently. venv.rst - The source code link (to a folder) works, but is missing a trailing slash. Terry, I got the same results when I tried applying it to 3.5, so I think a single patch will do. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22558> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22558] Missing doc links to source code for Python-coded modules.
Nathan Harold added the comment: I'll give this a go, per Terry's instructions in msg266846. I've noticed up front that, due to other changes near the headers of a couple of files (specifically fcntl.rst and termios.rst), the patch doesn't apply cleanly anymore. Is it permissible for me to fix that myself and upload a new version, or is it preferable for a patch's original author to handle such things? In any case, there are plenty of other files for me to look over for now. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22558> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22558] Missing doc links to source code for Python-coded modules.
Changes by Nathan Harold <penw81...@yahoo.com>: -- nosy: +nharold ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22558> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27178] Unconverted RST marking in interpreter tutorial
New submission from Nathan Harold: There's a bit of uninterpreted RST markup: 3.6.. _tut-using: at the top of the second section of the tutorial (https://docs.python.org/3.6/tutorial/interpreter.html) in the documentation for 3.6 only. (I can see this in the offline copy I received with 3.6.0a1 as well.) It appears that this originated in 96328:dfe62f685538, which changed various references to Python to say 3.6 instead of 3.5. This line had formerly just said: .. _tut-using: My best guess is that this was just an accident. I can't find a precedent or meaning for the changed notation, and there were no similar changes to any other files, either. I've included a patch for this line. -- assignee: docs@python components: Documentation files: fix.diff keywords: patch messages: 266840 nosy: docs@python, nharold priority: normal severity: normal status: open title: Unconverted RST marking in interpreter tutorial type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file43093/fix.diff ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27178> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26589] Add HTTP Response code 451
Nathan Harold added the comment: Added it to the table at https://docs.python.org/3.6/library/http.html#http-status-codes and put a versionadded notice at the bottom. -- nosy: +nharold Added file: http://bugs.python.org/file43086/doctable.diff ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26589> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26176] EmailMessage example doesn't work
Nathan Harold added the comment: emailexample.patch fixes the specific issue mentioned in #26426: the Address constructor is now used as documented. It changes the final output of the two combined examples (as presented in the documentation) accordingly. In general it seems as though these examples (the two in in 19.1.14.1) were meant to be read, not run. To run them, the user would have to supply (1) their own roasted-asparagus.jpg, (2) their own local SMTP server, and (3) their own implementation of imaginary.magic_html_parser. However, the Address constructor usage issue was real, and I was able to generate the relevant output without (2) and (3). -- keywords: +patch nosy: +nharold Added file: http://bugs.python.org/file43070/emailexample.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26176> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27043] Describe what ‘inspect.cleandoc’ does to synopsis line.
Nathan Harold added the comment: Split version (cleandoc2.patch): Clean up indentation from docstrings that are indented to line up with blocks of code. All leading whitespace is removed from the first line. Any leading whitespace that can be uniformly removed from the second line onwards is removed. Empty lines at the beginning and end are subsequently removed. Also, all tabs are expanded to spaces. -- Added file: http://bugs.python.org/file43030/cleandoc2.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27043> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26553] Write HTTP in uppercase
Changes by Nathan Harold <penw81...@yahoo.com>: Added file: http://bugs.python.org/file43022/3_fix_2.7.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26553> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26553] Write HTTP in uppercase
Changes by Nathan Harold <penw81...@yahoo.com>: Added file: http://bugs.python.org/file43021/3_fix_3.5.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26553> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26553] Write HTTP in uppercase
Nathan Harold added the comment: The 2_fix* patches were unfortunately slightly broken because an unrelated revision to xmlrpc.client.rst changed one of the lines the patch files were using as an anchor (by adding a period to the end). I've uploaded the 3_fix* series, which addresses this. The actual changes in these patches are identical to those in their precursors: capitalization of HTTP, HTTPS, FTP, and URL in a few places. -- nosy: +nharold Added file: http://bugs.python.org/file43020/3_fix_3.6.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26553> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27043] Describe what ‘inspect.cleandoc’ does to synopsis line.
Nathan Harold added the comment:
Here's my shot at a revision (corresponding patch attached):
Clean up indentation from docstrings that are indented to line up with blocks
of code. All leading whitespace is removed from the first line. Any leading
whitespace that can be uniformly removed from the second line onwards is
removed. Empty lines at the beginning and end are subsequently removed.
Also,
all tabs are expanded to spaces.
This version also makes it explicit that nothing happens to trailing
whitespace, should a line happen to have any. This actually seems to be a
difference between this function and the sample implementation in the PEP.
One odd side effect of that difference is that a line consisting only of
whitespace may actually not be removed from the beginning or end of the string,
if the preceding whitespace removals aren't sufficient to leave the line
completely empty. For instance:
>>> inspect.cleandoc(' A \n B \n \n ')
'A \nB \n '
Two spaces are removed from each of the second, third, and fourth lines. The
fourth line is then empty and is removed; the third line still contains one
space and is kept.
On the other hand, as defined in the PEP, the extra space on the third line is
removed as trailing whitespace, so that the third line is then removed entirely:
>>> trim(' A \n B \n \n ')
'A\nB'
Most likely this difference rarely affects anything. In any case, mentioning
it here because it influenced exactly how I revised the docs.
--
keywords: +patch
nosy: +nharold
Added file: http://bugs.python.org/file43018/cleandoc.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27043>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
