docs November 2019

docs@python.org

12 participants
298 discussions

[issue34394] Descriptors HowTo doesn't mention __set_name__

by Semyon

New submission from Semyon <simeon+bpo(a)maryasin.name>: There is a great HowTo document for descriptors https://github.com/python/cpython/blob/master/Doc/howto/descriptor.rst But it doesn't even mention the __set_name__ method which was added in py3. And it lists the descriptor protocol without that method as if it is the full protocol. The only way to know about that method is to go to the link for any other method and then you'll see that there is a __set_name__. I think the guide sholud be updated to include at least information about existence of __set_name__. ---------- assignee: docs@python components: Documentation messages: 323479 nosy: MarSoft, docs@python priority: normal severity: normal status: open title: Descriptors HowTo doesn't mention __set_name__ 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/issue34394> _______________________________________

1 hour, 35 minutes

[issue25509] PyImport_ImportModule inaccurately described

by Memeplex

New submission from Memeplex: The documentation (for 3.5) states that "[PyImport_ImportModule] is a simplified interface to PyImport_ImportModuleEx()" but the current implementation calls PyImport_Import instead, which is a higher level interface that takes into account import hooks. Older versions of PyImport_ImportModule (say 2.0) did call PyImport_ImportModuleEx, but that's no longer the case. The PyImport_Import* naming convention got a bit messy with the years and maybe I'm not understanding the intention quite well, but it seems to me that the documentation is outdated and that there is a change in semantics for PyImport_ImportModule. ---------- assignee: docs@python components: Documentation messages: 253674 nosy: docs@python, memeplex priority: normal severity: normal status: open title: PyImport_ImportModule inaccurately described versions: Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue25509> _______________________________________

5 hours, 26 minutes

[issue26515] Update extending/embedding docs to new way to build modules in C

by Brett Cannon

New submission from Brett Cannon: https://docs.python.org/3/extending/extending.html#a-simple-example uses PyModule_Create() instead of PyModuleDef_Init(). ---------- assignee: docs@python components: Documentation messages: 261398 nosy: brett.cannon, docs@python, eric.snow, ncoghlan priority: normal severity: normal stage: needs patch status: open title: Update extending/embedding docs to new way to build modules in C versions: Python 3.5, Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue26515> _______________________________________

9 hours, 1 minute

[issue38486] Dead links in mailbox doc

by Inada Naoki

New submission from Inada Naoki <songofacandy(a)gmail.com>: Reported on mailing list: https://mail.python.org/archives/list/docs@python.org/thread/NIXFQMWFNSNO6R… qmail.org is dead. The mailbox doc [1] contains two links to man pages in qmail.org. Can we just remove them? [1] https://docs.python.org/3/library/mailbox.html ---------- assignee: docs@python components: Documentation messages: 354738 nosy: docs@python, inada.naoki priority: normal severity: normal status: open title: Dead links in mailbox doc versions: Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue38486> _______________________________________

21 hours, 37 minutes

[issue9499] Python C/API Execution namespace undocumented. (patch included)

by Campbell Barton

New submission from Campbell Barton <ideasman42(a)gmail.com>: Some parts of the python api expect __main__ module dictionary to be the namespace when executing a script, this is true when running a python script from the python binary but NOT true when running a compiled script from the C/API which can lead to bugs which are not easy to solve unless the C/API author knows this. ---------- assignee: docs@python components: Documentation files: doc_py3_main_mod.diff keywords: patch messages: 112706 nosy: docs@python, ideasman42 priority: normal severity: normal status: open title: Python C/API Execution namespace undocumented. (patch included) type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file18357/doc_py3_main_mod.diff _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue9499> _______________________________________

22 hours, 33 minutes

[issue12174] Multiprocessing logging levels unclear

by JJeffries

New submission from JJeffries <jamesjeffries1(a)gmail.com>: It is unclear without reference to the logging module where the multiprocessing logging levels fit in the normal logging provided by the logging module, even though it says above the table "The table below illustrates where theses fit in the normal level hierarchy. +----------------+----------------+ | Level | Numeric value | +================+================+ | ``SUBWARNING`` | 25 | +----------------+----------------+ | ``SUBDEBUG`` | 5 | +----------------+----------------+" I propose adding further values from the logging module for clarification. ---------- assignee: docs@python components: Documentation messages: 136839 nosy: JJeffries, docs@python priority: normal severity: normal status: open title: Multiprocessing logging levels unclear versions: Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12174> _______________________________________

23 hours, 11 minutes

[issue13047] imp.find_module("") and imp.find_module(".")

by Arfrever Frehtes Taifersar Arahesis

