Mailman 3 May 2013 - docs

[issue14759] Berkeley DB License conditions are onerous (and poorly documented)
by Jeff Laing April 27, 2020

April 27, 2020

New submission from Jeff Laing <jefflaing(a)gmail.com>: As part of an audit of license compliance, I was looking at the terms in the LICENSE.txt that describe the Berkeley DB product. I had thought this would be under the standard Berkeley license, but Oracle have added their own zinger. * 3. Redistributions in any form must be accompanied by information on * how to obtain complete source code for the DB software and any * accompanying software that uses the DB software. The source code * must either be included in the distribution or be available for no * more than the cost of distribution plus a nominal fee, and must be * freely redistributable under reasonable conditions. So, my application, which embeds Python (rather than running it as python.exe) and includes the standard runtime library, must distribute my source code. This page: http://mail.python.org/pipermail/python-dev/2008-September/082316.html suggests that this is not the case for regular Python, but it makes no statement about "embedding". Sadly the Oracle page it links to suggesting this is not an issue, does not exist. The general "License" page on the Python websites makes no reference whatsoever to Berkeley DB license obligations. I note that there are other modules mentioned on the Licenses webpage that are not in the LICENSES.txt file, and vice versa. I have no idea whether this is deliberate, or an oversight. ---------- assignee: docs@python components: Documentation messages: 160238 nosy: Jeff.Laing, docs@python priority: normal severity: normal status: open title: Berkeley DB License conditions are onerous (and poorly documented) type: enhancement versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue14759> _______________________________________

5 12

[issue17904] bytes should be listed as built-in function for 2.7
by Florent Xicluna April 27, 2020

April 27, 2020

New submission from Florent Xicluna: Looking into the summary table, there's no information about the `bytes` built-in alias for `str`: http://docs.python.org/2/library/functions.html IMHO it should appear in this table (as str, unicode, bytearray) with the appropriate `.. versionadded:`. ---------- assignee: docs@python components: Documentation messages: 188349 nosy: docs@python, flox priority: normal severity: normal status: open title: bytes should be listed as built-in function for 2.7 type: behavior versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue17904> _______________________________________

5 6

[issue13743] xml.dom.minidom.Document class is not documented
by Sandro Tosi April 12, 2020

April 12, 2020

New submission from Sandro Tosi <sandro.tosi(a)gmail.com>: Hello, following up http://mail.python.org/pipermail/docs/2012-January/007026.html I noticed the whole Document class (and relative methods) is not documented. Maybe it is a choice to not document it, or maybe it's just a missing doc, dunno, the's why I'm opening this :) ---------- assignee: docs@python components: Documentation messages: 150935 nosy: docs@python, sandro.tosi priority: normal severity: normal stage: needs patch status: open title: xml.dom.minidom.Document class is not documented versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13743> _______________________________________

6 9

[issue15140] PEP 384 inconsistent with implementation
by Antoine Pitrou April 1, 2020

April 1, 2020

New submission from Antoine Pitrou <pitrou(a)free.fr>: In PEP 384, the PyType_Spec struct has a "const char *doc" that is not present in the implementation (Include/object.h). ---------- assignee: docs@python components: Documentation messages: 163449 nosy: docs@python, loewis, pitrou priority: normal severity: normal stage: needs patch status: open title: PEP 384 inconsistent with implementation type: behavior _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15140> _______________________________________

4 3

[issue15436] __sizeof__ is not documeneted
by Serhiy Storchaka March 22, 2020

March 22, 2020

New submission from Serhiy Storchaka <storchaka(a)gmail.com>: __sizeof__ is not mentioned on page Doc/reference/datamodel.rst together with other special methods. There is no __sizeof__ in index. ---------- assignee: docs@python components: Documentation messages: 166245 nosy: docs@python, storchaka priority: normal severity: normal status: open title: __sizeof__ is not documeneted versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15436> _______________________________________

14 24

[issue17422] language reference should specify restrictions on class namespace
by Eric Snow March 10, 2020

March 10, 2020

