Mailman 3 October 2019 - docs

[issue26629] Need an ability to build standard DLLs with distutils
by Buraddin Ibn-Karlo 27 Apr '21

27 Apr '21

New submission from Buraddin Ibn-Karlo: I want to make a a dynamic library to run its function with ctypes. Also I want to build the library from sources with distutils (the C++ sources are distributed with my Python code). But alas! Our distutils fails, if the library doesn't have initialization function (something like init_<module_name>). Even if the module does not need any initialization. I did a quick and dirty solution: added a dummy function: void init_<module_name>(){} It somehow works, but I don't think that it is a good idea. Cannot you add the possibility to tell distutils, that this extention module is just a simple DLL, that will be used via ctypes (or somehow else) and it does not need any extra init script? Also, cannot you add an extra section to ctypes documentation? With a description how to build such extensions via distutils? ---------- assignee: docs@python components: Build, Documentation, Extension Modules, Windows, ctypes messages: 262308 nosy: Buraddin Ibn-Karlo, docs@python, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Need an ability to build standard DLLs with distutils type: enhancement versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue26629> _______________________________________

3 3

[issue31055] All Sphinx generated pages could have a new "Edit This Page" link adjacent to the existing "Show Source"
by Paul Hammant 25 Apr '21

25 Apr '21

New submission from Paul Hammant: Show Source links to: https://github.com/python/cpython/blob/path/to/resource.rst Edit This Page would link to https://github.com/python/cpython/edit/path/to/resource.rst And yes, GitHub does the right thing if you're not ordinarily permitted to change python/cpython ---------- assignee: docs@python components: Documentation messages: 299306 nosy: Paul Hammant, docs@python priority: normal severity: normal status: open title: All Sphinx generated pages could have a new "Edit This Page" link adjacent to the existing "Show Source" versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue31055> _______________________________________

6 6

[issue27420] Docs for os.link - say what happens if link already exists
by Niall Mansfield 25 Apr '21

25 Apr '21

New submission from Niall Mansfield: In os.link(source, link_name) Change Create a hard link pointing to source named link_name. to Create a hard link pointing to source named link_name. If link_name already exists, OSError is raised. ---------- assignee: docs@python components: Documentation messages: 269572 nosy: docs@python, python-bugs-uit priority: normal severity: normal status: open title: Docs for os.link - say what happens if link already exists type: enhancement versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue27420> _______________________________________

2 1

[issue35676] class TestCase: docs are not correct
by אורי רודברג 25 Apr '21

25 Apr '21

New submission from אורי רודברג <uri(a)speedy.net>: I think some functions of `class TestCase` are not documented correctly in the docs. For example in https://docs.python.org/3.5/library/unittest.html and also https://docs.python.org/3.6/library/unittest.html and https://docs.python.org/3.7/library/unittest.html. Some of the functions which are not documented correctly: assertListEqual assertSetEqual assertDictEqual assertIsNone And many other functions. You can see some more details on https://github.com/python/typeshed/issues/2716. ---------- assignee: docs@python components: Documentation messages: 333137 nosy: docs@python, אורי רודברג priority: normal severity: normal status: open title: class TestCase: docs are not correct versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue35676> _______________________________________

4 5

[issue16386] imp.find_module does not specify registry key it searches on windows
by Jan Duzinkiewicz 24 Apr '21

24 Apr '21

New submission from Jan Duzinkiewicz: quote from http://docs.python.org/3/library/imp.html#imp.find_module: "...on some systems some other places are looked in as well (on Windows, it looks in the registry which may point to a specific file)." I actually didn't know the registry key is listed in "using Python on Window" guide until I grepped for PythonCore (which kind of requires to know the key already) - so I'm submitting a patch that cross references find_module docs and using Python on Windows guide. ---------- assignee: docs@python components: Documentation files: import_nt_reg.patch keywords: patch messages: 174508 nosy: dhgmgn, docs@python priority: normal severity: normal status: open title: imp.find_module does not specify registry key it searches on windows versions: Python 2.7, Python 3.3 Added file: http://bugs.python.org/file27843/import_nt_reg.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16386> _______________________________________

4 5

[issue35114] ssl.RAND_status docs describe it as returning True/False; actually returns 1/0
by Josh Rosenberg 23 Apr '21

23 Apr '21

