Mailman 3 March 2017 - docs

[issue28315] incorrect "in ?" output in 'divide' example at "Defining Clean-up Actions" in tutorial
by Viorel Tabara May 4, 2017

May 4, 2017

New submission from Viorel Tabara: At https://docs.python.org/3.5/tutorial/errors.html#defining-clean-up-actions when I'm running the "divide('2', '1')" example I get: File "<stdin>", line 1, in <module> instead of the documentation output of: File "<stdin>", line 1, in ? The same message is included with the 2.7 tutorial. To wit: $ python3 Python 3.5.2 (default, Sep 14 2016, 11:28:32) [GCC 6.2.1 20160901 (Red Hat 6.2.1-1)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> def divide(x, y): ... try: ... result = x / y ... except ZeroDivisionError: ... print('division by zero!') ... else: ... print('result is', result) ... finally: ... print('executing finally clause') ... >>> divide(2, 1) result is 2.0 executing finally clause >>> divide(2, 0) division by zero! executing finally clause >>> divide('2', '1') executing finally clause Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<stdin>", line 3, in divide TypeError: unsupported operand type(s) for /: 'str' and 'str' $ python2 Python 2.7.12 (default, Sep 2 2016, 15:40:50) [GCC 6.2.1 20160901 (Red Hat 6.2.1-1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> def divide(x, y): ... result = x / y KeyboardInterrupt >>> def divide(x, y): ... try: ... result = x / y ... except ZeroDivisionError: ... print('division by zero!') ... else: ... print('result is', result) ... finally: ... print('executing finally clause') ... >>> divide(2, 1) ('result is', 2) executing finally clause >>> divide(2, 0) division by zero! executing finally clause >>> divide('2', '1') executing finally clause Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<stdin>", line 3, in divide TypeError: unsupported operand type(s) for /: 'str' and 'str' Nice tutorial by the way ;) Thanks! ---------- assignee: docs@python components: Documentation messages: 277731 nosy: docs@python, viorel priority: normal severity: normal status: open title: incorrect "in ?" output in 'divide' example at "Defining Clean-up Actions" in tutorial type: behavior versions: Python 2.7, Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue28315> _______________________________________

5 46

[issue15346] Tkinter dnd has no documentation
by Daniel Swanson April 30, 2017

April 30, 2017

New submission from Daniel Swanson <popcorn.tomato.dude(a)gmail.com>: The title should be self explanatory. I needed Drag-and-drop for a project I was working on, (maybe I shouldn't be refering to it in the past tense as I haven't started yet) so I checked the documentation for tkinter and found: 3.3.0 b1 tkinter.dnd Drag-and-drop support for tkinter. This is experimental and should become deprecated when it is replaced with the Tk DND. 3.2.2 (and .2.3) tkinter.dnd Drag-and-drop support for tkinter. This is experimental and should become deprecated when it is replaced with the Tk DND. 2.7.3 Tkdnd Drag-and-drop support for Tkinter. This is experimental and should become deprecated when it is replaced with the Tk DND. I think that tkinter.dnd needs some documentation, whether or not it is replaced with Tk DND. ---------- assignee: docs@python components: Documentation messages: 165392 nosy: docs@python, weirdink13 priority: normal severity: normal status: open title: Tkinter dnd has no documentation versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15346> _______________________________________

4 10

[issue29576] Improve some deprecations in the importlib
by Matthias Bussonnier April 29, 2017

April 29, 2017

New submission from Matthias Bussonnier: A couple of function in importlib are marked as deprecated in the documentation but do not raise deprecation warnings. As the same time it would be great to improve some deprecation warnings and docstring to include the version since when this is deprecated. This should be take care of by https://github.com/python/cpython/pull/32 ---------- assignee: docs@python components: Documentation messages: 287908 nosy: docs@python, mbussonn priority: normal pull_requests: 88 severity: normal status: open title: Improve some deprecations in the importlib type: enhancement versions: Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue29576> _______________________________________

8 10

[issue28851] namedtuples field_names sequence preferred
by Francesco Grondona April 26, 2017

April 26, 2017

New submission from Francesco Grondona: A change by mhettinger in the doc of Python 2 years ago implicitely stated a sequence of strings as preferred way to provide 'field_names' to a namedtuple: https://github.com/python/cpython/commit/7be6326e09f2062315f995a18ab54baedf… Same change should be integrated in Python 3, I see no reason to prefer the single string version. ---------- assignee: docs@python components: Documentation messages: 282177 nosy: docs@python, peentoon priority: normal severity: normal status: open title: namedtuples field_names sequence preferred type: enhancement 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/issue28851> _______________________________________

5 10

[issue29952] "keys and values" is preferred to "keys and elements" for name of dict constituent
by Kinebuchi Tomohiko April 22, 2017

April 22, 2017

