Mailman 3 February 2021 - docs

[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

[issue39572] [typing] TypedDict's 'total' argument is undocumented
by Brett Cannon 23 Apr '21

23 Apr '21

New submission from Brett Cannon <brett(a)python.org>: The docs mention __total__, but there's no mention of how to actually set that attribute, nor what it actually represents. P.S. https://github.com/python/cpython/blob/master/Lib/typing.py#L16 says TypedDict "may be added soon"; I think that's outdated. ;) ---------- assignee: docs@python components: Documentation messages: 361503 nosy: brett.cannon, docs@python, gvanrossum, levkivskyi priority: normal severity: normal stage: needs patch status: open title: [typing] TypedDict's 'total' argument is undocumented versions: Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue39572> _______________________________________

5 16

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

23 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

[issue36868] New behavior of OpenSSL hostname verification not exposed, incorrectly documented
by Josh Rosenberg 18 Apr '21

18 Apr '21

New submission from Josh Rosenberg <shadowranger+python(a)gmail.com>: The What's New in 3.7 docs mention the change from #31399 to use OpenSSL's built-in hostname verification ( https://docs.python.org/3/whatsnew/3.7.html#ssl ), but aside from that, information about the change is largely undiscoverable and/or wrong. Specific problems: 1. The What's New docs repeatedly mention SSLContext.host_flags as the means of modifying behavior. The actual property is underscore prefixed though, as SSLContext._host_flags. Since SSLContext supports the creation of arbitrary names via __dict__, assigning to context.host_flags silently "works", it just fails to *do* anything (nothing ever reads it). 2. None of the flags are documented anywhere; the only way to discover them is to import _ssl (they're not exposed on ssl itself, just the internal C extension), then scan through the exposed names (they're all prefixed with HOSTFLAG_ AFAICT) 3. All of the flags are raw numeric values, but it seems like they should be IntEnums, like the other flags exposed by SSL (among other things, it would make it much easier to interpret the default _host_flags (currently it's just 4, when it could display as <HostFlags.HOSTFLAG_NO_PARTIAL_WILDCARDS: 4>) 4. Nothing about this change, _host_flags/host_flags, or the values of the flags themselves is mentioned on the ssl docs at all. 5. This unintentionally made a behavioral change (one that bit me, and may bite other folks using docker swarm, NETBIOS hostnames, etc.). Python's match_hostname implementation was fine with host names containing underscores (e.g. if the cert was wildcarded to *.example.com, it would match a_b_c.example.com just fine); they're not technically legal by the strict reading of the specs for host names (they're apparently legal for domain names, but not host names, which differ in ways I don't fully understand), but stuff like docker swarm names their services that way automatically, most (all?) browsers support visiting them, etc. It looks like OpenSSL (at least the 1.1.0g my Python 3.7.2 was built against) treats underscores as unmatchable, so any attempt to connect to such a host name in Python 3.7.2 dies with a SSLCertVerificationError, claiming a "Hostname mismatch, certificate is not valid for 'name_with_underscores.example.com'." I discovered all this because 3.7 broke some scripts I use to connect to docker swarm services. Before I realized the issue was underscores, I was trying to figure out how to tweak the host name checks (assuming maybe something was broken with wildcard matching), and stumbled across all the other issues with the docs, the lack of flag definition exposure, etc. For the record, I think it's reasonable to require legal host names (it was easy enough to fix for my case; I just updated our docker DNS server to provide aliases using only hyphens and changed the script to use the alias host names), but it would be nice if it was explicitly documented, and ideally, that Python itself recognize that underscores won't work and explicitly raise an exception saying why, rather than letting OpenSSL perform the rejection with a (to someone who doesn't know about the underscore issue) confusing error message. ---------- assignee: docs@python components: Documentation, Extension Modules, Library (Lib), SSL keywords: 3.6regression messages: 341990 nosy: christian.heimes, docs@python, josh.r, vstinner priority: normal severity: normal status: open title: New behavior of OpenSSL hostname verification not exposed, incorrectly documented type: behavior versions: Python 3.7, Python 3.8 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue36868> _______________________________________

5 8

[issue34078] Broken CRL functionality in ssl.py
by Joe N 18 Apr '21

18 Apr '21

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

2 2

[issue22128] patch: steer people away from codecs.open
by Frank van Dijk 17 Apr '21

17 Apr '21

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

7 11

[issue42037] Documentation confusion in CookieJar functions
by Markus Israelsson 16 Apr '21

16 Apr '21

New submission from Markus Israelsson <markus.israelsson(a)surgicalscience.com>: The documentation in https://docs.python.org/3.8/library/http.cookiejar.html#http.cookiejar.Cook… claims the following for functions add_cookie_header and extract_cookies. *** The request object (usually a urllib.request.Request instance) must support the methods get_full_url(), get_host(), get_type(), unverifiable(), has_header(), get_header(), header_items(), add_unredirected_header() and origin_req_host attribute as documented by urllib.request. *** When reading the documentation for Request Objects https://docs.python.org/3.8/library/urllib.request.html?highlight=requests#… there is this: *** Changed in version 3.4: The request methods add_data, has_data, get_data, get_type, get_host, get_selector, get_origin_req_host and is_unverifiable that were deprecated since 3.3 have been removed. *** So basically the documentation claims that if the request object does not support functions that are removed then the headers will not be added. The code itself seem to do the correct thing however and add the header. ---------- assignee: docs@python components: Documentation messages: 378624 nosy: docs@python, markus priority: normal severity: normal status: open title: Documentation confusion in CookieJar functions type: enhancement versions: Python 3.8 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue42037> _______________________________________

4 10

[issue40006] enum: Add documentation for _create_pseudo_member_ and composite members
by Ram Rachum 15 Apr '21

15 Apr '21

New submission from Ram Rachum <ram(a)rachum.com>: Looking at the enum source code, there's a method `_create_pseudo_member_` that's used in a bunch of places. Its docstring says "Create a composite member iff value contains only members", which would have been useful if I had any idea what "composite member" meant. It would be good if the documentation for the enum module would include more information about these two concepts. ---------- assignee: docs@python components: Documentation messages: 364561 nosy: cool-RR, docs@python priority: normal severity: normal status: open title: enum: Add documentation for _create_pseudo_member_ and composite members type: enhancement versions: Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue40006> _______________________________________

3 4

[issue37741] importlib.metadata docs not showing up in the module index
by Brett Cannon 15 Apr '21

15 Apr '21

New submission from Brett Cannon <brett(a)python.org>: If you look at https://docs.python.org/3.9/py-modindex.html#cap-i you will see that importlib.metadata isn't listed (same goes for the 3.8 docs). Or are you leaving it out due to it being provisional? ---------- assignee: docs@python components: Documentation messages: 348872 nosy: barry, brett.cannon, docs@python, jaraco priority: normal severity: normal status: open title: importlib.metadata docs not showing up in the module index versions: Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue37741> _______________________________________

7 19