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