Mailman 3 August 2017 - docs

[issue31283] Inconsistent behaviours with explicit and implicit inheritance from object
by Steven D'Aprano Aug. 26, 2017

Aug. 26, 2017

Steven D'Aprano added the comment: > the documentation states that the two examples I gave should yield identical results. Got a link to the specific documentation that says this? And a suggested improvement? ---------- assignee: -> docs@python components: +Documentation nosy: +docs@python _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue31283> _______________________________________

1 0

[issue31276] PyObject_CallFinalizerFromDealloc is undocumented
by Pauli Virtanen Aug. 25, 2017

Aug. 25, 2017

New submission from Pauli Virtanen: It's unclear if PyObject_CallFinalizerFromDealloc is a public function or not. It is not documented, but it seems there's no other way to ensure that tp_finalize runs, at least for objects without Py_TPFLAGS_HAVE_GC. In the documentation of tp_finalize (https://docs.python.org/3/c-api/typeobj.html?highlight=tp_finalize#c.PyType…) there is the sentence: """It is called either from the garbage collector (if the instance is part of an isolated reference cycle) or just before the object is deallocated.""" However, it appears it is necessary to call it explicitly from any user-provided tp_dealloc. Indeed, there are several calls to PyObject_CallFinalizerFromDealloc in cpython/Modules/* e.g. in posixmodule.c:ScandirIterator_dealloc ---------- assignee: docs@python components: Documentation messages: 300842 nosy: docs@python, pv priority: normal severity: normal status: open title: PyObject_CallFinalizerFromDealloc is undocumented versions: Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue31276> _______________________________________

1 0

[issue31274] Support building against homebrew on macOS
by Barry A. Warsaw Aug. 25, 2017

Aug. 25, 2017

New submission from Barry A. Warsaw: The devguide does touch on how to build Python from source using homebrew installed libraries on macOS, although I found it to be 1) a bit incomplete; 2) not so easy to discover. It might make sense to modify configure to autodetect homebrew, or to have a switch to enable linking against homebrew libraries. Barring that, I'd like to at least update the devguide to include details on how to also build sqlite3 and zlib modules. ---------- assignee: docs@python components: Build, Documentation messages: 300819 nosy: barry, docs@python priority: normal severity: normal status: open title: Support building against homebrew on macOS versions: Python 3.6, Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue31274> _______________________________________

2 1

[issue12067] Doc: remove errors about mixed-type comparisons.
by Terry J. Reedy Aug. 24, 2017

Aug. 24, 2017

New submission from Terry J. Reedy <tjreedy(a)udel.edu>: Current 3.2 doc, 5.9. Comparisons, has this paragraph about mixed-type comparisons. "The operators <, >, ==, >=, <=, and != compare the values of two objects. The objects need not have the same type. If both are numbers, they are converted to a common type. Otherwise, the == and != operators *always* consider objects of different types to be unequal, while the <, >, >= and <= operators raise a TypeError when comparing objects of different types that do not implement these operators for the given pair of types. You can control comparison behavior of objects of non-built-in types by defining rich comparison methods like __gt__(), described in section Basic customization." Sentence 3: "If both are numbers, they are converted to a common type." I suspect it would be more true to say 'common internal type' as I would not think it a language requirement to produce Python objects. In any case, I think it is only true for built-in number types, and I do not see that qualification anywhere previously. That aside, it does not appear to be true for Decimals and Fractions in 2.7.1. Sentence 4: first clause is only true for built-in types. That qualification is not obvious to everyone, as evidenced by a current python-list sub thread. For 2.7, which has a different continuation, I suggest adding 'built-in' before 'objects of'. For 3.2/3, I suggest deleting '*always*' and adding a comma after 'TypeError' so that the 'when' condition applies to equality comparisons also. After discussion about same-type comparisons, there is another paragraph about mixed-type comparison: "Comparison of objects of the differing types depends on whether either of the types provide explicit support for the comparison. Most numeric types can be compared with one another, but comparisons of float and Decimal are not supported to avoid the inevitable confusion arising from representation issues such as float('1.1') being inexactly represented and therefore not exactly equal to Decimal('1.1') which is. When cross-type comparison is not supported, the comparison method returns NotImplemented. This can create the illusion of non-transitivity between supported cross-type comparisons and unsupported comparisons. For example, Decimal(2) == 2 and 2 == float(2) but Decimal(2) != float(2)." I suggest deleting this entirely. The first sentence and first clause of the second repeat what was said above. The rest is obsolete as float/decimal comparisons *are* implemented in 2.7.1 and 3.2.0. ---------- assignee: docs@python components: Documentation keywords: easy messages: 135873 nosy: docs@python, rhettinger, terry.reedy priority: normal severity: normal stage: needs patch status: open title: Doc: remove errors about mixed-type comparisons. versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12067> _______________________________________

