[issue32343] Leak Sanitizer reports memory leaks while building using ASAN

[https403]

https403  added the comment:

I got similar errors while playing around configure opts, but seems come from 
different places.

Configure opts: --enable-optimizations --with-address-sanitizer 
--with-undefined-behavior-sanitizer --with-pymalloc

Build environment: DigitalOcean $5 w/ Ubuntu 18.04 LTS

=
==26611==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 80 byte(s) in 1 object(s) allocated from:
#0 0x4f5ac0 in malloc 
(/tmp/python-build.20191217041116.18861/Python-3.7.5/python+0x4f5ac0)
#1 0xaf2362 in _PyObject_GC_Alloc 
/tmp/python-build.20191217041116.18861/Python-3.7.5/Modules/gcmodule.c:1696:26
#2 0xaf285a in _PyObject_GC_Malloc 
/tmp/python-build.20191217041116.18861/Python-3.7.5/Modules/gcmodule.c:1718:12
#3 0xaf285a in _PyObject_GC_New 
/tmp/python-build.20191217041116.18861/Python-3.7.5/Modules/gcmodule.c:1730
#4 0x64b03f in new_dict 
/tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/dictobject.c:584:14
#5 0xa7964a in ste_new 
/tmp/python-build.20191217041116.18861/Python-3.7.5/Python/symtable.c:85:24
#6 0xa7964a in symtable_enter_block 
/tmp/python-build.20191217041116.18861/Python-3.7.5/Python/symtable.c:943
#7 0xa7fd35 in symtable_visit_stmt 
/tmp/python-build.20191217041116.18861/Python-3.7.5/Python/symtable.c:1131:14
#8 0xa7f90b in symtable_visit_stmt 
/tmp/python-build.20191217041116.18861/Python-3.7.5/Python/symtable.c:1153:9
#9 0xa77bac in PySymtable_BuildObject 
/tmp/python-build.20191217041116.18861/Python-3.7.5/Python/symtable.c:293:18
#10 0x95fbc5 in PyAST_CompileObject 
/tmp/python-build.20191217041116.18861/Python-3.7.5/Python/compile.c:342:14
#11 0xa6ca51 in Py_CompileStringObject 
/tmp/python-build.20191217041116.18861/Python-3.7.5/Python/pythonrun.c:1102:10
#12 0x8f9d61 in builtin_compile_impl 
/tmp/python-build.20191217041116.18861/Python-3.7.5/Python/bltinmodule.c:878:14 
   #13 0x8f9d61 in builtin_compile 
/tmp/python-build.20191217041116.18861/Python-3.7.5/Python/clinic/bltinmodule.c.h:177
#14 0x58c722 in _PyMethodDef_RawFastCallDict 
/tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/call.c:544:18
#15 0x58784c in _PyCFunction_FastCallDict 
/tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/call.c:586:14
#16 0x9193df in do_call_core 
/tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:4641:9
#17 0x9193df in _PyEval_EvalFrameDefault 
/tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:3191
#18 0x953711 in _PyEval_EvalCodeWithName 
/tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:3930:14
#19 0x588f5e in _PyFunction_FastCallKeywords 
/tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/call.c:433:12
#20 0x94e195 in call_function 
/tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:4616:17
#21 0x91670e in _PyEval_EvalFrameDefault 
/tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:3139:19
#22 0x953711 in _PyEval_EvalCodeWithName 
/tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:3930:14
#23 0x588f5e in _PyFunction_FastCallKeywords 
/tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/call.c:433:12
#24 0x94e195 in call_function 
/tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:4616:17
#25 0x91e6eb in _PyEval_EvalFrameDefault 
/tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:3110:23
#26 0x58b839 in function_code_fastcall 
/tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/call.c:283:14
#27 0x94e195 in call_function 
/tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:4616:17
#28 0x91e6eb in _PyEval_EvalFrameDefault 
/tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:3110:23
#29 0x58b839 in function_code_fastcall 
/tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/call.c:283:14
#30 0x94e195 in call_function 
/tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:4616:17
#31 0x91e6eb in _PyEval_EvalFrameDefault 
/tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:3110:23
#32 0x58b839 in function_code_fastcall 
/tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/call.c:283:14
#33 0x94e195 in call_function 
/tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:4616:17

Direct leak of 64 byte(s) in 1 object(s) allocated from:
#0 0x4f5ac0 in malloc 
(/tmp/python-build.20191217041116.18861/Python-3.7.5/python+0x4f5ac0)
#1 0xaf2362 in _PyObject_GC_Alloc 
/tmp/python-build.20191217041116.18861/Python-3.7.5/Modules/gcmodule.c:1696:26
#2 0xaf2a4b in _PyObject_GC_Malloc 
/tmp/python-build.20191217041116.18861/Python-3.7.5/Modules/gcmodule.c:1718:12
#3 0xaf2a4b in _PyObject_GC_NewVar 
/tmp/python-build.20191217041116.18861/Python-3.7.5/Modules/gcmodule.c:1747
#4 0x70ff55 in PyTuple_New 
/tmp/python-bu

[issue37228] UDP sockets created by create_datagram_endpoint() allow by default multiple processes to bind the same port

[Kyle Stanley]

Kyle Stanley  added the comment:

Thanks for taking care of merging the remaining backport PRs for 3.6-3.8, Ned. 
Now, the only branch left is (potentially) 3.5.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39040] Wrong attachement filename when mail mime header was too long

[Abhilash Raj]

Abhilash Raj  added the comment:

Thanks David! I applied the fixes as per  your comments, can you please take 
another look?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31046] ensurepip does not honour the value of $(prefix)

[Zackery Spytz]

Change by Zackery Spytz :


--
nosy: +ZackerySpytz
versions: +Python 3.9 -Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39066] Expose SOABI setting in the header

[Ben Boeckel]

Ben Boeckel  added the comment:

Ah, that does look like it is suitable (since it is a shell script). I assume 
it is a batch script on Windows (though I feel cross-compilation is far rarer 
there). Thanks.

--
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31046] ensurepip does not honour the value of $(prefix)

[Zackery Spytz]

Change by Zackery Spytz :


--
pull_requests: +17103
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17634

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39059] Getting incorrect results in rounding procedures

[Kubilay Kocak]

Change by Kubilay Kocak :


--
nosy:  -koobs

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38730] 2.7 modern compiler warnings

[Benjamin Peterson]

Benjamin Peterson  added the comment:


New changeset 052f47ef5cc363e842e0e839980cfa55ada123b5 by Benjamin Peterson in 
branch '2.7':
bpo-38730: Replace strncpy in import.c with memcpy. (GH-17633)
https://github.com/python/cpython/commit/052f47ef5cc363e842e0e839980cfa55ada123b5


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39066] Expose SOABI setting in the header

