[issue40981] increment is wrong in 3.7 but not in 2.7

Steven D'Aprano added the comment: > I wouldn't trust a language behaving crazy like this I guess then you won't trust C, Java, C++, Swift, Javascript, Ruby, Cobol, Fortran, and pretty much every programming language in existence. The only ones that escape this are ones that don't have float

[issue40981] increment is wrong in 3.7 but not in 2.7

mike stern added the comment: you can at least try it and see for yourself that what I am saying is actually true but never mind I will keep on opening tickets until someone tries it on 2.7 and see what I am talking about From: Redwane Freedom Is-to-Be-With-

[issue40981] increment is wrong in 3.7 but not in 2.7

mike stern added the comment: you can at least try it and see for yourself that what I am saying is actually true but never mind I will keep on opening tickets until someone tries it on 2.7 and see what I am talking about From: Redwane Freedom Is-to-Be-With-

[issue40981] increment is wrong in 3.7 but not in 2.7

mike stern added the comment: what is rude is to talk to me in an autoritative way like you do you haven't even checked what I said , I said it working in Python 2.7 and it is not in 3.7 and you want to just read me an article. From: report=bugs.python@rou

[issue40981] increment is wrong in 3.7 but not in 2.7

Christian Heimes added the comment: Python's float are IEE 754 floats for over 25 years and since Python 1.x, maybe earlier. IIRC standard is from 1985. It's how CPUs have dealt with floats for over 35 years. By the way it's is incredible rude to keep re-opening a bug and responding on a cl

[issue40981] increment is wrong in 3.7 but not in 2.7

mike stern added the comment: Christian Heimes you haven't tried it on 2.7 did you ? -- status: closed -> open ___ Python tracker ___ _

[issue40981] increment is wrong in 3.7 but not in 2.7

Christian Heimes added the comment: Multiple people already told you that it is not a bug. It's how floating point standard IEEE 754 works. -- nosy: +christian.heimes status: open -> closed ___ Python tracker _

[issue40981] increment is wrong in 3.7

mike stern added the comment: Christian Heimes why did you close it -- status: closed -> open ___ Python tracker ___ ___ Python-bug

[issue40981] increment is wrong in 3.7 but not in 2.7

Change by mike stern : -- nosy: -serhiy.storchaka, terry.reedy title: increment is wrong in 3.7 -> increment is wrong in 3.7 but not in 2.7 ___ Python tracker ___

[issue40981] increment is wrong in 3.7

Change by Christian Heimes : -- status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https:

[issue40981] increment is wrong in 3.7

mike stern added the comment: so anybody can close a ticket ? anybody can say their point of view and close a ticket, is that how it goes? this is not serious who is managing this ? is this how we can trust a programming language? it sounds like we are dealing with irresponsible kids here ple

[issue40981] increment is wrong in 3.7

SilentGhost added the comment: This isn't a problem, this is how floating number implemented in Python and many other languages. Please read the linked detailed explanation and do not re-open the ticket. -- nosy: +SilentGhost status: open -> closed __

[issue40981] increment is wrong in 3.7

mike stern added the comment: problem actually more serious, it is here print(0.7+0.1) , which gives .7999 same thing when adding the .1 increment to 4.8 , 5.1 etc ... I am not sure of the pattern but it is acting up with some numbers who will fix this , this is serious I wouldn't tr

[issue40890] Dict views should be introspectable

Change by Serhiy Storchaka : -- stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___ Python-bugs-list m

[issue40981] increment is wrong in 3.7

Serhiy Storchaka added the comment: https://docs.python.org/3/faq/design.html#why-are-floating-point-calculations-so-inaccurate This is not Python 3.7 specific issue, and is not even Python issue. It is how floating-point numbers work. -- nosy: +serhiy.storchaka resolution: -> not a

[issue36144] Dictionary union. (PEP 584)

Sumit Jaiswal added the comment: First off, thanks for adding the feature, it's much appreciated. But it'd be great if you guys can enable list merge for the dict having list as its value, in current form I believe it's handling only "key: value" merge. for e.g.: >>> d1 = {'spam': [1, 2, 3]}

[issue40981] increment is wrong in 3.7

New submission from mike stern : I noticed i big problem making a simple increment of .1 in python 3.7 using while the result is wrong i=0 while i < 1.2: i += 0.1 print(i) result == RESTART: C:/Users/icosf/AppData/Local/Programs/Python/Python37-32/bb.py == 0.1 0.2 0.30004

