Mailman 3 November 2020 - docs

[issue10709] Misc/AIX-NOTES needs updating
by Antoine Pitrou 11 Nov '20

11 Nov '20

New submission from Antoine Pitrou <pitrou(a)free.fr>: Sébastien, would you like to provide an updated version of that file? The current contents look hopelessly outdated. ---------- assignee: docs@python components: Documentation messages: 124024 nosy: docs@python, pitrou, sable priority: normal severity: normal stage: needs patch status: open title: Misc/AIX-NOTES needs updating versions: Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10709> _______________________________________

5 14

[issue42314] Incorrect documentation entry for venv
by Adrien 11 Nov '20

11 Nov '20

New submission from Adrien <niedra91(a)hotmail.com>: Hello, I am reading the venv official documentation available here: https://docs.python.org/3/library/venv.html If I pick English - 3.9.0, it's stated: "Changed in version 3.8: Add --upgrade-deps option to upgrade pip + setuptools to the latest on PyPI" When I run this my laptop: $ python3 --version Python 3.8.5 $ python3 -m venv venv-myproject --clear --upgrade-deps usage: venv [-h] [--system-site-packages] [--symlinks | --copies] [--clear] [--upgrade] [--without-pip] [--prompt PROMPT] ENV_DIR [ENV_DIR ...] venv: error: unrecognized arguments: --upgrade-deps If I pick English - 3.8(.6), I (correctly) don't see the option in the documentation. Please fix the documentation of 3.9 to indicates that this option was changed (added) in 3.9 and not 3.8 Thanks! Adrien ---------- assignee: docs@python components: Documentation messages: 380684 nosy: ari75, docs@python priority: normal severity: normal status: open title: Incorrect documentation entry for venv type: enhancement versions: Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue42314> _______________________________________

3 3

[issue42292] C API: Allocating Objects on the Heap. Misleading documentation.
by igo95862 11 Nov '20

11 Nov '20

New submission from igo95862 <igo9586(a)gmail.com>: The issue is that the function names are too similar to other function that do completely different things. `PyObject_Init` this function does not use `__init__` at all. What it does is sets the already allocated object pointer to the specific type and increments its reference. `PyObject_New` this function has nothing to do with `__new__`. It mallocs the new object and when calls `PyObject_Init` to set its type and increment reference. Most importantly neither function actually calls `__init__`. You need to do it manually otherwise you might get garbage in your object data from residual memory. I think there should be a small example showing how to allocate objects on heap and initialize them. This is what I do (ignore the names): ``` SdBusMessageObject *message_object = PyObject_NEW(SdBusMessageObject, &SdBusMessageType); SdBusMessageType.tp_init((PyObject *)message_object, NULL, NULL); ``` ---------- assignee: docs@python components: Documentation messages: 380558 nosy: docs@python, igo95862 priority: normal severity: normal status: open title: C API: Allocating Objects on the Heap. Misleading documentation. versions: Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue42292> _______________________________________

1 2

[issue15034] tutorial should use best practices in user defined execeptions section
by R. David Murray 11 Nov '20

11 Nov '20

New submission from R. David Murray <rdmurray(a)bitdance.com>: And I wish I knew what those were. ---------- assignee: docs@python components: Documentation messages: 162513 nosy: docs@python, r.david.murray priority: normal severity: normal stage: needs patch status: open title: tutorial should use best practices in user defined execeptions section type: behavior versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15034> _______________________________________

11 16

[issue16781] execfile/exec execution in other than global scope uses locals(), leading to undefined behavior
by Irit Katriel 10 Nov '20

10 Nov '20

Change by Irit Katriel <iritkatriel(a)yahoo.com>: ---------- versions: +Python 3.10, Python 3.8, Python 3.9 -Python 2.6, Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue16781> _______________________________________

1 0

[issue34365] datetime's documentation refers to "comparison [...] falling back to the default scheme of comparing object addresses"
by Kevin Norris 10 Nov '20

10 Nov '20

