Mailman 3 December 2019 - docs

[issue39059] Getting incorrect results in rounding procedures
by AVicennA Dec. 17, 2019

Dec. 17, 2019

New submission from AVicennA <tural.jalilov.92(a)gmail.com>: This is about rounding process and getting incorrect results. In documentation written that, "This is not a bug: it’s a result of the fact that most decimal fractions can’t be represented exactly as a float". - https://docs.python.org/3/library/functions.html?highlight=round#round It is also related with hardware. I wrote some code parts that shows it and used decimal value as in documentation sample: ''' 2.675(4) - (4) or (3)… [View More] or (2) etc. I have given range 2, and the result is influenced not just by one number after those 2 ranges, but also the another number consistently. ''' >>> round(2.675, 2) 2.67 >>> >>> round(5.765, 2) 5.76 >>> >>> round(2.6754, 2) 2.68 >>> >>> round(5.7652, 2) 5.77 ''' "format" is also not working properly. Gives incorrect results. ''' >>> format(2.675, ".2f") '2.67' >>> >>> format(2.678, ".2f") '2.68' >>> >>> '{:0.2f}'.format(2.675) '2.67' >>> >>> '{:0.2f}'.format(2.678) '2.68' ''' Because, when the decimal string is converted to a binary floating-point number, it's again replaced with a binary approximation: Whose exact value is 5.765 --> 5.76499999999999968025576890795491635799407958984375 && 2.675 --> 2.67499999999999982236431605997495353221893310546875 It means that, the 76(5) --> 5 replaced in a memory as 4.(999999999999) && 67(5) --> 5 replaced in a memory as 4.(999999999999) ''' >>> from decimal import Decimal >>> Decimal(2.675) Decimal('2.67499999999999982236431605997495353221893310546875') >>> >>> Decimal(5.765) Decimal('5.76499999999999968025576890795491635799407958984375') ''' Used float point precision(FPU) with math lib to apply a certain correct form. I propose to use some tricks. But again incorrect result in third sample: ''' >>> import math >>> math.ceil(2.675 * 100) / 100 2.68 >>> >>> print("%.2f" % (math.ceil(2.675 * 100) / 100)) 2.68 >>> math.ceil(2.673 * 100) / 100 2.68 ''' The most correct form is using by round: ''' >>> round(2.675 * 100) / 100 2.68 >>> >>> round(2.673 * 100) / 100 2.67 >>> round(2.674 * 100) / 100 2.67 >>> round(2.676 * 100) / 100 2.68 ''' In this case, whatever the range the full right result is a return. Mostly can be using in fraction side correctness. ''' >>> def my_round(val, n): ... return round(val * 10 ** n) / 10 ** n ... >>> my_round(2.675, 2) 2.68 >>> >>> my_round(2.676, 2) 2.68 >>> >>> my_round(2.674, 2) 2.67 >>> >>> my_round(2.673, 2) 2.67 >>> >>> my_round(2.674, 3) 2.674 >>> >>> my_round(55.37678, 3) 55.377 >>> >>> my_round(55.37678, 2) 55.38 >>> >>> my_round(55.37478, 2) 55.37 >>> >>> my_round(224.562563, 2) 224.56 >>> >>> my_round(224.562563, 3) 224.563 >>> >>> my_round(224.562563, 4) 224.5626 >>> >>> my_round(224.562563, 5) 224.56256 >>> >>> my_round(224.562563, 7) 224.562563 >>> >>> my_round(224.562563, 11) 224.562563 ''' my_round - function tested on Windows and Linux platforms(x64). This can be added in Python next releases to solve this problem which related with the IEEE 754 and PEP 754 problems. ''' ---------- assignee: docs@python components: Documentation, FreeBSD, IDLE, Interpreter Core, Library (Lib), Tests, Windows, macOS messages: 358467 nosy: AVicennA, docs@python, koobs, ned.deily, paul.moore, ronaldoussoren, steve.dower, terry.reedy, tim.golden, zach.ware priority: normal severity: normal status: open title: Getting incorrect results in rounding procedures type: behavior versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue39059> _______________________________________ [View Less]

6 11