[issue40976] Clarify motivation for `chain.from_iterable`

New submission from Raymond Hettinger : Thank you for the suggestion, but we're going to decline for the reasons mentioned in the PR. Feel free to submit other ideas. -- nosy: +rhettinger resolution: -> rejected stage: patch review -> resolved status: open -> closed

[issue36346] Prepare for removing the legacy Unicode C API

Change by Inada Naoki : -- pull_requests: +20066 pull_request: https://github.com/python/cpython/pull/20879 ___ Python tracker ___ _

[issue40978] Document that typing.SupportsXXX protocols are runtime checkable

Change by Karthikeyan Singaravelan : -- nosy: +gvanrossum, levkivskyi ___ Python tracker ___ ___ Python-bugs-list mailing list Unsub

[issue36346] Prepare for removing the legacy Unicode C API

Change by Inada Naoki : -- pull_requests: +20065 pull_request: https://github.com/python/cpython/pull/20878 ___ Python tracker ___ _

[issue40890] Dict views should be introspectable

Pablo Galindo Salgado added the comment: New changeset 10c3b2120afa01b2c310ac50e99d8b98c943b0a2 by Pablo Galindo in branch 'master': bpo-40890: Fix compiler warning in dictobject.c (GH-20876) https://github.com/python/cpython/commit/10c3b2120afa01b2c310ac50e99d8b98c943b0a2 -- _

[issue40890] Dict views should be introspectable

Change by Pablo Galindo Salgado : -- nosy: +pablogsal nosy_count: 5.0 -> 6.0 pull_requests: +20064 pull_request: https://github.com/python/cpython/pull/20876 ___ Python tracker ___

[issue40958] ASAN/UBSAN: heap-buffer-overflow in pegen.c

Change by Pablo Galindo Salgado : -- pull_requests: +20063 pull_request: https://github.com/python/cpython/pull/20875 ___ Python tracker ___ ___

[issue40548] Always run GitHub action jobs, even on documentation-only jobs

Change by Jakub Stasiak : -- nosy: +jstasiak ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyt

[issue40967] asyncio.Task.all_tasks() and asyncio.Task.current_task() must be removed in 3.9

Change by Rémi Lapeyre : -- keywords: +patch pull_requests: +20062 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20874 ___ Python tracker ___

[issue40980] group names of bytes regexes are strings

New submission from Quentin Wenger : I noticed that match.groupdict() returns string keys, even for a bytes regex: ``` >>> import re >>> re.match(b"(?P)", b"").groupdict() {'a': b''} ``` This seems somewhat strange, because string and bytes matching in re are kind of two separate parts, cf. d

[issue40890] Dict views should be introspectable

Change by Dennis Sweeney : -- pull_requests: +20061 stage: resolved -> patch review pull_request: https://github.com/python/cpython/pull/20873 ___ Python tracker ___ __

[issue40963] distutils make_zipfile uses random order

Raymond Hettinger added the comment: +1 for sorting filenames prior to insertion -- nosy: +rhettinger ___ Python tracker ___ ___ Py

[issue40979] typing module docs: keep text, add subsections

