docs November 2018

docs@python.org

20 participants
535 discussions

[issue16386] imp.find_module does not specify registry key it searches on windows

by Jan Duzinkiewicz

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> _______________________________________

5 months

[issue35114] ssl.RAND_status docs describe it as returning True/False; actually returns 1/0

by Josh Rosenberg

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> _______________________________________

5 months

[issue11977] Document int.conjugate, .denominator, ...

by Jonas H.

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> _______________________________________

5 months

[issue32133] documentation: numbers module nitpick

by abcdef

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> _______________________________________

5 months

[issue21352] improve indexing

by bob gailer

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> _______________________________________

5 months

[issue19023] ctypes docs: Unimplemented and undocumented features

by Sye van der Veen

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> _______________________________________

5 months

[issue34078] Broken CRL functionality in ssl.py

by Joe N

New submission from Joe N <nettijoe(a)gmail.com>: CRLs in ssl.py or at the documentation is broken. Specifically I think the documentation here is wrong: https://docs.python.org/3/library/ssl.html#ssl.SSLContext.load_verify_locat… Here is a stackoverflow post: https://stackoverflow.com/questions/51196492/how-to-use-crls-in-pyopenssl?n… I made a very user friendly test suite of files to show how it is broken. Run the code in here (follow readme instructions) to see the bug. https://github.com/nettijoe96/bugInSSL ---------- assignee: christian.heimes components: SSL messages: 321343 nosy: Joe N, christian.heimes, docs@python priority: normal severity: normal status: open title: Broken CRL functionality in ssl.py type: behavior versions: Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue34078> _______________________________________

5 months, 1 week

[issue22128] patch: steer people away from codecs.open

by Frank van Dijk

New submission from Frank van Dijk: stackoverflow.com has a zillion answers recommending the use of codecs.open() as a unicode capable drop in replacement for open(). This probably means that there is still a lot of code being written that uses codecs.open(). That's bad thing because of codecs.open()'s lack of newline conversion. A lot of that code will - have compatibility issues when it is moved between unix and windows - silently break text files on windows, leading to issues further downstream (confusing other tools, messing up revision control histories) The problem has been fixed with io.open() in 2.x and open() in 3.x. Unfortunately the 2.7 unicode HOWTO still recommends the use of codecs.open(). The 2.7 and the 3.x documentation of codecs.open() doesn't refer the reader to better alternatives. The attached patches fix that. The only downside I see is that newly written code that uses the better alternatives would be incompatible with 2.5 and older. However croaking on a small minority of systems is better than silently disrupting workflows, causing platform incompatibilities, and inviting flaky workarounds. The 2.7 patch makes the unicode HOWTO recommend io.open() instead of codecs.open(). Both patches change the codecs.open() documentation to refer to io.open() or (on 3.x) open(). Additionally I removed the "data loss" explanation from codecs.open()'s note about its lack of newline conversion. It is not particularly helpful information and it is not entirely correct (data loss could also have been avoided by doing newline conversion before encoding and after decoding) ---------- assignee: docs@python components: Documentation files: codecsopen2.patch keywords: patch messages: 224632 nosy: Frank.van.Dijk, docs@python priority: normal severity: normal status: open title: patch: steer people away from codecs.open type: behavior versions: Python 2.7, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file36234/codecsopen2.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue22128> _______________________________________

5 months, 1 week

[issue28197] range.index mismatch with documentation

by Vedran Čačić

New submission from Vedran Čačić: Look at this: >>> from collections.abc import Sequence >>> help(Sequence.index) index(self, value, start=0, stop=None) S.index(value, [start, [stop]]) -> integer -- return first index of value. Raises ValueError if the value is not present. >>> issubclass(range, Sequence) True >>> help(range.index) index(...) rangeobject.index(value, [start, [stop]]) -> integer -- return index of value. Raise ValueError if the value is not present. So far, so good. But: >>> range(9).index(2, 1, 5) TypeError: index() takes exactly one argument (3 given) Of course it's not essential, but the docs shouldn't lie. And if range _is_ a Sequence, then it should have the complete interface of a Sequence. Including start and end arguments for .index: they are optional from the point of call, not from the point of implementation. :-) ---------- assignee: docs@python components: Documentation, Library (Lib) messages: 276908 nosy: docs@python, veky priority: normal severity: normal status: open title: range.index mismatch with documentation type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue28197> _______________________________________

5 months, 1 week

[issue20364] Rename & explain sqlite3.Cursor.execute 'parameters' param

by Terry J. Reedy

New submission from Terry J. Reedy: "execute(sql[, parameters]) Executes an SQL statement. The SQL statement may be parametrized (i. e. placeholders instead of SQL literals). The sqlite3 module supports two kinds of placeholders: question marks (qmark style) and named placeholders (named style)." Experimental facts based on experiments with the code example in the doc, using 3.4.b2: 'parameters' is a single subscriptable collection parameter, sequence or dict, that might be called seq_dict. It is positional only, so whatever name is used is a dummy. Only one placeholder style can be used in a given SQL statement string. If question marks are used, seq_dict must be a sequence. If names are used, seq_dict can be either a sequence or dict or subclass thereof. A UserDict is treated as a sequence and raises KeyError(0). Possible text that encompasses the above, replacing the last sentence: "A statement may use one of two kinds of placeholders: question marks (qmark style) or named placeholders (named style). For qmark style, seq_dict must be a sequence. For named style, it can be either a sequence or dict instance. Len(seq_dict) must match the number of placeholders." After cleaning up the test file, I will verify on 2.7 and upload. ---------- assignee: docs@python components: Documentation, Library (Lib) messages: 208908 nosy: docs@python, terry.reedy priority: normal severity: normal stage: patch review status: open title: Rename & explain sqlite3.Cursor.execute 'parameters' param type: behavior versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue20364> _______________________________________

5 months, 1 week

Jump to page:

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

docs November 2018