Mailman 3 November 2015 - docs

[issue19225] lack of PyExc_BufferError doc
by hiroaki itoh 20 Apr '17

20 Apr '17

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 17 Apr '17

17 Apr '17

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

[issue25632] Document BUILD_*_UNPACK opcodes
by Antony Lee 15 Apr '17

15 Apr '17

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

[issue15369] pybench and test.pystone poorly documented
by Florent Xicluna 31 Mar '17

31 Mar '17

New submission from Florent Xicluna <florent.xicluna(a)gmail.com>: The benchmarking tools "pystones" and "pybench" which are shipped with the Python standard distribution are not documented. The only information is in the what's-new for Python 2.5: http://docs.python.org/dev/whatsnew/2.5.html?highlight=pybench#new-improved… IMHO, they should be mentioned somewhere in the HOWTOs, the FAQ or the standard library documentation ("Development Tools" or "Debugging and Profiling") ---------- assignee: docs@python components: Benchmarks, Documentation messages: 165603 nosy: docs@python, flox priority: normal severity: normal status: open title: pybench and test.pystone poorly documented type: behavior versions: Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15369> _______________________________________

7 17

[issue22392] Clarify documentation of __getinitargs__
by David Gilman 30 Mar '17

30 Mar '17

New submission from David Gilman: Implementations of __getinitargs__ return a tuple of the positional arguments for __init__. This wasn't initially apparent to me after reading the docs: I thought you were passing a tuple (args, kwargs) that would get called f(*args, **kwargs) and had to go to the pickle implementation to find out what you were supposed to do. The proposed documentation enhancement: mention that you're just supposed to return a tuple of positional args and that it doesn't support kwargs. ---------- assignee: docs@python components: Documentation messages: 226795 nosy: David.Gilman, docs@python priority: normal severity: normal status: open title: Clarify documentation of __getinitargs__ type: enhancement versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue22392> _______________________________________

5 8

[issue16011] "in" should be consistent with return value of __contains__
by Neal Parikh 29 Mar '17

29 Mar '17

New submission from Neal Parikh: The Python 2.7.3 documentation says the following about defining __contains__: "Called to implement membership test operators. Should return true if item is in self, false otherwise. For mapping objects, this should consider the keys of the mapping rather than the values or the key-item pairs." This suggests that while you should return True/False, you don't need to. Also, the documentation doesn't say that if you return a value other than True or False, it will silently coerce other values to be True or False when you use "in". For example: >>> class Foo(object): ... def __contains__(self, item): return 42 ... >>> foo = Foo() >>> 3 in foo True >>> foo.__contains__(3) 42 When __contains__ is defined, "in" should return whatever __contains__ returns, even if this value is neither True nor False. That would be consistent with, for example, the comparison operators: You can return anything from __lt__ and "x < 4" will correctly pass along that value regardless of what it is. ---------- assignee: docs@python components: Documentation, Interpreter Core messages: 171085 nosy: docs@python, nparikh priority: normal severity: normal status: open title: "in" should be consistent with return value of __contains__ type: behavior versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16011> _______________________________________

10 25

[issue20314] Potentially confusing formulation in 6.1.4. Template strings
by Gerrit Holl 28 Mar '17

28 Mar '17

New submission from Gerrit Holl: The standard library documentation “6.1. string — Common string operations” describes string formatting through the `.format` method and the corresponding mini-language, and the `Template` class. In the part describing the `Template` class (6.1.4) is the text: > Instead of the normal %-based substitutions, Templates support $-based substitutions, using the following rules: This is potentially confusing. The documentation in this section has not made any mention of %-based substitutions. Rather, a novel reader may, at this point, think that {}-based substitution is normal. I would suggest to resolve this issue by simply not mentioning %-based substitutions, replacing the sentence above by: > Templates support $-based substitutions, using the following rules: ---------- assignee: docs@python components: Documentation messages: 208553 nosy: Gerrit.Holl, docs@python priority: normal severity: normal status: open title: Potentially confusing formulation in 6.1.4. Template strings type: enhancement versions: Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue20314> _______________________________________

4 10

[issue19824] string.Template: Add PHP-style variable expansion example
by anatoly techtonik 28 Mar '17

28 Mar '17

New submission from anatoly techtonik: http://docs.python.org/2/library/string.html#template-strings This class could be more useful with the following example: >>> from string import Template >>> t = Template('$who likes $what') >>> who = 'tim' >>> what = 'kung pao' >>> t.substitute(locals()) 'tim likes kung pao' This will help PHP folks to transition their .php files. ---------- assignee: docs@python components: Documentation messages: 204677 nosy: docs@python, techtonik priority: normal severity: normal status: open title: string.Template: Add PHP-style variable expansion example _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue19824> _______________________________________

5 15

[issue22594] Add a link to the regex module in re documentation
by Serhiy Storchaka 25 Mar '17

25 Mar '17

New submission from Serhiy Storchaka: The regex module is purposed as a replacement of standard re module. Of course we fix re bugs, but for now regex is more bugfree. Even after fixing all open re bugs, regex will remain more featured. It would be good to add a link to regex in re documentation (as there are links to other GUI libraries in Tkinter documentation). ---------- assignee: docs@python components: Documentation, Regular Expressions keywords: easy messages: 228961 nosy: docs@python, ezio.melotti, mrabarnett, pitrou, serhiy.storchaka priority: normal severity: normal status: open title: Add a link to the regex module in re documentation type: enhancement versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue22594> _______________________________________

11 26

[issue24796] Deleting names referencing from enclosed and enclosing scopes
by Nick Coghlan 23 Mar '17

23 Mar '17

New submission from Nick Coghlan: While committing issue #24129, I noticed the following in the execution model documentation: ================== If a variable is referenced in an enclosing scope, it is illegal to delete the name. An error will be reported at compile time. ================== I'm not sure what that means, as both of the following compiled fine for me under 3.4.2: >>> def f(): ... x = 1 ... def g(): ... nonlocal x ... del x ... >>> def f(): ... x = 1 ... del x ... def g(): ... print(x) ... ---------- assignee: docs@python components: Documentation messages: 248036 nosy: docs@python, ncoghlan priority: normal severity: normal status: open title: Deleting names referencing from enclosed and enclosing scopes _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue24796> _______________________________________

4 9