New submission from Kevin Norris <nykevin.norris(a)gmail.com>: The 3.x datetime documentation contains the following footnote: > In other words, date1 < date2 if and only if date1.toordinal() < date2.toordinal(). In order to stop comparison from falling back to the default scheme of comparing object addresses, date comparison normally raises TypeError if the other comparand isn’t also a date object. However, NotImplemented is returned instead if the other comparand has a timetuple() attribute. This hook gives other kinds of date objects a chance at implementing mixed-type comparison. If not, when a date object is compared to an object of a different type, TypeError is raised unless the comparison is == or !=. The latter cases return False or True, respectively. But in 3.x, comparison no longer falls back to comparing object addresses. Also, some of the comments on issue 8005 seem to suggest that this footnote is not actually true in 3.x (aside from the first sentence, of course). But regardless, the footnote should not refer to a long dead interpreter behavior as if it were still around. ---------- assignee: docs@python components: Documentation messages: 323314 nosy: Kevin.Norris, docs@python priority: normal severity: normal status: open title: datetime's documentation refers to "comparison [...] falling back to the default scheme of comparing object addresses" versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue34365> _______________________________________

7 12

[issue42298] Documented interaction of single-stage init and sub-interpreters inaccurate
by pkerling 09 Nov '20

09 Nov '20

New submission from pkerling <9b6ab161(a)casix.org>: The C API documentation says this about single-phase initialization and sub-interpreters: "[T]he first time a particular extension is imported, it is initialized normally, and a (shallow) copy of its module’s dictionary is squirreled away. When the same extension is imported by another (sub-)interpreter, a new module is initialized and filled with the contents of this copy; the extension’s init function is not called." - from https://docs.python.org/3.10/c-api/init.html#c.Py_NewInterpreter I was investigating crashes relating to the _datetime module and sub-interpreters and from my observations, this does not seem to be true. I have tracked this functionality down to the m_base.m_copy dictionary of the PyModuleDef of an extension and the functions _PyImport_FixupExtensionObject and _PyImport_FindExtensionObject in Python/import.c. However, modules are only ever added to the `extensions` global when imported in the main interpreter, see https://github.com/python/cpython/blob/1f73c320e2921605c4963e202f6bdac1ef18… Furthermore, even if they were added and m_base.m_copy was set, it would be cleared again on sub-interpreter shutdown here: https://github.com/python/cpython/blob/1f73c320e2921605c4963e202f6bdac1ef18… - implying that the module will be loaded and initialized again next time due to this check: https://github.com/python/cpython/blob/1f73c320e2921605c4963e202f6bdac1ef18… These observations are supported by the fact that in my tests, if "import _datetime" is ran subsequently in two different sub-interpreters, PyInit__datetime is indeed called twice. Test code - set a breakpoint on PyInit__datetime to observe the behavior: #include <Python.h> #include <assert.h> int main() { Py_Initialize(); for (int i = 0; i < 100; ++i) { PyThreadState* ts = Py_NewInterpreter(); assert(ts); int result = PyRun_SimpleString("import _datetime"); assert(result == 0); Py_EndInterpreter(ts); } return 0; } In summary, it seems to me that the documented behavior is not accurate (any more?) - so either the docs or the implementation should change. ---------- assignee: docs@python components: Documentation messages: 380602 nosy: docs@python, pkerling priority: normal severity: normal status: open title: Documented interaction of single-stage init and sub-interpreters inaccurate versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue42298> _______________________________________

1 0

[issue15099] [doc] exec of function doesn't call __getitem__ or __missing__ on undefined global
by Irit Katriel 08 Nov '20

08 Nov '20

Change by Irit Katriel <iritkatriel(a)yahoo.com>: ---------- title: exec of function doesn't call __getitem__ or __missing__ on undefined global -> [doc] exec of function doesn't call __getitem__ or __missing__ on undefined global versions: +Python 3.10, Python 3.8, Python 3.9 -Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue15099> _______________________________________

1 0

[issue1397474] [doc] timeit execution enviroment
by Irit Katriel 08 Nov '20

08 Nov '20

Change by Irit Katriel <iritkatriel(a)yahoo.com>: ---------- title: timeit execution enviroment -> [doc] timeit execution enviroment versions: +Python 3.10, Python 3.8, Python 3.9 -Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue1397474> _______________________________________

1 0

[issue12488] multiprocessing.Connection does not communicate pipe closure between parent and child
by Irit Katriel 08 Nov '20

08 Nov '20

Change by Irit Katriel <iritkatriel(a)yahoo.com>: ---------- versions: +Python 3.10, Python 3.8, Python 3.9 -Python 2.6, Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue12488> _______________________________________

1 0