Mailman 3 August 2019 - docs

[issue30974] Update os.samefile docstring to match documentation
by miss-islington 02 Aug '19

02 Aug '19

miss-islington <mariatta.wijaya+miss-islington(a)gmail.com> added the comment: New changeset 6b833901fe9053937c289c6371bb731c9aceb58e by Miss Islington (bot) in branch '3.8': bpo-30974: Change os.path.samefile docstring to match docs (GH-7337) https://github.com/python/cpython/commit/6b833901fe9053937c289c6371bb731c9a… ---------- nosy: +miss-islington _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue30974> _______________________________________

1 0

[issue34142] Windows launcher version lookup flawed
by Steve Dower 02 Aug '19

02 Aug '19

Change by Steve Dower <steve.dower(a)python.org>: ---------- versions: +Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue34142> _______________________________________

1 0

[issue30974] Update os.samefile docstring to match documentation
by Steve Dower 02 Aug '19

02 Aug '19

Steve Dower <steve.dower(a)python.org> added the comment: Still needs a 2.7 backport if someone would like to do it. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue30974> _______________________________________

1 0

[issue30974] Update os.samefile docstring to match documentation
by Steve Dower 02 Aug '19

02 Aug '19

Steve Dower <steve.dower(a)python.org> added the comment: I'm not personally thrilled about it being documented like this, but it's certainly how the current documentation reads. Consistency is better until we get motivated enough to fix all of it. Thanks for the patch! ---------- stage: patch review -> backport needed _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue30974> _______________________________________

1 0

[issue30974] Update os.samefile docstring to match documentation
by miss-islington 02 Aug '19

02 Aug '19

Change by miss-islington <mariatta.wijaya+miss-islington(a)gmail.com>: ---------- pull_requests: +14832 pull_request: https://github.com/python/cpython/pull/15087 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue30974> _______________________________________

1 0

[issue30974] Update os.samefile docstring to match documentation
by miss-islington 02 Aug '19

02 Aug '19

Change by miss-islington <mariatta.wijaya+miss-islington(a)gmail.com>: ---------- pull_requests: +14831 pull_request: https://github.com/python/cpython/pull/15086 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue30974> _______________________________________

1 0

[issue30974] Update os.samefile docstring to match documentation
by Steve Dower 02 Aug '19

02 Aug '19

Steve Dower <steve.dower(a)python.org> added the comment: New changeset 8e568ef266a2805f9a6042003723d9c050830461 by Steve Dower (Timo Furrer) in branch 'master': bpo-30974: Change os.path.samefile docstring to match docs (GH-7337) https://github.com/python/cpython/commit/8e568ef266a2805f9a6042003723d9c050… ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue30974> _______________________________________

1 0

[issue34564] Tutorial Section 2.1 Windows Installation Path Correction
by Tom Berry 02 Aug '19

02 Aug '19

New submission from Tom Berry <tom.berryx(a)gmail.com>: The listed installation location is incorrect in the 02 Sep 18 release of the tutorial. It shows the default install path as C:\python36 vice C:\Program Files\python37. This may be related to an installer issue, as installing single-user places the program in an entirely different directory. Changing the installer to default back to C:\python37 would remove the need to differentiate Program Files (x86) for a 32-bit installer, as well as Program Files\ for the 64-bit. Corrected Tutorial attached reflecting change FROM C:\python36 TO C:\Program Files\Python37. ---------- assignee: docs@python components: Documentation files: Tutorial_EDIT.pdf messages: 324482 nosy: aperture, docs@python priority: normal severity: normal status: open title: Tutorial Section 2.1 Windows Installation Path Correction type: enhancement versions: Python 3.7 Added file: https://bugs.python.org/file47781/Tutorial_EDIT.pdf _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue34564> _______________________________________

3 2

ftplib Line Ending Documentation Discrepancy
by Patrick Dunham 02 Aug '19

02 Aug '19

Hi! I think I’ve found a discrepancy in the documentation in Python’s ftplib . A comment on line 75 claims that ftplib supports \r, \n, and \r\n line endings # Line terminators (we always output CRLF, but accept any of CRLF, CR, LF) but after attempting to use it to read a 2 MB file with \r line endings off of an FTP server, this does not appear to be the case. The entire file is read out as a single “line” (after increasing the size of FTP.maxline). It looks like this is intentional, as the the implementation of FTP.retrlines() and FTP_TLS.retrlines() only strips \n and \r\n (snippet from line 452) if line[-2:] == CRLF: line = line[:-2] elif line[-1:] == '\n': line = line[:-1] callback(line) Am I missing something? Or just interpreting the documentation wrong? I know this is not a common occurrence (esp. since RFC 959 states that ASCII line endings should be \r\n), but it seems confusing, and doesn’t mesh with Python’s generally excellent universal newline support. This seems to be the case with the versions of ftplib in Ubuntu 18.04.2’s distribution of Python 2.7.15+ and Python 3.6.8. The FTP server in question is run off of an unknown RTOS on a Zumbach ODAC-14XY laser micrometer. I can provide an example of the file in question if required. -- Cheers, Patrick Dunham Scale-Up Engineer

1 0

[issue37726] Tutorial should not recommend getopt
by Guido van Rossum 01 Aug '19

01 Aug '19

New submission from Guido van Rossum <guido(a)python.org>: I read on python-ideas that the tutorial recommends getopt as the simple argument parsing choice, and argparse as advanced. This is silly. We should only promote argparse (unless you want to use raw sys.argv[1:]). ---------- assignee: docs@python components: Documentation keywords: newcomer friendly messages: 348774 nosy: docs@python, gvanrossum priority: normal severity: normal stage: needs patch status: open title: Tutorial should not recommend getopt versions: Python 2.7, Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue37726> _______________________________________

3 9