[Ned Deily]

Ned Deily  added the comment:

The entire extension suffix is currently available from the pythonX.Y-config 
command which does not depend on a running interpreter (on Linux systems at 
least), for example:

$ python3.8-config --extension-suffix
.cpython-38-i386-linux-gnu.so

Is that not sufficient for your needs?

--
nosy: +ned.deily

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38730] 2.7 modern compiler warnings

[Benjamin Peterson]

Change by Benjamin Peterson :


--
pull_requests: +17102
pull_request: https://github.com/python/cpython/pull/17633

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39070] Uninstalling 3.8.0 fails but it says it succeeds..

[tuijatuulia]

New submission from tuijatuulia :

I installed 3.8.0 on Windows 10 without problems. Using windows user that has 
no admin rights - and system was asking for admin info.
Then I wanted to uninstall it because I got a wrong version and 32 bit version 
when I wanted 64 bit, but uninstalling did nothing, although it said it was 
successful and asked for admin login and ended into successful -screen - 
although it was too quick so I figured it did nothing actually, and it did not 
remove anything.
Only when I gave this same windows user the admin rights to the computer, I 
could uninstall 3.8.0.

--
components: Windows
messages: 358526
nosy: paul.moore, steve.dower, tim.golden, tuijatuulia, zach.ware
priority: normal
severity: normal
status: open
title: Uninstalling 3.8.0 fails but it says it succeeds..
type: behavior
versions: Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39035] Travis CI fail on backports: pyvenv not installed

[Ned Deily]

Ned Deily  added the comment:


New changeset 7699281b72b862797a89fcad004da8f58e93c800 by Ned Deily (Inada 
Naoki) in branch '3.6':
bpo-39035: travis: Update image to xenial (GH-17622)
https://github.com/python/cpython/commit/7699281b72b862797a89fcad004da8f58e93c800


--
nosy: +ned.deily

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37228] UDP sockets created by create_datagram_endpoint() allow by default multiple processes to bind the same port

[Kyle Stanley]

Change by Kyle Stanley :


--
pull_requests: +17101
pull_request: https://github.com/python/cpython/pull/17632

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37228] UDP sockets created by create_datagram_endpoint() allow by default multiple processes to bind the same port

[Kyle Stanley]

Change by Kyle Stanley :


--
pull_requests: +17099
pull_request: https://github.com/python/cpython/pull/17630

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37228] UDP sockets created by create_datagram_endpoint() allow by default multiple processes to bind the same port

[Kyle Stanley]

Change by Kyle Stanley :


--
pull_requests: +17100
pull_request: https://github.com/python/cpython/pull/17631

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37762] IDLE very slow due a super long line output in chunks

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Python374-4.png shows that Tensorflow prints proper lines, ending with newline, 
when printing to the Windows console.  The 30 character progress bar is 
repeated on each new line.  It does not appear to be using either \r or \b.  I 
consider it a bug in tensorflow that it omits newlines when printing to IDLE, 
and that it apparently add \bs instead.

https://stackoverflow.com/questions/59309917/tensorflow-printing-weird-symbols-as
 is about the same issue.  The questioner ran 
 for c in '': print(hex(ord(c)))
where  is the copy and pasted segment printing as the reverse bullets 
and they are indeed backspaces.  In his output, there are 39 backspaces, which 
is not at all enough to overprint the entire line.  This makes no sense to me.

--
resolution:  -> third party
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39069] Move ast.unparse() function to a different module

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

Closing this now that we have consensus. :)

Thanks, everyone for your input!

--
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39069] Move ast.unparse() function to a different module

[Batuhan]

Batuhan  added the comment:

Thanks for having consensus on this. I'll refactor PR 17612 and open
anothor one for reverting PR 17376

On Tue, Dec 17, 2019, 12:31 AM STINNER Victor 
wrote:

>
> STINNER Victor  added the comment:
>
> Pablo:
> > Victor, are you OK if we close this issue and just use the desired
> imports directly in the PRs for issue 38870?
>
> Yes.
>
> --
>
> *I* don't care of "import ast" performance, since I don't expect it to be
> commonly used by command line applications. I don't know the story of the
> revert, but it seems like you don't bother much anymore.
>
> If tomorrow using "functools" and "enum" becomes a performance bottleneck
> (for import time), maybe we should try to optimize imports and optimize
> these modules instead?
>
> I opened this issue because I would like to use these modules in ast. I'm
> unhappy with the current proposed implementation:
> ---
>
> class _NoDelimit:
> def __enter__(self): pass
> def __exit__(self, *args): pass
>
> class _Delimit:
> """A context manager for preparing the source for expressions. It
> adds
> start of the delimiter  and enters, after exit it adds delimiter
> end."""
> def __init__(self, unparser, delimiter):
> self.unparser = unparser
> self.delimiter = delimiter
> def __enter__(self):
> self.unparser.write(self.delimiter[0])
> def __exit__(self, exc_type, exc_value, traceback):
> self.unparser.write(self.delimiter[-1])
>
> def delimit_if(self, condition, delimiter):
> if condition:
> return self._Delimit(self, delimiter)
> else:
> return self._NoDelimit()
> ---
>
> Having to define two classes just to call the write() method seems
> overkill to me.
>
> Same remark for the pseudo enum in PR 17377:
> ---
> PRECEDENCE_LEVELS = {
> "PR_TUPLE": 0,
> "PR_YIELD": 1,
> "PR_TEST": 2,
> "PR_OR": 3,
> "PR_AND": 4,
> "PR_NOT": 5,
> "PR_CMP": 6,
> "PR_EXPR": 7,
> "PR_BOR": 7,
> "PR_BXOR": 8,
> "PR_BAND": 9,
> "PR_SHIFT": 10,
> "PR_ARITH": 11,
> "PR_TERM": 12,
> "PR_FACTOR": 13,
> "PR_POWER": 14,
> "PR_AWAIT": 15,
> "PR_ATOM": 16,
> }
> ---
>
> It's too easy to introduce a duplicated constant with such construction.
> The enum module is designed to define unique constants.
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39069] Move ast.unparse() function to a different module

[STINNER Victor]

STINNER Victor  added the comment:

Pablo:
> Victor, are you OK if we close this issue and just use the desired imports 
> directly in the PRs for issue 38870?

Yes.

--

*I* don't care of "import ast" performance, since I don't expect it to be 
commonly used by command line applications. I don't know the story of the 
revert, but it seems like you don't bother much anymore.

If tomorrow using "functools" and "enum" becomes a performance bottleneck (for 
import time), maybe we should try to optimize imports and optimize these 
modules instead?