[issue39067] EOFError in tarfile.open
by jvoisin Dec. 17, 2019

Dec. 17, 2019

jvoisin <jvoisin(a)google.com> added the comment: Does it means that the right™ way to process untrusted tar files is to wrap every call to functions from tarfile.py in a `try: … except Exception:` block? ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue39067> _______________________________________

1 0

[issue39067] EOFError in tarfile.open
by Ronald Oussoren Dec. 16, 2019

Dec. 16, 2019

Ronald Oussoren <ronaldoussoren(a)mac.com> added the comment: The stdlib documentation does in general not contain exhaustive documentation on exceptions that might be raised. ---------- assignee: -> docs@python components: +Documentation nosy: +docs@python _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue39067> _______________________________________

1 0

Minor documentation bug for weakref
by Daniel Dunn Dec. 16, 2019

Dec. 16, 2019

Thank you all for the wonderful work you do! I notice that WeakMethod seems to take a callback(Just likeweakref.ref does) when I test it in practice, but the docs only show one parameter. I don't know if this is intentional, but I thought you may want to know. Thanks guys!

1 0

[issue39037] Fix the trial order of the __exit__ and __enter__ methods in the with statement documentation
by Géry Dec. 15, 2019

Dec. 15, 2019

Géry <gery.ogam(a)gmail.com> added the comment: Thanks @ncoghlan, it perfectly answered my question on Stack Overflow: https://stackoverflow.com/questions/59322585/what-is-the-exact-try-statemen… ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue39037> _______________________________________

1 0

[issue34000] Document when compile returns a code object v. AST
by Geoffrey Sneddon Dec. 15, 2019

Dec. 15, 2019

New submission from Geoffrey Sneddon <geoffers+pythonbugs(a)gmail.com>: The compile built-in documentation says: > Compile the source into a code or AST object. It doesn't however go on to say when it returns each! It does however note: > If you want to parse Python code into its AST representation, see ast.parse(). So compile can compile the source into an AST object, but if I want to parse Python code into an AST I should use ast.parse? As far as I can tell, this goes back … [View More]

3 2

[issue39037] Fix the trial order of the __exit__ and __enter__ methods in the with statement documentation
by Nick Coghlan Dec. 15, 2019

Dec. 15, 2019

Nick Coghlan <ncoghlan(a)gmail.com> added the comment: It's a matter of historical timing: PEP 343 was written before try/except/finally was allowed, when try/finally and try/except were still distinct statements. However, PEP 341 was *also* accepted and implemented for Python 2.5, allowing for the modern try/except/finally form: https://docs.python.org/dev/whatsnew/2.5.html#pep-341-unified-try-except-fi… ---------- _______________________________________ Python tracker <report(a)… [View More]

1 0

[issue39037] Fix the trial order of the __exit__ and __enter__ methods in the with statement documentation
by Géry Dec. 15, 2019

Dec. 15, 2019

Géry <gery.ogam(a)gmail.com> added the comment: @gvanrossum By the way, is there any particular reason why the ``try`` statement implementation equivalent to the ``with`` statement given in PEP 343 puts the finally clause in an outer ``try`` statement instead of in the inner ``try`` statement? (cf. https://www.python.org/dev/peps/pep-0343/#specification-the-with-statement) In other words, couldn't we simplify this: ``` mgr = (EXPR) exit = type(mgr).__exit__ # Not calling it yet value … [View More]

1 0

[issue39037] Fix the trial order of the __exit__ and __enter__ methods in the with statement documentation
by Géry Dec. 14, 2019

Dec. 14, 2019

Change by Géry <gery.ogam(a)gmail.com>: ---------- title: Wrong trial order of __exit__ and __enter__ in the with statement -> Fix the trial order of the __exit__ and __enter__ methods in the with statement documentation _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue39037> _______________________________________

1 0

[issue39037] Wrong trial order of __exit__ and __enter__ in the with statement
by Géry Dec. 14, 2019

Dec. 14, 2019

Géry <gery.ogam(a)gmail.com> added the comment: Done @brett.cannon, would you like to review it? https://github.com/python/cpython/pull/17608 ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue39037> _______________________________________

1 0