Mailman 3 June 2019 - docs

[issue32573] sys.argv documentation should include caveat for embedded environments
by Pedro 02 Jun '19

02 Jun '19

New submission from Pedro <pgacv2+pythonbugs(a)gmail.com>: Embedded Python interpreters, such as Boost.Python, do not have sys.argv available. (sys itself works fine.) This causes the interpreter to crash with the following exception when you try to access argv: AttributeError: 'module' object has no attribute 'argv' I'm not sure how closely related this is to #15577 or PEP 432. A simple workaround is to manually assign a list with an empty string to argv, as suggested by https://github.com/google/oauth2client/issues/642. However, the documentation for the sys module makes no mention of this special case for argv, and the line at the top that says "It is always available" can easily be interpreted to mean that *all* of sys's attributes will always be available. I suggest adding the following to the documentation for sys.argv: ======== Since `argv` contains the list of **command line** arguments passed to the Python interpreter, `argv` is not available within embedded interpreters, and scripts that run in embedded environments will raise an `AttributeError` when they attempt to access `argv`. As a workaround, assign a list with an empty string manually: ``` import sys if not hasattr(sys, 'argv'): sys.argv = [''] ``` ---------- assignee: docs@python components: Documentation messages: 310105 nosy: docs@python, pgacv2 priority: normal severity: normal status: open title: sys.argv documentation should include caveat for embedded environments type: enhancement versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue32573> _______________________________________

6 14

[issue37014] fileinput module should document that openhook and mode are ignored when reading from stdin
by Grant Wu 02 Jun '19

02 Jun '19

New submission from Grant Wu <grant.wu(a)petuum.com>: https://github.com/python/cpython/blob/master/Lib/fileinput.py#L326 shows that the openhook and mode are ignored when reading from stdin. Since part of fileinput's functionality is to abstract over whether one is reading from stdin or over a file, I think this abstraction leak should be documented. One common use case where this might break is when attempting to set the file encoding using the included fileinput.hook_encoded functionality. ---------- assignee: docs@python components: Documentation messages: 343221 nosy: Grant Wu2, docs@python priority: normal severity: normal status: open title: fileinput module should document that openhook and mode are ignored when reading from stdin versions: Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue37014> _______________________________________

5 10

Great Documention
by Jim Osborne 02 Jun '19

02 Jun '19

Your python documentation is the best I have ever seen ... thanks. Jim

1 0

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

02 Jun '19

Change by Mark Dickinson <dickinsm(a)gmail.com>: ---------- resolution: -> third party stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue36879> _______________________________________

1 0

[issue36984] typing docs "versionadded" is inaccurate for many attributes
by Anthony Sottile 02 Jun '19

02 Jun '19

New submission from Anthony Sottile <asottile(a)umich.edu>: expanding on https://bugs.python.org/issue36983 the docs are also a bit out of date in places I'm not sure how to document something that appeared in two versions, but I'll leave that part to review. Using data generated / collected in https://github.com/asottile/flake8-typing-imports via this script: https://github.com/asottile/flake8-typing-imports/blob/master/bin/build-gen… and then analyzed with this script: from flake8_typing_imports import SYMBOLS ALL = set().union(*(v for _, v in SYMBOLS)) for k in sorted(ALL): state = False for i, (v, ks) in enumerate(SYMBOLS): if state is False and k in ks: print(f'{k}: new in {v}') state = True elif state is True and k not in ks: print(f'=> {k}: removed in {v}') state = False I've found the following: $ python3 t.py | grep -v 'new in 3\.5\.0' AsyncContextManager: new in 3.5.4 => AsyncContextManager: removed in 3.6.0 AsyncContextManager: new in 3.6.2 AsyncGenerator: new in 3.6.1 AsyncIterable: new in 3.5.2 AsyncIterator: new in 3.5.2 Awaitable: new in 3.5.2 ChainMap: new in 3.5.4 => ChainMap: removed in 3.6.0 ChainMap: new in 3.6.1 ClassVar: new in 3.5.3 Collection: new in 3.6.0 ContextManager: new in 3.5.4 Coroutine: new in 3.5.3 Counter: new in 3.5.4 => Counter: removed in 3.6.0 Counter: new in 3.6.1 DefaultDict: new in 3.5.2 Deque: new in 3.5.4 => Deque: removed in 3.6.0 Deque: new in 3.6.1 ForwardRef: new in 3.7.0 GenericMeta: new in 3.5.4 => GenericMeta: removed in 3.6.0 GenericMeta: new in 3.6.1 => GenericMeta: removed in 3.7.0 NewType: new in 3.5.2 NoReturn: new in 3.5.4 => NoReturn: removed in 3.6.0 NoReturn: new in 3.6.2 OrderedDict: new in 3.7.2 TYPE_CHECKING: new in 3.5.2 Text: new in 3.5.2 Type: new in 3.5.2 ---------- assignee: docs@python components: Documentation messages: 342978 nosy: Anthony Sottile, docs@python priority: normal severity: normal status: open title: typing docs "versionadded" is inaccurate for many attributes versions: Python 3.8 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue36984> _______________________________________