I opened this issue because I would like to use these modules in ast. I'm 
unhappy with the current proposed implementation:
---

class _NoDelimit:
def __enter__(self): pass
def __exit__(self, *args): pass

class _Delimit:
"""A context manager for preparing the source for expressions. It adds
start of the delimiter  and enters, after exit it adds delimiter end."""
def __init__(self, unparser, delimiter):
self.unparser = unparser
self.delimiter = delimiter
def __enter__(self):
self.unparser.write(self.delimiter[0])
def __exit__(self, exc_type, exc_value, traceback):
self.unparser.write(self.delimiter[-1])

def delimit_if(self, condition, delimiter):
if condition:
return self._Delimit(self, delimiter)
else:
return self._NoDelimit()
---

Having to define two classes just to call the write() method seems overkill to 
me.

Same remark for the pseudo enum in PR 17377:
---
PRECEDENCE_LEVELS = {
"PR_TUPLE": 0,
"PR_YIELD": 1,
"PR_TEST": 2,
"PR_OR": 3,
"PR_AND": 4,
"PR_NOT": 5,
"PR_CMP": 6,
"PR_EXPR": 7,
"PR_BOR": 7,
"PR_BXOR": 8,
"PR_BAND": 9,
"PR_SHIFT": 10,
"PR_ARITH": 11,
"PR_TERM": 12,
"PR_FACTOR": 13,
"PR_POWER": 14,
"PR_AWAIT": 15,
"PR_ATOM": 16,
}
---

It's too easy to introduce a duplicated constant with such construction. The 
enum module is designed to define unique constants.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39069] Move ast.unparse() function to a different module

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

Victor, are you OK if we close this issue and just use the desired imports 
directly in the PRs for issue 38870?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39069] Move ast.unparse() function to a different module

[Guido van Rossum]

Guido van Rossum  added the comment:

If anything, ast.literal_eval() should be moved.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39069] Move ast.unparse() function to a different module

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

If I remember correctly, the people that were concerned mentioned the usage of 
'ast.literal_eval' in some simple command line applications were the import may 
be noticeable but I will be totally ok to just accept the slower import of ast.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39069] Move ast.unparse() function to a different module

[Guido van Rossum]

Guido van Rossum  added the comment:

Why is the import speed of ast important enough to uglify this code? Who is 
using ast.py that isn't also importing lots of other stuff? For example, black 
imports lots of other stuff (multiprocessing, asyncio, pathlib, typing, ..., 
even 3rd party attr, click and toml).

--
nosy: +gvanrossum

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39059] Getting incorrect results in rounding procedures

[Mark Dickinson]

Mark Dickinson  added the comment:

@AVicennA: 4.39 *is* the correctly-rounded result for `round(4.395, 2)`. Modulo 
(as-yet unreported) bugs, `round` does correct-rounding (in the IEEE 754 sense) 
in all cases. I was pointing out that your `my_round` does not solve the 
problem you think it does: presumably you'd consider the "correct" result for 
`round(4.395, 2)` to be `4.4`, so you'd like `my_round(4.395, 2)` to return 
`4.4`?

> Do you have any suggestion to solve this problem?

The "problem" presumably being that two-argument `round` gives surprising 
results, to those who haven't thought about the implications of binary 
floating-point?

Unfortunately, there's no easy solution here. Discouraging use of two-argument 
round, and perhaps eventually deprecating it, is one possibility; there are few 
really good use-cases for two-argument round - most of the common use-cases 
involve rounding for reporting purposes, and that's better handled by string 
formatting. Keeping two-argument round and documenting the issue is another, 
and that's the solution the Python core devs have chosen. A more drastic 
solution would be to have Python's numeric literals use decimal floating-point 
by default instead of binary floating-point, so that we finally have a What You 
See Is What You Get behaviour for floating-point. That would be a huge change 
with many implications, and it's definitely way out of scope for this issue.

If you want to discuss this further, please feel free to do so, but not here: 
this isn't the right forum for that discussion.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39041] Support GitHub Actions in CI

[Steve Dower]

Steve Dower  added the comment:


New changeset 6a263cf1adfc18cdba65c788dd76d35997a89acf by Steve Dower in branch 
'master':
bpo-39041: Add GitHub Actions badge to README.rst (GH-17628)
https://github.com/python/cpython/commit/6a263cf1adfc18cdba65c788dd76d35997a89acf


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38993] cProfile behaviour issue with decorator and math.factorial() lib.

[AVicennA]

Change by AVicennA :


--
resolution: not a bug -> later

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39059] Getting incorrect results in rounding procedures

[Steve Dower]

Change by Steve Dower :


--
nosy:  -steve.dower

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39061] Garbage Collection makes some object live for very long

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
title: Garbage Collection optimizations cause "memory leak" -> Garbage 
Collection makes some object live for very long

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39059] Getting incorrect results in rounding procedures

[AVicennA]

AVicennA  added the comment:

@mark.dickinson,

1) Where is your "`round` is giving the correct result in all cases"??

>>> round(4.395, 2)
4.39

2) I wrote it in my post using decimal punct:
''' 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.76468025576890795491635799407958984375
 &&
 2.675 --> 
2.67482236431605997495353221893310546875

It means that, the 76(5) --> 5 replaced in a memory as 4.()
 &&
   67(5) --> 5 replaced in a memory as 4.() '''

3) round(2.6748, 2) --> this is the same with round(2.675, 2).

4) I also have a question for you.. Do you have any suggestion to solve this 
problem?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39069] Move ast.unparse() function to a different module

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

Opened https://github.com/python/cpython/pull/17629 in case we decide to go 
this route.

--
stage: patch review -> 

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39069] Move ast.unparse() function to a different module

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
keywords: +patch
pull_requests: +17098
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17629

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39041] Support GitHub Actions in CI

[Steve Dower]

Change by Steve Dower :


--
keywords: +patch
pull_requests: +17097
pull_request: https://github.com/python/cpython/pull/17628

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39069] Move ast.unparse() function to a different module

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

One thing to notice:

Factoring this into a submodule may be a bit annoying as it will have circular 
imports as the unparse submodule depends directly on stuff from ast and ast 
will import unparse. Is possible to make it work if we import it at the end but 
is a bit ugly.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39059] Getting incorrect results in rounding procedures

[Terry J. Reedy]

Terry J. Reedy  added the comment:

The flaw in my_round is that it rounds twice, not once.  The first rounding is 
caused by multiplying by a factor that is not a power of 2.  

In the case of 2.675, that rounding is up enough to affect the second rounding.
>>> format(2.675, ".17f")
'2.67482'
>>> format(2.675 *100, ".17f")
'267.5'