New submission from ramalho : The typing module documentation page has a very long section "Classes, functions, and decorators" (https://docs.python.org/3/library/typing.html#classes-functions-and-decorators) that should be split in subsections. The ordering of the entries seems haphazard: i

[issue40978] Document that typing.SupportsXXX protocols are runtime checkable

New submission from ramalho : The typing module documentation (https://docs.python.org/3/library/typing.html#typing.SupportsInt) does not mention that the protocols listed below are all decorated with `@runtime_checkable`. This should mentioned in the entry for each protocol and also in the

[issue40974] possible optimization: SHRINK_STACK(n)

Serhiy Storchaka added the comment: It increases the size of the eval loop. It can break optimizations which is performed by the C compiler only when the code size does not exceed some limits, and it can exceed the size of processor caches which can make execution less efficient. So there ar

[issue40974] possible optimization: SHRINK_STACK(n)

Change by Raymond Hettinger : -- nosy: +rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://ma

[issue40974] possible optimization: SHRINK_STACK(n)

Pablo Galindo Salgado added the comment: > less opcodes = faster evaluation Unfortunately, that is not always true as opcodes can have arbitrary complexity and there are very low-level effects that are relevant in the eval loop. Even if it is better, the improvement may not be worth burning

[issue40969] Python 3.8.3 And Now For Something CompletelyDifferent

Cheryl Sabella added the comment: Good catch! Please open an issue for this on the pythondotorg repo at https://github.com/python/pythondotorg/issues. Thanks! -- nosy: +cheryl.sabella resolution: -> third party stage: -> resolved status: open -> closed ___

[issue39756] Event sequence "KeyRelease-Shift_R" not being fired

Cheryl Sabella added the comment: @Devin Morgan, thank you for the report and @epaine, thank you for researching the cause. I'll close this as third party. -- nosy: +cheryl.sabella resolution: -> third party stage: -> resolved status: open -> closed ___

[issue39756] Event sequence "KeyRelease-Shift_R" not being fired

E. Paine added the comment: This is strange, as the release of the right-shift key triggers the binding for the left-shift release. This issue, however, is not a tkinter issue (which just passes the calls onto Tcl/Tk), as running the following in 'wish' prints "R shift down L shift up": bi

[issue39229] library/functions.rst causes translated builds to fail

Manuel Kaufmann added the comment: We are having a similar issue in python-docs-es translation. cpython/Doc/library/ctypes.rst:: WARNING: inconsistent term references in translated message. original: [], translated: [':ref:`evento de auditoría `'] https://travis-ci.org/github/python/python-

[issue34480] _markupbase.py fails with UnboundLocalError on invalid keyword in marked section

Change by Dong-hee Na : -- nosy: +corona10 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue40890] Dict views should be introspectable

Serhiy Storchaka added the comment: There is a tiny portability issue. -- status: closed -> open ___ Python tracker ___ ___ Python-

[issue40945] TKinter.Tk.geometry(Tk.winfo_geometry()) should be idempotent

Change by Serhiy Storchaka : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker ___ ___ Pyth

[issue39171] Missing default root in tkinter simpledialog.py

Change by E. Paine : -- nosy: +epaine versions: +Python 3.10 -Python 3.9 ___ Python tracker ___ ___ Python-bugs-list mailing list Un

[issue40974] possible optimization: SHRINK_STACK(n)

Change by Batuhan Taskaya : -- nosy: +Mark.Shannon, pablogsal ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40945] TKinter.Tk.geometry(Tk.winfo_geometry()) should be idempotent

E. Paine added the comment: I am glad I was able to help. To be consistent with Tk, I don't think the tkinter behaviour should be changed. If you agree, I would really appreciate if you could close the issue as "not a bug" (to give the core devs one less issue they need to look through!).

[issue40975] contextlib.AsyncExitStack enter_async_context and aclose should be labeled as coroutine methods

Change by Karthikeyan Singaravelan : -- components: +asyncio nosy: +asvetlov, yselivanov ___ Python tracker ___ ___ Python-bugs-list

[issue40977] asyncio.trsock.TransportSocket says some APIs will be prohibited in 3.9