New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA(a)GMail.Com>: It's undocumented that imp.find_module("") and imp.find_module(".") try to find __init__.py. There is also a small difference in behavior between them. sys.path by default contains "" as the first element, which is sufficient for imp.find_module("."), but not for imp.find_module(""): $ mkdir /tmp/imp_tests $ cd /tmp/imp_tests $ touch __init__.py $ python3.3 -c 'import imp, sys; print(repr(sys.path[0])); print(imp.find_module("."))' '' (None, '.', ('', '', 5)) $ python3.3 -c 'import imp, sys; print(repr(sys.path[0])); print(imp.find_module(""))' '' Traceback (most recent call last): File "<string>", line 1, in <module> ImportError: No module named '' If sys.path contains path (e.g. "." or absolute path) to directory with __init__.py file, then imp.find_module("") will succeed: $ PYTHONPATH="." python3.3 -c 'import imp, sys; print(repr(sys.path[0:2])); print(imp.find_module("."))' ['', '/tmp/imp_tests'] (None, '.', ('', '', 5)) $ PYTHONPATH="." python3.3 -c 'import imp, sys; print(repr(sys.path[0:2])); print(imp.find_module(""))' ['', '/tmp/imp_tests'] (None, '/tmp/imp_tests/', ('', '', 5)) $ python3.3 -c 'import imp, sys; sys.path.insert(1, "."); print(repr(sys.path[0:2])); print(imp.find_module("."))' ['', '.'] (None, '.', ('', '', 5)) $ python3.3 -c 'import imp, sys; sys.path.insert(1, "."); print(repr(sys.path[0:2])); print(imp.find_module(""))' ['', '.'] (None, './', ('', '', 5)) I think that imp.find_module(".") and imp.find_module("") should have the same behavior, and this behavior should be documented. ---------- assignee: docs@python components: Documentation, Interpreter Core messages: 144531 nosy: Arfrever, docs@python priority: normal severity: normal status: open title: imp.find_module("") and imp.find_module(".") versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13047> _______________________________________

1 day, 1 hour

[issue14979] pdb: Link to source

by anatoly techtonik

New submission from anatoly techtonik <techtonik(a)gmail.com>: http://docs.python.org/library/pdb.html#pdb.Pdb Documentation for pdb says: "The debugger is extensible — it is actually defined as the class Pdb. This is currently undocumented but easily understood by reading the source." There should a link to the source. ---------- assignee: docs@python components: Documentation, Library (Lib) messages: 162074 nosy: docs@python, techtonik priority: normal severity: normal status: open title: pdb: Link to source _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue14979> _______________________________________

1 day, 2 hours

[issue35181] Doc: Namespace Packages: Inconsistent documentation of __loader__ being None

by Julien Palard

New submission from Julien Palard <julien+python(a)palard.fr>: The documentation states that a __loader__ of a namespace package should be None: - [1] "For namespace packages this should be set to None." - [2] "To indicate to the import machinery that the spec represents a namespace portion. the path entry finder sets “loader” on the spec to None". But this looks wrong [3], looks like it has been changed in [4]/[5]. I think one should rely on __file__ being None on namespace packages (which make sense as they span over multiple directories) instead of __loader__ being None (a side effect of the import machinery ?). [1]: https://docs.python.org/3/library/importlib.html#importlib.machinery.Module… [2]: https://docs.python.org/3/reference/import.html#path-entry-finder-protocol [3]: https://stackoverflow.com/questions/52869541/namespace-package-spec-loader-… [4]: https://bugs.python.org/issue32303 [5]: https://github.com/python/cpython/pull/5481/files#diff-a6592cec2ebc8dba9bbf… ---------- assignee: docs@python components: Documentation messages: 329392 nosy: docs@python, mdk priority: normal severity: normal status: open title: Doc: Namespace Packages: Inconsistent documentation of __loader__ being None versions: Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue35181> _______________________________________

1 day, 23 hours

[issue19438] Where is NoneType in Python 3?

by mpb

New submission from mpb: types.NoneType seems to have disappeared in Python 3. This is probably intentional, but I cannot figure out how to test if a variable is of type NoneType in Python 3. Specifically, I want to write: assert type (v) in ( bytes, types.NoneType ) Yes, I could write: assert v is None or type (v) is bytes But the first assert statement is easier to read (IMO). Here are links to various Python 3 documentation about None: [1] http://docs.python.org/3/library/stdtypes.html#index-2 [2] http://docs.python.org/3/library/constants.html#None Link [2] says: "None The sole value of the type NoneType." However, NoneType is not listed in the Python 3 documentation index. (As compared with the Python 2 index, where NoneType is listed.) [3] http://docs.python.org/3/library/types.html If NoneType is gone in Python 3, mention of NoneType should probably be removed from link [2]. If NoneType is present in Python 3, the docs (presumably at least one of the above links, and hopefully also the index) should tell me how to use it. Here is another link: [4] http://docs.python.org/3/library/stdtypes.html#bltin-type-objects "The standard module types defines names for all standard built-in types." (Except <class 'NoneType'> ???) None is a built-in constant. It has a type. If None's type is not considered to be a "standard built-in type", then IMO this is surprising(!!) and should be documented somewhere (for example, at link [4], and possibly elsewhere as well.) Thanks! ---------- assignee: docs@python components: Documentation messages: 201666 nosy: docs@python, mpb priority: normal severity: normal status: open title: Where is NoneType in Python 3? versions: Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue19438> _______________________________________

2 days, 2 hours

Jump to page:

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

docs November 2019