In the case of 4.395, the first rounding is down.
>>> format(4.395, ".17f")
'4.39457'
>>> format(4.395 *100, ".17f")
'439.44316'
Even if it had been up, it might not have been enough to affect the outcome, as 
57 is a lot farther from 100 than 82.

If you want to discuss floating point approximations and rounding further, 
please post to python-list, not here.

--
components:  -Documentation, FreeBSD, IDLE, Library (Lib), Tests, Windows, macOS
versions:  -Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39041] Support GitHub Actions in CI

[Steve Dower]

Steve Dower  added the comment:

Have merged the core support. Now that checks are enabled, any updates to the 
workflow files can be tested in PRs, so that will be much easier.

Other things to do:
* badges
* disable Azure Pipelines for PR builds
* ...? What have I missed?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39069] Move ast.unparse() function to a different module

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

Also, make sure that the module is not cached, for example:

./python -m pyperf timeit 'import sys; 
sys.modules.pop("ast",None);sys.modules.pop("enum",None)' 'import ast'

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38993] cProfile behaviour issue with decorator and math.factorial() lib.

[AVicennA]

Change by AVicennA :


Removed file: https://bugs.python.org/file48764/cProfiling.txt

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39041] Support GitHub Actions in CI

[Steve Dower]

Steve Dower  added the comment:


New changeset a76ba362c4d86adf5e7f8254398135d12d7afd25 by Steve Dower in branch 
'master':
bpo-39041: Add GitHub Actions support (GH-17594)
https://github.com/python/cpython/commit/a76ba362c4d86adf5e7f8254398135d12d7afd25


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39069] Move ast.unparse() function to a different module

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

That will likely be very dependent on the filesystem. For example, in one of my 
servers without SSDs:

Before: Mean +- std dev: 412 ns +- 11 ns
After: Mean +- std dev: 472 ns +- 11 ns

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39069] Move ast.unparse() function to a different module

[Batuhan]

Batuhan  added the comment:

$ ./python -m pyperf timeit "import ast"
Before: Mean +- std dev: 326 ns +- 13 ns
After: Mean +- std dev: 330 ns +- 19 ns

(applied my first patch with both contextlib and IntEnum)

Pablo Galindo Salgado , 16 Ara 2019 Pzt, 21:27
tarihinde şunu yazdı:

>
> Pablo Galindo Salgado  added the comment:
>
> Ok, I think I agree, will make a PR for that.
>
> --
> assignee:  -> pablogsal
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39069] Move ast.unparse() function to a different module

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

Ok, I think I agree, will make a PR for that.

--
assignee:  -> pablogsal

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39069] Move ast.unparse() function to a different module

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
nosy: +BTaskaya

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38870] Expose ast.unparse in the ast module

[STINNER Victor]

STINNER Victor  added the comment:

I created bpo-39069: "Move ast.unparse() function to a different module".

--
nosy: +vstinner

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38348] Make python -m ast more configurable

[STINNER Victor]

STINNER Victor  added the comment:

Thanks Batuhan Taşkaya.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38348] Make python -m ast more configurable

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 814d687c7df3e0c60036943b68ece13f9f19dfef by Victor Stinner 
(Batuhan Taşkaya) in branch 'master':
bpo-38348: Extend command line options of ast parsing tool (GH-16540)
https://github.com/python/cpython/commit/814d687c7df3e0c60036943b68ece13f9f19dfef


--
nosy: +vstinner

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39069] Move ast.unparse() function to a different module

[STINNER Victor]

STINNER Victor  added the comment:

> Lazy import

IMHO moving unparse code to a new _ast_unparse module, and use 
ast.__getattr__() to lazily import it and bind it as the ast.unparse() function 
is the best option, since __getattr__() alone is enough to implement the 
laziness and it should be simple, something like:

def __getattr__(name):
  if name == 'unparse':
import _ast_unparse
globals()['unpase'] = _ast_unparse.unparse
return _ast_unparse.unparse
  else:
raise AttributeError

I never used a module __getattr__().

So _ast_unparse could use any super slow but cool Python feature, without 
having to use dirty hacks to make the code lazy.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39040] Wrong attachement filename when mail mime header was too long

[R. David Murray]

R. David Murray  added the comment:

In general your solution looks good, just a few naming comments and an 
additional test request.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39069] Move ast.unparse() function to a different module

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

I will be ok with (no particular order):

- Avoid cool enum and functools modules, and use simpler
- Accept to make "import ast" slower
- Lazy import

I think is very important to keep 'ast.unparse' symmetric with 'ast.parse': is 
consistent, helps with discovery and they are very much related. Whatever 
option we choose we should try to maintain this IMO.

--
nosy:  -BTaskaya

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39069] Move ast.unparse() function to a different module

[STINNER Victor]

Change by STINNER Victor :


--
nosy: +BTaskaya

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39069] Move ast.unparse() function to a different module

[STINNER Victor]

STINNER Victor  added the comment:

Can someone try to run a benchmark to see the actual overhead of adding 
functools and/or enum imports, and creating a enum type on "import ast"?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39069] Move ast.unparse() function to a different module

[STINNER Victor]

STINNER Victor  added the comment:

> On the same PR, I also proposed to use import enum:

"import enum" is not the biggest enum. Creating an enum type is expensive, and 
so we might to do it lazily. For example, "import re" was made betweeen 20 an 
30% slower than re constants were converted to enums.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39069] Move ast.unparse() function to a different module

[STINNER Victor]

New submission from STINNER Victor :

Pablo Galingo Salgado recently moved Tools/parser/unparse.py to a ast.unparse() 
function.

Pablo made a change using functools. The additional "import functools" made 
"import ast" slower and so Pablo reverted his change:

* https://github.com/python/cpython/pull/17376
* https://bugs.python.org/issue38870

The question of using contextlib comes back in another ast.unparse change to 
get @contextlib.contextmanager:

* https://github.com/python/cpython/pull/17377#discussion_r350239415

On the same PR, I also proposed to use import enum:

* https://github.com/python/cpython/pull/17377#discussion_r357921289

There are different options to not impact "import ast" performance:

* Move ast.unparse() code into a new module
* Write to code so imports can be done lazily

"from ast import unparse" or "ast.unparse()" can be kept using a private 
_ast_unparse module and add a __getattr__() function to Lib/ast.py to lazily 
bind _ast_unparse.unparse() to ast.unparse().

Other options:

* Avoid cool enum and functools modules, and use simpler Python code (that 
makes me sad, but it's ok)
* Accept to make "import ast" slower
* Remove ast.unparse(): I don't think that anyone wants this, ast.unparse() was 
approved on python-dev.

--
components: Library (Lib)
messages: 358496
nosy: pablogsal, vstinner
priority: normal
severity: normal
status: open
title: Move ast.unparse() function to a different module
versions: Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39068] Base 85 encoding initialization race condition