15 71

[issue26256] Fast decimalisation and conversion to other bases
by Stefan Krah Aug. 24, 2017

Aug. 24, 2017

Stefan Krah added the comment: What needs to be mentioned though is that the context has to be set for unrounded calculations: c = getcontext() c.prec = MAX_PREC c.Emax = MAX_EMAX c.Emin = MIN_EMIN Otherwise some people believe that the bignums are just rounded floating point arithmetic that is expected to be fast (I've seen this misconception somewhere, perhaps on Stackoverflow). ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue26256> _______________________________________

1 0

[issue26256] Fast decimalisation and conversion to other bases
by Stefan Krah Aug. 24, 2017

Aug. 24, 2017

Stefan Krah added the comment: pypy-5.8.0-beta0 (Python 3.5.3) is using a very nicely written CFFI wrapper for libmpdec, so it also has the fast bignums. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue26256> _______________________________________

1 0

[issue26256] Fast decimalisation and conversion to other bases
by Raymond Hettinger Aug. 24, 2017

Aug. 24, 2017

Raymond Hettinger added the comment: A couple of thoughts: * It is okay to add a couple lines to the decimal module docs noting a Cpython specific implementation detail that it uses better than expected algorithms which can payoff nicely when used with very large numbers. * Mersenne prime examples and whatnot belong external to our docs. I usually put my recipes and examples on the ASPN Python Cookbook. http://code.activestate.com/recipes/langs/python/ ---------- nosy: +rhettinger _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue26256> _______________________________________

1 0

[issue26256] Fast decimalisation and conversion to other bases
by Cheryl Sabella Aug. 23, 2017

Aug. 23, 2017

Cheryl Sabella added the comment: Hello, I came across this issue and was wondering if the FAQ section of the doc might be a good place to mention the presence of FFT, or actually fast number theoretic transform, as Stefan pointed out. I was also wondering if the short code snippet for the Mersenne prime might be included in the recipes as an example of what decimal is capable of? ---------- nosy: +csabella _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue26256> _______________________________________

1 0

Download links for 3.4 are broken
by Silvia Aug. 23, 2017

Aug. 23, 2017

The links in https://docs.python.org/3.4/download.html don't work, because they point to https://docs.python.org/ftp/python/doc/3.4.7rc1/python-3.4.7rc1-docs-... They should probably link to the files in https://www.python.org/ftp/python/doc/3.4.7/ : https://docs.python.org/ftp/python/doc/3.4.7/python-3.4.7-docs-... (without rc1)

1 0

[issue31024] typing.Tuple is class but is defined as data inside https://docs.python.org/3.6/objects.inv
by Ivan Levkivskyi Aug. 23, 2017

Aug. 23, 2017

Ivan Levkivskyi added the comment: TBH, I think this is a Sphinx problem, not a Python problem. And concerning ``Tuple`` being an actual class I think this is an implementation detail, so that I am closing this as "won't fix". ---------- resolution: -> wont fix stage: -> resolved status: open -> closed _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue31024> _______________________________________

1 0