New submission from Eric Snow: (related to PEP 422 and issue #17044) The execution namespace from a class definition is passed as the third argument to the metaclass (see builtin___build_class__() in Python/bltinmodule.c). When applicable, which is almost always, the subsequent call to type.__new__() copies that namespace into a new dict which is in turn exposed via the class's __dict__. This matters in the case where a metaclass with __prepare__() gets used (or the PEP 422 equivalent). The language reference[1] should note that the object returned by __prepare__() is copied into a new dict when the class is finally created via the metaclass. [1] http://docs.python.org/3.4/reference/datamodel.html#customizing-class-creat… ---------- assignee: docs@python components: Documentation messages: 184188 nosy: docs@python, eric.snow, ncoghlan priority: normal severity: normal stage: needs patch status: open title: language reference should specify restrictions on class namespace type: enhancement versions: Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue17422> _______________________________________

8 25

[issue13077] Unclear behavior of daemon threads on main thread exit
by etuardu March 9, 2020

March 9, 2020

New submission from etuardu <edonan(a)gmail.com>: The definition of daemon thread in the current documentation reads: «A thread can be flagged as a "daemon thread". The significance of this flag is that the entire Python program exits when only daemon threads are left. [...]» (http://docs.python.org/library/threading.html#thread-objects) I think it's not very clear from this that daemon threads themselves terminate when the program (main thread plus other non-daemon threads) terminates. I think this have to be said more explicitly. I'd propose a change with something like: «A thread can be flagged as a "daemon thread", which means it will get shut down when the overall program terminates. The entire Python program exits when only daemon threads are left.» ---------- assignee: docs@python components: Documentation messages: 144691 nosy: docs@python, etuardu priority: normal severity: normal status: open title: Unclear behavior of daemon threads on main thread exit type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13077> _______________________________________

5 7

[issue17231] Mark __del__ not being called in cycles as an impl detail
by Maciej Fijalkowski March 6, 2020

March 6, 2020

New submission from Maciej Fijalkowski: Here: http://docs.python.org/2/reference/datamodel.html, as per python-dev discussion ---------- assignee: docs@python components: Documentation messages: 182364 nosy: docs@python, fijall priority: normal severity: normal status: open title: Mark __del__ not being called in cycles as an impl detail type: behavior _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue17231> _______________________________________

5 5

[issue8824] Improve documentation of exec
by Terry J. Reedy Feb. 28, 2020

Feb. 28, 2020

New submission from Terry J. Reedy <tjreedy(a)udel.edu>: This doc improvement suggestion is inspired by #991196 (and subsequent duplicates) and the current discussion on py-dev in the thread 'variable name resolution in exec is incorrect' (which is not a correct claim). I believe there is consensus that the doc for exec needs improving. My suggestion (which others may amend) is that the following paragraph (from the 3.x builtin functions exec entry) "In all cases, if the optional parts are omitted, the code is executed in the current scope. If only globals is provided, it must be a dictionary, which will be used for both the global and the local variables. If globals and locals are given, they are used for the global and local variables, respectively. If provided, locals can be any mapping object." have these two sentences added: "If only globals is provided or if onedict is provided as both globals and locals, the code is executed in a new top-level scope. If different objects are given as globals and locals, the code is executed as if it were in a class statement in a new top-level scope." ---------- assignee: docs@python components: Documentation messages: 106552 nosy: docs@python, tjreedy priority: normal severity: normal status: open title: Improve documentation of exec versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue8824> _______________________________________

6 19

[issue15474] Differentiate decorator and decorator factory in docs
by Éric Araujo Feb. 27, 2020

Feb. 27, 2020

New submission from Éric Araujo <merwok(a)netwok.org>: Some of the confusion encountered when writing decorators arise from the difference between a decorator (@something) and a decorator factory (@something(args)). It would help to adopt this clearer terminology in our docs: a decorator takes the decorated function as argument and does its business, a decorator factory takes some arguments and returns a decorator which wraps the decorated function. (I think it was Nick who suggested this in a recent-ish mailing list thread.) ---------- assignee: docs@python components: Documentation messages: 166600 nosy: docs@python, eric.araujo, ncoghlan priority: normal severity: normal status: open title: Differentiate decorator and decorator factory in docs versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15474> _______________________________________

8 14