[Brandon Stansbury]

Change by Brandon Stansbury :


--
title: Base 85 encoding initialization race conditiong -> Base 85 encoding 
initialization race condition

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39068] Base 85 encoding initialization race conditiong

[Brandon Stansbury]

New submission from Brandon Stansbury :

Under multi-threading scenarios a race condition may occur where a thread sees 
an initialized `_b85chars` table but an uninitialized `_b85chars2` table due to 
the guard only checking the first table.

This causes an exception like:

```
  File "/usr/lib/python3.6/base64.py", line 434, in b85encode
return _85encode(b, _b85chars, _b85chars2, pad),
  File "/usr/lib/python3.6/base64.py", line 294, in _85encode
for word in words],
  File "/usr/lib/python3.6/base64.py", line 294, in 
for word in words],
 "TypeError: 'NoneType' object is not subscriptable
```

--
components: Library (Lib)
messages: 358495
nosy: drmonkeysee
priority: normal
pull_requests: 17096
severity: normal
status: open
title: Base 85 encoding initialization race conditiong
type: crash
versions: Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39067] EOFError in tarfile.open

[Ronald Oussoren]

Ronald Oussoren  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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39067] EOFError in tarfile.open

[jvoisin]

jvoisin  added the comment:

Unfortunately, the documentation ( 
https://docs.python.org/3/library/tarfile.html) doesn't mention that EOFError 
is an exception that could be raised when using tarfile.open :/

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39067] EOFError in tarfile.open

[Ronald Oussoren]

Ronald Oussoren  added the comment:

Looks like expected behaviour, the attached file is an incomplete compressed 
file that does not seem to contain data (according to gzcat)

gzcat: crash-f4032ed3c7c2ae59a8f4424e0e73ce8b11ad3ef90155b008968f5b1b08499bc4: 
unexpected end of file
gzcat: crash-f4032ed3c7c2ae59a8f4424e0e73ce8b11ad3ef90155b008968f5b1b08499bc4: 
uncompress failed

--
nosy: +ronaldoussoren

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39061] Garbage Collection optimizations cause "memory leak"

[Maxime Istasse]

Maxime Istasse  added the comment:

> The fact that the GC will take longer time does not qualify this as memory 
> leaks. A memory leak is by definition memory that cannot be reclaimed and in 
> this case, once the collection of the old generation happens it will be 
> collected, therefore is not a "leak" per se.

I completely agree, I did not know what to call that. It's just that I was 
really believing to write GC-friendly code, but that my assumptions were very 
wrong. The result of my investigation seems so counter-intuitive that I tend to 
believe this is a bug introduced by a quick implementation shortcut and an 
optimization.

I wouldn't have reported it if I had been able to mitigate it by setting the gc 
parameters. My first idea was to set a threshold0 such that I'm certain I don't 
keep references for that amount of time. But the one I'm using at the moment of 
the second generation collection will go in the old generation, it is the only 
one but it will for sure. As those are the only "new" objects that go to the 
old generation, it really takes a long time for it to grow sufficiently to get 
collected.

> This has also other downsides, like objects that won't be collected will 
> suffer more traversals and collections, that can be impactful in performance, 
> so is not that simple.

I don't think it will be that impactful because of traversals and collections. 
I think it was mostly convenient to merge the generations in the "collect" 
function, and that not merging them will be a bit more tedious.

If there is a second gen collection every 10 young gen collection, then it just 
introduces some more objects in the next second gen collection every second gen 
collection rather than putting them in the old generation directly.

To me, it is unintended that all the objects that are reachable during a second 
gen collection are put in the old generation. There is a high probability we 
have some short-lived objects there. It wouldn't be as problematic to traverse 
them once more in the next second gen. I tend to believe it is the purpose of 
the old gen not to be reachable in less than 2 passes.

Hopefully, for my personal, non artificial case, there are other assumptions I 
can make so I used weakrefs. I have one parent with children pointing to it, 
they just point with weakrefs now, and I know I always keep a reference to the 
parent or are OK to let them all go as refcount(parent) == 0. I'm very grateful 
I don't have to do gc.collect, which indeed was the next option.

Thank you for taking the problem seriously, and for the time you may dedicate 
to it. No need to be quick, I just wanted to raise that question. I am of 
course interested in the bad consequences it could bring (at the core of such a 
broadly used language, I would expect there are some), but at the same time, it 
is such a rare event and very localized and counter-intuitive in the 
implementation that it would surprise me.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39067] EOFError in tarfile.open

[jvoisin]

New submission from jvoisin :

The attached file produces the following stacktrace when opened via 
`tarfile.open`, on Python 3.7.5rc1:


```
$ cat tarrepro.py 
import tarfile
import sys

with tarfile.open(sys.argv[1], errorlevel=2) as t:
  for member in t.getmembers():
pass
$
```

```
$ python3 tarrepro.py 
crash-f4032ed3c7c2ae59a8f4424e0e73ce8b11ad3ef90155b008968f5b1b08499bc4
Traceback (most recent call last):
  File "tarrepro.py", line 4, in 
with tarfile.open(sys.argv[1], errorlevel=2) as t:
  File "/usr/lib/python3.7/tarfile.py", line 1574, in open
return func(name, "r", fileobj, **kwargs)
  File "/usr/lib/python3.7/tarfile.py", line 1646, in gzopen
t = cls.taropen(name, mode, fileobj, **kwargs)
  File "/usr/lib/python3.7/tarfile.py", line 1622, in taropen
return cls(name, mode, fileobj, **kwargs)
  File "/usr/lib/python3.7/tarfile.py", line 1485, in __init__
self.firstmember = self.next()
  File "/usr/lib/python3.7/tarfile.py", line 2290, in next
tarinfo = self.tarinfo.fromtarfile(self)
  File "/usr/lib/python3.7/tarfile.py", line 1094, in fromtarfile
buf = tarfile.fileobj.read(BLOCKSIZE)
  File "/usr/lib/python3.7/gzip.py", line 276, in read
return self._buffer.read(size)
  File "/usr/lib/python3.7/_compression.py", line 68, in readinto
data = self.read(len(byte_view))
  File "/usr/lib/python3.7/gzip.py", line 463, in read
if not self._read_gzip_header():
  File "/usr/lib/python3.7/gzip.py", line 421, in _read_gzip_header
self._read_exact(extra_len)
  File "/usr/lib/python3.7/gzip.py", line 400, in _read_exact
raise EOFError("Compressed file ended before the "
EOFError: Compressed file ended before the end-of-stream marker was reached

```