New submission from Kinebuchi Tomohiko: In the section "6.10.1. Value comparisons" [1]_:: Equality comparison of the keys and elements enforces reflexivity. would be Equality comparison of the keys and values enforces reflexivity. because we usually call an entry of dict as "key-value pair". .. [1] https://docs.python.org/3.6/reference/expressions.html#value-comparisons ---------- assignee: docs@python components: Documentation messages: 290890 nosy: cocoatomo, docs@python priority: normal severity: normal status: open title: "keys and values" is preferred to "keys and elements" for name of dict constituent versions: Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue29952> _______________________________________

4 10

[issue29387] Tabs vs spaces FAQ out of date
by Martin Panter April 20, 2017

April 20, 2017

New submission from Martin Panter: The Windows FAQ <https://docs.python.org/release/3.5.2/faq/windows.html#how-do-i-keep-editor…> mentions the “python -t” command-line option, but in Python 3 this option is undocumented (and I understand has no effect): /media/disk/home/proj/python/cpython/Doc/faq/windows.rst:303: WARNING: unknown option: -t Also, the reference to the tabnanny script is wrong. It exists as a module (Lib/tabnanny.py), not in Tools/scripts/. This aspect also applies to 2.7. ---------- assignee: docs@python components: Documentation, Windows files: tabnanny.patch keywords: patch messages: 286460 nosy: docs@python, martin.panter, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal stage: patch review status: open title: Tabs vs spaces FAQ out of date versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file46450/tabnanny.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue29387> _______________________________________

8 16

[issue19225] lack of PyExc_BufferError doc
by hiroaki itoh April 20, 2017

April 20, 2017

New submission from hiroaki itoh: http://docs.python.org/2.7/c-api/exceptions.html#standard-exceptions Python2.7 (at least 2.7.5) has PyExc_BufferError, but the document does not tell it. ---------- assignee: docs@python components: Documentation messages: 199458 nosy: docs@python, xwhhsprings priority: normal severity: normal status: open title: lack of PyExc_BufferError doc type: behavior versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue19225> _______________________________________

9 30

[issue23174] shelve.open fails with error "anydbm.error: db type could not be determined"
by Karl Richter April 17, 2017

April 17, 2017

New submission from Karl Richter: `shelve.open(tempfile.mkstemp()[1])` fails with error "anydbm.error: db type could not be determined" which is not explainable with the docs. Traceback is Traceback (most recent call last): File "./cudaminer_param_checker.py", line 720, in <module> plac.call(cudaminer_param_checker) File "/usr/local/lib/python2.7/dist-packages/plac_core.py", line 309, in call cmd, result = parser_from(obj).consume(arglist) File "/usr/local/lib/python2.7/dist-packages/plac_core.py", line 195, in consume return cmd, self.func(*(args + varargs + extraopts), **kwargs) File "./cudaminer_param_checker.py", line 715, in cudaminer_param_checker visualize_cudaminer_param_checker_results_wxpython_gui() File "./cudaminer_param_checker.py", line 365, in visualize_cudaminer_param_checker_results_wxpython_gui frame = CudaminerParamChecker(None, ) File "./cudaminer_param_checker.py", line 378, in __init__ self.generator = CudaminerParamCheckerGenerator() File "./cudaminer_param_checker.py", line 160, in __init__ self.result_dict= shelve.open(storage_file_path) File "/usr/lib/python2.7/shelve.py", line 239, in open return DbfilenameShelf(filename, flag, protocol, writeback) File "/usr/lib/python2.7/shelve.py", line 223, in __init__ Shelf.__init__(self, anydbm.open(filename, flag), protocol, writeback) File "/usr/lib/python2.7/anydbm.py", line 82, in open raise error, "db type could not be determined" anydbm.error: db type could not be determined ---------- assignee: docs@python components: Documentation messages: 233488 nosy: docs@python, krichter priority: normal severity: normal status: open title: shelve.open fails with error "anydbm.error: db type could not be determined" type: behavior versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue23174> _______________________________________

6 13

[issue29378] Invalid example in documentation for PyErr_Fetch
by Kaeptm Blaubaer April 15, 2017

April 15, 2017

New submission from Kaeptm Blaubaer: In the example are the pointers to pointers to PyObject too many, because then PyErr_Fetch and PyErr_Restore would get too many pointers to pointers. ---------- assignee: docs@python components: Documentation messages: 286321 nosy: Kaeptm Blaubaer, docs@python priority: normal severity: normal status: open title: Invalid example in documentation for PyErr_Fetch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue29378> _______________________________________

3 6

[issue25632] Document BUILD_*_UNPACK opcodes
by Antony Lee April 15, 2017

April 15, 2017

New submission from Antony Lee: The additional unpack generalizations provided by Python3.5 rely on a new set of opcodes, BUILD_{TUPLE,LIST,DICT,SET}_UNPACK, that are not documented in the docs for the dis module. ---------- assignee: docs@python components: Documentation messages: 254715 nosy: Antony.Lee, docs@python priority: normal severity: normal status: open title: Document BUILD_*_UNPACK opcodes versions: Python 3.5, Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue25632> _______________________________________

2 1