New submission from Ronald Oussoren : The implementation for asyncio.trsock.TransportSocket says that a number of methods will be prohibited in 3.9 (https://github.com/python/cpython/blob/8f04a84755babe516ebb5304904ea7c15b865c80/Lib/asyncio/trsock.py#L19), but merely warns in both 3.9 and 3.1

[issue40976] Clarify motivation for `chain.from_iterable`

Change by SilentGhost : -- assignee: -> docs@python components: +Documentation -Library (Lib) nosy: +docs@python ___ Python tracker ___ ___

[issue40976] Clarify motivation for `chain.from_iterable`

Change by Ram Rachum : -- keywords: +patch pull_requests: +20060 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20871 ___ Python tracker ___ _

[issue40976] Clarify motivation for `chain.from_iterable`

Change by Ram Rachum : -- components: Library (Lib) nosy: cool-RR priority: normal severity: normal status: open title: Clarify motivation for `chain.from_iterable` type: enhancement versions: Python 3.10 ___ Python tracker

[issue40975] contextlib.AsyncExitStack enter_async_context and aclose should be labeled as coroutine methods

Change by Naglis Jonaitis : -- keywords: +patch pull_requests: +20059 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20870 ___ Python tracker ___

[issue40975] contextlib.AsyncExitStack enter_async_context and aclose should be labeled as coroutine methods

New submission from Naglis Jonaitis : enter_async_context[1] and aclose[2] are coroutine methods. 1: https://github.com/python/cpython/blob/8f04a84755babe516ebb5304904ea7c15b865c80/Lib/contextlib.py#L548 2: https://github.com/python/cpython/blob/8f04a84755babe516ebb5304904ea7c15b865c80/Lib/co

[issue40924] Recent importlib change breaks most recent certifi == 2020.4.5.2

Łukasz Langa added the comment: New changeset 8a3469047c3c7b68f434ed244ef3ae4292dd8cbc by Jason R. Coombs in branch '3.9': [3.9] bpo-40924: Remove protocol for supplying Traversable objects from loaders (GH-20820) https://github.com/python/cpython/commit/8a3469047c3c7b68f434ed244ef3ae4292dd8c

[issue40974] possible optimization: SHRINK_STACK(n)

New submission from SHRINK_STACK : context managers and except blocks generates multiple POP_TOPS constantly and maybe other cases which might lead generation of multiple POP_TOPS. A SHRINK_STACK(n) opcode would make things better (improvement on pyc size, less opcodes = faster evaluation).

[issue31844] HTMLParser: undocumented not implemented method

Cheryl Sabella added the comment: @berker.peksag's last comment was he closed the PR on 23 August 2018. However, he reopened it on 6 January 2020 as @ezio.melotti mentioned that they are both needed. The PR for this issue is waiting to be re-reviewed by Ezio. -- nosy: +cheryl.sabel

[issue38252] Use 8-byte step to detect ASCII sequence in 64bit Windows builds

Change by Cheryl Sabella : -- nosy: +steve.dower, zach.ware versions: +Python 3.10 -Python 3.9 ___ Python tracker ___ ___ Python-bug

[issue30064] BaseSelectorEventLoop.sock_{recv, sendall}() don't remove their callbacks when canceled

Kyle Stanley added the comment: Thanks again for working on this @Fantix, and for the continued vigilance on the issue after the test failures occurred in the buildbots. I think this recent PR-20868 will do the trick. At the very least, it will make the failure much more rare than before, wh

[issue30064] BaseSelectorEventLoop.sock_{recv, sendall}() don't remove their callbacks when canceled

miss-islington added the comment: New changeset 83cd968f5cc59ad60b665080087f50fefac17a07 by Miss Islington (bot) in branch '3.9': bpo-30064: Fix slow asyncio sock test (GH-20868) https://github.com/python/cpython/commit/83cd968f5cc59ad60b665080087f50fefac17a07 -- __

[issue30064] BaseSelectorEventLoop.sock_{recv, sendall}() don't remove their callbacks when canceled

Change by miss-islington : -- pull_requests: +20058 pull_request: https://github.com/python/cpython/pull/20869 ___ Python tracker ___ __

[issue33498] pathlib.Path wants an rmtree method

Charles Machalow added the comment: I'm disappointed to see this closed. For new (and old) users, it makes complete sense to have an rmtree method on the Path object itself. If I'm using pathlib, I try not to delegate to os. for file operations, since it also tends to seem more OO and clean

[issue40968] urllib is unable to deal with TURN server infront

Change by SilentGhost : -- nosy: +orsenthil ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyth

[issue40973] platform.platform() in Python 3.8 does not report detailed Linux platform information

SilentGhost added the comment: This is the result of removal of platform.linux_distribution() in #28167. Which was deprecated since 3.5. As far as I understand, suggested replacement is distro package on pypi (https://pypi.org/project/distro/). -- nosy: +SilentGhost, petr.viktorin re

[issue30064] BaseSelectorEventLoop.sock_{recv, sendall}() don't remove their callbacks when canceled

miss-islington added the comment: New changeset 8f04a84755babe516ebb5304904ea7c15b865c80 by Fantix King in branch 'master': bpo-30064: Fix slow asyncio sock test (GH-20868) https://github.com/python/cpython/commit/8f04a84755babe516ebb5304904ea7c15b865c80 --

[issue40973] platform.platform() in Python 3.8 does not report detailed Linux platform information

Change by Kyle Stanley : -- nosy: +aeros ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.

[issue40973] platform.platform() in Python 3.8 does not report detailed Linux platform information

Change by Kyle Stanley : -- nosy: +jaraco, lemburg ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://ma

[issue30064] BaseSelectorEventLoop.sock_{recv, sendall}() don't remove their callbacks when canceled

Change by Fantix King : -- pull_requests: +20057 pull_request: https://github.com/python/cpython/pull/20868 ___ Python tracker ___ _

[issue40972] Add a recurse flag to Path.rmdir()

Serhiy Storchaka added the comment: This is virtually a duplicate of issue33498. shutil.rmtree() is very complex function. It is not trivial task to remove directories and files recursively in safe and efficient way. It needs also a way to customize errors handling. We do not want to duplica