--
components: Library (Lib)
files: crash-f4032ed3c7c2ae59a8f4424e0e73ce8b11ad3ef90155b008968f5b1b08499bc4
messages: 358490
nosy: jvoisin
priority: normal
severity: normal
status: open
title: EOFError in tarfile.open
type: behavior
versions: Python 3.7
Added file: 
https://bugs.python.org/file48784/crash-f4032ed3c7c2ae59a8f4424e0e73ce8b11ad3ef90155b008968f5b1b08499bc4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39066] Expose SOABI setting in the header

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +vstinner

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39066] Expose SOABI setting in the header

[Ben Boeckel]

New submission from Ben Boeckel :

Currently, the SOABI suffix is only available by running the Python interpreter 
to ask `sysconfig` about the setting. This complicates cross compilation 
because the target platform's Python may not be runnable on the build platform. 
Exposing this in the header would allow for build processes to know what suffix 
to add to modules without having to run the interpreter.

--
components: C API
messages: 358489
nosy: mathstuf
priority: normal
severity: normal
status: open
title: Expose SOABI setting in the header
type: enhancement

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39061] Garbage Collection optimizations cause "memory leak"

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

> It happens to cause huge memory leaks if the self-referencing objects 
> occupies a lot of RAM, which should be expected.

The fact that the GC will take longer time does not qualify this as memory 
leaks. A memory leak is by definition memory that cannot be reclaimed and in 
this case, once the collection of the old generation happens it will be 
collected, therefore is not a "leak" per se.

> I think the best and simplest solution would be to move the objects one 
> generation at a time. This would avoid the heavy but short-lived objects to 
> make it to the old generation.

This has also other downsides, like objects that won't be collected will suffer 
more traversals and collections, that can be impactful in performance, so is 
not that simple. 

I am currently working on an experiment to see if we can detect "nepotism" 
(check https://www.memorymanagement.org/glossary/n.html for a definition) and 
this will likely help with your problem.

In the meanwhile, I think the most portable option is forcing collections 
yourself or adjusting the gc parameters.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34028] Python 3.7.0 wont compile with SSL Support 1.1.0 > alledged missing X509_VERIFY_PARAM_set1_host() support

[joahking]

joahking  added the comment:

hello,
I ran over this same problem on Ubuntu 14.04

As per
https://github.com/pyenv/pyenv/wiki/Common-build-problems

"Python 3.7.0 will not compile on RHEL6 because it requires OpenSSL 1.0.2 or 
1.1 and RHEL6 provides 1.0.1e"

openssl version confirms this to be the case on Ubuntu 14.04

"On Ubuntu 14.04 on Dreamhost, an extra flag is required for Python 3.7+:
First, follow these instructions: 
https://help.dreamhost.com/hc/en-us/articles/360001435926-Installing-OpenSSL-locally-under-your-username";

then I ran: 
./configure --with-ensurepip=yes CFLAGS="-I$HOME/openssl/include" 
LDFLAGS="-L$HOME/openssl/lib"

after that python3.7 was correct

hope that helps, kind regards
Joaquin

--
nosy: +joahking

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39061] Garbage Collection optimizations cause "memory leak"

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +pablogsal

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39061] Garbage Collection optimizations cause "memory leak"

[Maxime Istasse]

Maxime Istasse  added the comment:

TLDR; a short-lived object can make it directly from young generation to old 
generation if middle generation collection kicks in while it is not freeable 
yet. Old generation is very rarely collected. Several of those objects, if they 
imply cyclic references, can therefore stack there and use a lot of RAM if big 
objects are attached to them. (if no cyclic refs, refcount goes to 0 and 
everything is OK)

This seems to happen in 3.8 as well, most likely in old versions as well. To 
me, those conditions shouldn't be exceptional enough to be ignored. 
I'm beginning to work on a fix, no guarantee yet though...

--
versions:  -Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39065] OSError in TarFile.getmembers()

[jvoisin]

New submission from jvoisin :

The attached file produces the following stacktrace when opened via 
`tarfile.open` and iterated with `TarFile.getmembers`, on Python 3.7.5rc1:

```
$ cat tarrepro.py 
import tarfile
import sys

with tarfile.open(sys.argv[1]) as t:
  for member in t.getmembers():
pass
```

```
$ python3 tarrepro.py 
crash-462a00f845e737bff6df2fe6467fc7cdd4c39cd8e27ef1d3011ec68a9808ca8e
Traceback (most recent call last):
  File "tarrepro.py", line 5, in 
for member in t.getmembers():
  File "/usr/lib/python3.7/tarfile.py", line 1763, in getmembers
self._load()# all members, we first have to
  File "/usr/lib/python3.7/tarfile.py", line 2350, in _load
tarinfo = self.next()
  File "/usr/lib/python3.7/tarfile.py", line 2281, in next
self.fileobj.seek(self.offset - 1)
  File "/usr/lib/python3.7/gzip.py", line 368, in seek
return self._buffer.seek(offset, whence)
  File "/usr/lib/python3.7/_compression.py", line 143, in seek
data = self.read(min(io.DEFAULT_BUFFER_SIZE, offset))
  File "/usr/lib/python3.7/gzip.py", line 454, in read
self._read_eof()
  File "/usr/lib/python3.7/gzip.py", line 501, in _read_eof
hex(self._crc)))
OSError: CRC check failed 0x21e25017 != 0x7c839e8b
```

The OSError exception isn't documented as a possible exception when using 
TarFile.getmembers ( https://docs.python.org/3/library/tarfile.html ).

--
components: Library (Lib)
files: crash-462a00f845e737bff6df2fe6467fc7cdd4c39cd8e27ef1d3011ec68a9808ca8e
messages: 358485
nosy: jvoisin
priority: normal
severity: normal
status: open
title: OSError in TarFile.getmembers()
type: behavior
versions: Python 3.7
Added file: 
https://bugs.python.org/file48783/crash-462a00f845e737bff6df2fe6467fc7cdd4c39cd8e27ef1d3011ec68a9808ca8e

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39064] ValueError in zipfile.ZipFile

[jvoisin]

New submission from jvoisin :

The attached file produces the following stacktrace when opened via 
`zipfile.ZipFile`, on Python 3.7.5rc1:

```
$ cat ziprepro.py 
import zipfile
import sys

zipfile.ZipFile(sys.argv[1])
```