New submission from Josh Rosenberg <shadowranger+python(a)gmail.com>: The ssl.RAND_status online docs say (with code format on True/False): "Return True if the SSL pseudo-random number generator has been seeded with ‘enough’ randomness, and False otherwise." This is incorrect; the function actually returns 1 or 0 (and the docstring agrees). Fix can be one of: 1. Update docs to be less specific about the return type (use true/false, not True/False) 2. Update docs to match docstring (which specifically says 1/0, not True/False) 3. Update implementation and docstring to actually return True/False (replacing PyLong_FromLong with PyBool_FromLong and changing docstring to use True/False to match online docs) #3 involves a small amount of code churn, but it also means we're not needlessly replicating a C API's use of int return values when the function is logically bool (there is no error status for the C API AFAICT, so it's not like returning int gains us anything on flexibility). bool would be mathematically equivalent to the original 1/0 return value in the rare cases someone uses it mathematically. ---------- assignee: docs@python components: Documentation, SSL messages: 328917 nosy: docs@python, josh.r priority: low severity: normal status: open title: ssl.RAND_status docs describe it as returning True/False; actually returns 1/0 type: behavior _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue35114> _______________________________________

4 4

[issue11977] Document int.conjugate, .denominator, ...
by Jonas H. 23 Apr '21

23 Apr '21

New submission from Jonas H. <jonas(a)lophus.org>: Various `int` attributes and methods seem undocumented (at least it does not work to intersphinx them): * .conjugate * .denominator * .imag * .numerator * .real ---------- assignee: docs@python components: Documentation messages: 134926 nosy: docs@python, jonash priority: normal severity: normal status: open title: Document int.conjugate, .denominator, ... versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue11977> _______________________________________

6 8

[issue32133] documentation: numbers module nitpick
by abcdef 23 Apr '21

23 Apr '21

New submission from abcdef <x(a)mailinator.com>: Documentation of the numbers module: https://docs.python.org/3/library/numbers.html states "None of the types defined in this module can be instantiated." This is true for Complex, Real, Rational, Integral but not for Number: >>> numbers.Number() <numbers.Number object at 0x7fcccc71f3c0> >>> numbers.Real() Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: Can't instantiate abstract class Real... Since Number doesn't have any abstract methods, the correct fix seems to be changing the documentation. I would try to convey something like this: "The types defined in this module can be used for subclassing and checking whether a specific class is in the numeric hierarchy; they are not used directly for instantiation. For this, you can use types such as `complex` or `fractions.Fraction`". ---------- assignee: docs@python components: Documentation messages: 306970 nosy: abcdef, docs@python priority: normal severity: normal status: open title: documentation: numbers module nitpick type: enhancement versions: Python 2.7, Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue32133> _______________________________________

2 1

[issue21352] improve indexing
by bob gailer 22 Apr '21

22 Apr '21

New submission from bob gailer: Inconsistencies / confusion with documentation Index Tab. Example (line numbers added for comments that follow): 1 max 2 built-in function 3 max (datetime.date attribute) 4 (datetime.datetime attribute) 5 (datetime.time attribute) 6 max() built-in function 7 (decimal.Context method) 8 (decimal.Decimal method) 9 (in module audioloop) The following all lead to confusion and frustration: Having 3 rows (1, 3, 6)that begin with max. Having an entry (1) that does nothing when double-clicked. double-clicking (2) takes us to a reference rather than a definition. RECOMMENDATION: change to: max() built-in function (sequence operation) (decimal.Context method) (decimal.Decimal method) max (datetime.date attribute) (datetime.datetime attribute) (datetime.time attribute) where double-clicking the first line goes to the max() definition in 2. Built-in Functions These comments apply, with a number of variations, to most built-in functions index entries. ---------- assignee: docs@python components: Documentation messages: 217170 nosy: bgailer, docs@python priority: normal severity: normal status: open title: improve indexing type: enhancement versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue21352> _______________________________________

7 6

[issue19023] ctypes docs: Unimplemented and undocumented features
by Sye van der Veen 20 Apr '21

20 Apr '21

New submission from Sye van der Veen: In the ctypes documentation, there's mention of a BigEndianUnion/LittleEndianUnion that isn't actually implemented, and the "Arrays and pointers" section just reads "Not yet written". The attached patch adds the (Big|Little)EndianUnion classes (with tests), finishes the Array/_Pointer class docs (and adds missing cases to the tests), and makes some stylistic improvements to docs. The patch was made against default, but it's quite likely it could be back-ported all the way to Python 3.1. ---------- assignee: docs@python components: Documentation, Tests, ctypes hgrepos: 209 messages: 197764 nosy: docs@python, syeberman priority: normal severity: normal status: open title: ctypes docs: Unimplemented and undocumented features type: enhancement _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue19023> _______________________________________

8 15