4 4

[issue29414] Change 'the for statement is such an iterator' in Tutorial
by Jim Fasarakis-Hilliard 01 Jun '19

01 Jun '19

New submission from Jim Fasarakis-Hilliard: The current line is confusing hinting that the for statement is actually an object, it also makes a reference to iterators which the tutorial doesn't disambiguate until the chapter on Classes. I've added a small patch that, in my opinion, makes it clearer by using the terminology of the previous sentence. ---------- assignee: docs@python components: Documentation messages: 286678 nosy: Jim Fasarakis-Hilliard, docs@python priority: normal severity: normal status: open title: Change 'the for statement is such an iterator' in Tutorial versions: 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/issue29414> _______________________________________

6 16

[issue26468] shutil.copy2 raises OSError if filesystem doesn't support chmod
by Jeffrey Kintscher 01 Jun '19

01 Jun '19

Change by Jeffrey Kintscher <websurfer(a)surf2c.net>: ---------- nosy: +Jeffrey.Kintscher _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue26468> _______________________________________

1 0

[issue31968] exec(): method's default arguments from dict-inherited globals
by Raymond Hettinger 01 Jun '19

01 Jun '19

Change by Raymond Hettinger <raymond.hettinger(a)gmail.com>: ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue31968> _______________________________________

1 0

[issue31968] exec(): method's default arguments from dict-inherited globals
by Raymond Hettinger 01 Jun '19

01 Jun '19

Raymond Hettinger <raymond.hettinger(a)gmail.com> added the comment: New changeset 059b9ea5ac98f432e41b05d1fa5aab4ffa22df4d by Raymond Hettinger (Anthony Shaw) in branch 'master': bpo-31968: Documentation -- add clarification on the globals dict for exec() (GH-13140) https://github.com/python/cpython/commit/059b9ea5ac98f432e41b05d1fa5aab4ffa… ---------- nosy: +rhettinger _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue31968> _______________________________________

1 0

[issue36612] Unittest document is not clear on SetUpClass calls
by Vratko Polak 01 Jun '19

01 Jun '19

New submission from Vratko Polak <vrpolak(a)cisco.com>: One particular paragraph from unittest.rst is not clear enough: "If you want the setUpClass and tearDownClass on base classes called then you must call up to them yourself. The implementations in TestCase are empty." It has sparkled a debate here [0]. Example: A class SuperTestCase, which inherits from unittest.TestCase, defines some non-trivial setUpClass class method. Then a class SubTestCase, which inherits from SuperTestCase, wants to have SuperTestCase.setUpClass executed as its setUpClass. Does SubTestCase need to override setUpClass just to call SuperTestCase.setUpClass (as the paragraphs might suggest), or can it rely in inheritance to have it executed without overriding? I will create GitHub PR soon. [0] https://gerrit.fd.io/r/#/c/18579/1/test/test_sparse_vec.py@14 ---------- assignee: docs@python components: Documentation messages: 340028 nosy: docs@python, vrpolakatcisco priority: normal severity: normal status: open title: Unittest document is not clear on SetUpClass calls type: enhancement versions: Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue36612> _______________________________________

3 3