```
$ python3 ziprepro.py 
crash-4da08e9ababa495ac51ecad588fd61081a66b5bb6e7a0e791f44907fa274ec62
Traceback (most recent call last):
  File "ziprepro.py", line 4, in 
zipfile.ZipFile(sys.argv[1])
  File "/usr/lib/python3.7/zipfile.py", line 1225, in __init__
self._RealGetContents()
  File "/usr/lib/python3.7/zipfile.py", line 1310, in _RealGetContents
fp.seek(self.start_dir, 0)
ValueError: cannot fit 'int' into an offset-sized integer
```

The ValueError exception isn't documented as a possible exception when using 
zipfile.ZipFile ( https://docs.python.org/3/library/tarfile.html ).

--
components: Library (Lib)
files: crash-4da08e9ababa495ac51ecad588fd61081a66b5bb6e7a0e791f44907fa274ec62
messages: 358484
nosy: jvoisin
priority: normal
severity: normal
status: open
title: ValueError in zipfile.ZipFile
type: behavior
versions: Python 3.7
Added file: 
https://bugs.python.org/file48782/crash-4da08e9ababa495ac51ecad588fd61081a66b5bb6e7a0e791f44907fa274ec62

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26978] Implement pathlib.Path.link (Using os.link)

[miss-islington]

miss-islington  added the comment:


New changeset 8d0f36940e728989822c3789025b0813a8fe249a by Miss Islington (bot) 
in branch '3.8':
bpo-38811: Check for presence of os.link method in pathlib (GH-17225)
https://github.com/python/cpython/commit/8d0f36940e728989822c3789025b0813a8fe249a


--
nosy: +miss-islington

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38811] Pathlib crashes when os module is missing 'link' method

[STINNER Victor]

STINNER Victor  added the comment:

If someone cares about the missing os.symlink code path: please open a 
separated issue.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38811] Pathlib crashes when os module is missing 'link' method

[miss-islington]

miss-islington  added the comment:


New changeset 8d0f36940e728989822c3789025b0813a8fe249a by Miss Islington (bot) 
in branch '3.8':
bpo-38811: Check for presence of os.link method in pathlib (GH-17225)
https://github.com/python/cpython/commit/8d0f36940e728989822c3789025b0813a8fe249a


--
nosy: +miss-islington

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38993] cProfile behaviour issue with decorator and math.factorial() lib.

[Mark Dickinson]

Change by Mark Dickinson :


--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39063] Format string does not work with "in" statement

[Ramon Medeiros]

Change by Ramon  Medeiros :


--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38811] Pathlib crashes when os module is missing 'link' method

[STINNER Victor]

STINNER Victor  added the comment:

Thanks Toke Høiland-Jørgensen! I merged your fix.

I don't really get why the Debian/Ubuntu image on Travis CI didn't get 
os.link() function, but I'm not really intersted to dig into this question. 
It's fine to simply skip the feature if it's not available, we do that in many 
places in Python.

I asked Toke Høiland-Jørgensen to revert his changes about os.symlink(): the 
pathlib code to handle missing os.symlink() seems to be broken, but it also 
seems like Python no longer support platforms without os.symlink(). Only old 
Windows version didn't support os.symlink(), but Python don't support these 
versions anymore.

I merged the os.link() change into master and made a 3.8 backport which will be 
merged automatically soon.

I close the issue.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39063] Format string does not work with "in" statement

[Ramon Medeiros]

New submission from Ramon  Medeiros :

Tried to use "in" statement to check if a string exists in a array and failed 
using string format.

How to reproduce:

~/ ipython
Python 3.7.4 (default, Oct 12 2019, 18:55:28)
Type 'copyright', 'credits' or 'license' for more information
IPython 7.8.0 -- An enhanced Interactive Python. Type '?' for help.

In [2]: "a" in ["a", "b"]
Out[2]: True

In [4]: z = "a"

In [5]: f"{z}" in ["a", "b"]
Out[5]: True

In [6]: z = "b"

In [7]: f"{z}" in ["a", "b"]
Out[7]: True

--
components: 2to3 (2.x to 3.x conversion tool)
messages: 358479
nosy: ramon@gmail.com
priority: normal
severity: normal
status: open
title: Format string does not work with "in" statement
versions: Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38870] Expose ast.unparse in the ast module

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:


New changeset a322f50c369e2e4138266c88e32ef83af95b2da6 by Pablo Galindo 
(Batuhan Taşkaya) in branch 'master':
bpo-38870: Remove dead code related with argument unparsing (GH-17613)
https://github.com/python/cpython/commit/a322f50c369e2e4138266c88e32ef83af95b2da6


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38811] Pathlib crashes when os module is missing 'link' method

[miss-islington]

Change by miss-islington :


--
pull_requests: +17094
pull_request: https://github.com/python/cpython/pull/17626

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26978] Implement pathlib.Path.link (Using os.link)

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 092435e932dee1802784ec28f39454f50fdd879a by Victor Stinner (Toke 
Høiland-Jørgensen) in branch 'master':
bpo-38811: Check for presence of os.link method in pathlib (GH-17225)
https://github.com/python/cpython/commit/092435e932dee1802784ec28f39454f50fdd879a


--
nosy: +vstinner

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38811] Pathlib crashes when os module is missing 'link' method

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 092435e932dee1802784ec28f39454f50fdd879a by Victor Stinner (Toke 
Høiland-Jørgensen) in branch 'master':
bpo-38811: Check for presence of os.link method in pathlib (GH-17225)
https://github.com/python/cpython/commit/092435e932dee1802784ec28f39454f50fdd879a


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26978] Implement pathlib.Path.link (Using os.link)

[miss-islington]

Change by miss-islington :


--
pull_requests: +17095
pull_request: https://github.com/python/cpython/pull/17626

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39060] asyncio.Task.print_stack doesn't print the full stack

[Amit Itzkovitch]

Amit Itzkovitch  added the comment:

In is mainly confusing because I expected this function to behave like 
"traceback.print_stack()", which prints the stack including all the awaits that 
lead to it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39060] asyncio.Task.print_stack doesn't print the full stack

[Andrew Svetlov]

Andrew Svetlov  added the comment:

Technically the output is correct: a stack for async function call doesn't 
contain the outer async function that is used for awaiting.

Agree, it may sound confusing, but `await f()` is not the same as just `f()`.

Perhaps we can provide *alternative* API for retrieving async call stack.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39059] Getting incorrect results in rounding procedures

[AVicennA]

AVicennA  added the comment:

@steven.daprano, yes, my_round(2.675, 2) --> gave 2.68 and it's not buggy and 
not wrong. This is correct in this case. I advise you look at 5th class math 
book.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39062] ValueError in TarFile.getmembers

[jvoisin]

New submission from jvoisin :

The attached file produces the following stacktrace when opened via 
`tarfile.open`  and iterated with `TarFile.getmembers`, on Python 3.7.5rc1:

```
$ cat tarrepro.py
import tarfile
import sys

with tarfile.open(sys.argv[1]) as t:
  for member in t.getmembers():
pass
```

```
$ python3 tarrepro.py 
crash-7221297307ab37ac87be6ea6dd9b28d4d453c557aa3da8a2138ab98e015cd42a
Traceback (most recent call last):
  File "tarrepro.py", line 5, in 
for member in t.getmembers():
  File "/usr/lib/python3.7/tarfile.py", line 1763, in getmembers
self._load()# all members, we first have to
  File "/usr/lib/python3.7/tarfile.py", line 2350, in _load
tarinfo = self.next()
  File "/usr/lib/python3.7/tarfile.py", line 2281, in next
self.fileobj.seek(self.offset - 1)
ValueError: cannot fit 'int' into an offset-sized integer
```

This file isn't a valid tar file, it was created by a fuzzer.

--
components: Library (Lib)
files: crash-7221297307ab37ac87be6ea6dd9b28d4d453c557aa3da8a2138ab98e015cd42a
messages: 358472
nosy: jvoisin
priority: normal
severity: normal
status: open
title: ValueError in TarFile.getmembers
type: behavior
versions: Python 3.7
Added file: 
https://bugs.python.org/file48781/crash-7221297307ab37ac87be6ea6dd9b28d4d453c557aa3da8a2138ab98e015cd42a

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39059] Getting incorrect results in rounding procedures

[Mark Dickinson]

Change by Mark Dickinson :


--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39059] Getting incorrect results in rounding procedures

[Mark Dickinson]

Mark Dickinson  added the comment:

@AVicennA: as the docs you linked to explain, this is not a bug: `round` is 
giving the correct result in all cases (or at least, as correct as is possible 
given the use of binary floating-point).

Let's take just the first case, `round(2.675, 2)`. `2.675` is a numeric literal 
in the source that's converted to a Python object of type `float` whose value 
is stored[*] using the IEEE 754 binary64 format. The exact value of that object 
is then 2.67482236431605997495353221893310546875.

So the value that Python sees when rounding is *less* than the halfway case 
2.675, so it rounds down to 2.67. If you think that's not the right thing to 
do, I have a question for you: what result would you expect 
`round(2.6748, 2)` to give?

Your proposed my_round replacement is not a fix: unlike *round*, it does *not* 
do correct rounding in all cases, and does not always give the naively expected 
result in all cases either. To give just one example of many:

>>> my_round(4.395, 2)
4.39

So I don't really understand what action you're proposing here. `round` is as 
good as it can reasonably be, and the documentation already explains the 
weaknesses and links to further reading. Unless you're proposing that Python 
adopt decimal floating-point for its core float type, or that two-argument 
round be deprecated, there not really anything to be done here.

[*] Disclaimer: use of IEEE 754 is not guaranteed, but is overwhelmingly likely 
on common platforms.

--
nosy: +mark.dickinson

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39061] Garbage Collection optimizations cause "memory leak"

[Maxime Istasse]

New submission from Maxime Istasse :

When working on a self-referencing object in the young generation and the 
middle-generation collection kicks in, that object is directly moved to the old 
generation. (if I understood this well: 
https://github.com/python/cpython/blob/d68b592dd67cb87c4fa862a8d3b3fd0a7d05e113/Modules/gcmodule.c#L1192)
Then, it won't be freed until the old generation is collected, which happens to 
be much later. (because of this: 
https://github.com/python/cpython/blob/d68b592dd67cb87c4fa862a8d3b3fd0a7d05e113/Modules/gcmodule.c#L1388)

It happens to cause huge memory leaks if the self-referencing objects occupies 
a lot of RAM, which should be expected.

This is of course the kind of problem that I expect with garbage collection 
with bad parameters.

However, I also expected that playing with threshold0 could have been 
sufficient to solve it. However, the fact that we move the object to old 
generation every time the middle collection pops in forces the problem to 
happen once in a while, and in the end reaching very high memory consumption.

I think the best and simplest solution would be to move the objects one 
generation at a time. This would avoid the heavy but short-lived objects to 
make it to the old generation.

--
components: Interpreter Core
files: late_gc.py
messages: 358469
nosy: mistasse
priority: normal
severity: normal
status: open
title: Garbage Collection optimizations cause "memory leak"
type: resource usage
versions: Python 3.7
Added file: https://bugs.python.org/file48780/late_gc.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39059] Getting incorrect results in rounding procedures

[Steven D'Aprano]

Steven D'Aprano  added the comment:

You've spent a lot of time demonstrating behaviour, but have not given us any 
reason why you think the results given are wrong.

As far as I can tell, every single example you show is correct. You have even 
quoted one of the relevant sections from the docs. "This is not a bug..."

You've flagged this is a documentation bug, an IDLE bug, an interpreter core 
bug, a library bug, etc. It isn't all of those things! I don't know what you 
actually want: do you want to improve the documentation? Something else?

By the way, your function "my_round" is buggy. This is wrong:

my_round(2.675, 2)
2.68

The binary float 2.675 is exactly equal to 3011782250804019/1125899906842624, 
or in decimal, exactly 

2.67482236431605997495353221893310546875

Rounding to two decimal places is 2.67, not 2.68.

Can you explain why we shouldn't close this as Not A Bug?

--
nosy: +steven.daprano

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39060] asyncio.Task.print_stack doesn't print the full stack

[Amit Itzkovitch]

New submission from Amit Itzkovitch :

Hi!
I think I found some issue in the "print_stack()" function of asyncio.Task.
When I try to print the stack of some task, I only see the first few lines of 
the stack. 
Attached an example file, that contains a recursive function that after 10 
calls prints the stack of the task. 
You can see that the stack that it prints only shows the first call of the 
recursive function, although you would expect to see it 10 times.

Tested on python3.7 and 3.8 on both MacOS and CentOS, the result is the same. 

Your help will be appreciated very much! :)

--
components: asyncio
files: example.py
messages: 358468
nosy: amit7itz, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.Task.print_stack doesn't print the full stack
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48779/example.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39059] Getting incorrect results in rounding procedures

[AVicennA]

New submission from AVicennA :

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) 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.76468025576890795491635799407958984375
 &&
 2.675 --> 
2.67482236431605997495353221893310546875

It means that, the 76(5) --> 5 replaced in a memory as 4.()
 &&
   67(5) --> 5 replaced in a memory as 4.() '''

>>> from decimal import Decimal
>>> Decimal(2.675)
Decimal('2.67482236431605997495353221893310546875')
>>>
>>> Decimal(5.765)
Decimal('5.76468025576890795491635799407958984375')

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

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com