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

[Serhiy Storchaka]

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 duplicate all this code in 
pathlib if shutil.rmtree() already supports path-like objects.

--
nosy: +serhiy.storchaka
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> pathlib.Path wants an rmtree method

___
Python tracker 

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

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

[Fantix King]

Change by Fantix King :


--
pull_requests: +20057
pull_request: https://github.com/python/cpython/pull/20868

___
Python tracker 

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

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

[Kyle Stanley]

Change by Kyle Stanley :


--
nosy: +jaraco, lemburg

___
Python tracker 

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

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

[Kyle Stanley]

Change by Kyle Stanley :


--
nosy: +aeros

___
Python tracker 

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

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

[miss-islington]

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


--

___
Python tracker 

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

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

[SilentGhost]

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
resolution:  -> wont fix
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

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

[SilentGhost]

Change by SilentGhost :


--
nosy: +orsenthil

___
Python tracker 

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

[issue33498] pathlib.Path wants an rmtree method

[Charles Machalow]

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 to stick with the object methods. 
Same thought process for shutil for rmtree.

We already have things like owner() and group() that explicitly go import grp, 
pwd to do their job on Path objects. Why is shutil special with regards to 
using another piece of the standard library from pathlib? To me this request 
falls in the same boat as those functions; they were likely added for 
convenience and since it made sense.

I believe the very same holds true for the request to add rmtree().

--
nosy: +Charles Machalow

___
Python tracker 

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

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

[miss-islington]

Change by miss-islington :


--
pull_requests: +20058
pull_request: https://github.com/python/cpython/pull/20869

___
Python tracker 

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

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

[miss-islington]

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


--

___
Python tracker 

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

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

[Kyle Stanley]

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, which is definitely an improvement.

--
stage: patch review -> commit review
versions: +Python 3.10, Python 3.9 -Python 3.8

___
Python tracker 

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

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

[Cheryl Sabella]

Change by Cheryl Sabella :


--
nosy: +steve.dower, zach.ware
versions: +Python 3.10 -Python 3.9

___
Python tracker 

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

[issue31844] HTMLParser: undocumented not implemented method

[Cheryl Sabella]

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.sabella
versions: +Python 3.10 -Python 3.8

___
Python tracker 

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

[issue40974] possible optimization: SHRINK_STACK(n)

[SHRINK_STACK]

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). 

A possible patch:

(to peephole.c)
+
+case POP_TOP:
+h = i + 1;
+while (h < codelen && _Py_OPCODE(codestr[h]) == POP_TOP) {
+h++;
+}
+if (h > i + 1) {
+codestr[i] = PACKOPARG(SHRINK_STACK, h - i);
+fill_nops(codestr, i + 1, h);
+nexti = h;
+}
+break;


(to ceval.c)
 
+case TARGET(SHRINK_STACK): {
+for (int i = 0; i < oparg; i++) {
+PyObject *value = POP();
+Py_DECREF(value);
+}
+FAST_DISPATCH();
+}
+

and some other minor things for opcode.py and magic number

--
messages: 371501
nosy: shrink_stack
priority: normal
severity: normal
status: open
title: possible optimization: SHRINK_STACK(n)

___
Python tracker 

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

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

[Łukasz Langa]

Ł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/8a3469047c3c7b68f434ed244ef3ae4292dd8cbc


--

___
Python tracker 

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

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

[Naglis Jonaitis]

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/contextlib.py#L591

--
assignee: docs@python
components: Documentation
messages: 371503
nosy: docs@python, naglis
priority: normal
severity: normal
status: open
title: contextlib.AsyncExitStack enter_async_context and aclose should be 
labeled as coroutine methods
versions: Python 3.10, 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

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

[Naglis Jonaitis]

Change by Naglis Jonaitis :


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

___
Python tracker 

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

[issue40976] Clarify motivation for `chain.from_iterable`

[Ram Rachum]

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 

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

[issue40976] Clarify motivation for `chain.from_iterable`

[Ram Rachum]

Change by Ram Rachum :


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

___
Python tracker 

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

[issue40976] Clarify motivation for `chain.from_iterable`

[SilentGhost]

Change by SilentGhost :


--
assignee:  -> docs@python
components: +Documentation -Library (Lib)
nosy: +docs@python

___
Python tracker 

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

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

[Ronald Oussoren]

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.10.

It is too late to change this in 3.9, other than updating the warning message.

--
components: asyncio
messages: 371504
nosy: asvetlov, ronaldoussoren, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.trsock.TransportSocket says some APIs will be prohibited in 3.9
type: behavior
versions: Python 3.10, Python 3.9

___
Python tracker 

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

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

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
components: +asyncio
nosy: +asvetlov, yselivanov

___
Python tracker 

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

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

[E. Paine]

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!).

--

___
Python tracker 

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

[issue40974] possible optimization: SHRINK_STACK(n)

[Batuhan Taskaya]

Change by Batuhan Taskaya :


--
nosy: +Mark.Shannon, pablogsal

___
Python tracker 

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

[issue39171] Missing default root in tkinter simpledialog.py

[E. Paine]

Change by E. Paine :


--
nosy: +epaine
versions: +Python 3.10 -Python 3.9

___
Python tracker 

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

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

[Serhiy Storchaka]

Change by Serhiy Storchaka :


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

[issue40890] Dict views should be introspectable

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

There is a tiny portability issue.

--
status: closed -> open

___
Python tracker 

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

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

[Dong-hee Na]

Change by Dong-hee Na :


--
nosy: +corona10

___
Python tracker 

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

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

[Manuel Kaufmann]

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-docs-es/builds/698122676


Note that the WARNING does not mention a line number in the RST file. From what 
I could find, this is because the source English sentence is not in the .rst 
file, but it's a RST directive and the sentence comes from Python code: 
https://github.com/python/cpython/blob/6f8c8320e9eac9bc7a7f653b43506e75916ce8e8/Doc/tools/extensions/pyspecific.py#L135-L139

The original RST file, uses the directive here: 
https://github.com/python/cpython/blob/6f8c8320e9eac9bc7a7f653b43506e75916ce8e8/Doc/library/ctypes.rst#L1510


The PO file we are translating, does not have a header with line numbers for 
this paragraph: 
https://github.com/python/python-docs-es/blob/c51c38134ba74e26f73732ed96584325536141d3/library/ctypes.po#L1456-L1459

--
nosy: +humitos

___
Python tracker 

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

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

[E. Paine]

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":

bind .  {puts {L shift down}}
bind .  {puts {L shift up}}
bind .  {puts {R shift down}}
bind .  {puts {R shift up}}

You can take this issue up with the Tcl team if you want 
(https://core.tcl-lang.org/index.html), however, I ask that you close this 
issue as third party.

--
nosy: +epaine

___
Python tracker 

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

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

[Cheryl Sabella]

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

___
Python tracker 

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

[issue40969] Python 3.8.3 And Now For Something CompletelyDifferent

[Cheryl Sabella]

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

___
Python tracker 

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

[issue40974] possible optimization: SHRINK_STACK(n)

[Pablo Galindo Salgado]

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 another opcode, 
especially since the new opcode won't replace POP_TOP (so we need to deal with 
both).

Without evaluating the tradeoffs and how it plays into the current status quo I 
have some initial questions:

- What is the performance improvement of the patch that you propose? Could you 
run the pyperformance benchmark suite to have some numbers? 

- How many opcodes less are we talking about? What is the size before and after 
the suggested change in the stdlib pyc files?

--

___
Python tracker 

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

[issue40974] possible optimization: SHRINK_STACK(n)

[Raymond Hettinger]

Change by Raymond Hettinger :


--
nosy: +rhettinger

___
Python tracker 

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

[issue40974] possible optimization: SHRINK_STACK(n)

[Serhiy Storchaka]

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 are possible negative effects. We should have evidence 
that this change actually improves performance.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

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

[ramalho]

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 entry for `@runtime_checkable`

* SupportsAbs
* SupportsBytes
* SupportsComplex
* SupportsFloat
* SupportsIndex
* SupportsInt
* SupportsRound

--
assignee: docs@python
components: Documentation
messages: 371513
nosy: docs@python, ramalho
priority: normal
severity: normal
status: open
title: Document that typing.SupportsXXX protocols are runtime checkable
versions: Python 3.10, 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

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

[ramalho]

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: it's not alphabetical. Its grouped according to invisible 
categories. 

The categories appear as comments in the source code of typing.py: the 
`__all__` global lists the API split into categories (see below). We should add 
these categories to the page as subsections of "Classes, functions, and 
decorators"

- Super-special typing primitives.
- ABCs (from collections.abc).
- Structural checks, a.k.a. protocols.
- Concrete collection types.

--
assignee: docs@python
components: Documentation
messages: 371514
nosy: docs@python, ramalho
priority: normal
severity: normal
status: open
title: typing module docs: keep text, add subsections
versions: Python 3.10, 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

[issue40963] distutils make_zipfile uses random order

[Raymond Hettinger]

Raymond Hettinger  added the comment:

+1 for sorting filenames prior to insertion

--
nosy: +rhettinger

___
Python tracker 

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

[issue40890] Dict views should be introspectable

[Dennis Sweeney]

Change by Dennis Sweeney :


--
pull_requests: +20061
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/20873

___
Python tracker 

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

[issue40980] group names of bytes regexes are strings

[Quentin Wenger]

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. doc:

> Both patterns and strings to be searched can be Unicode strings (str) as well 
> as 8-bit strings (bytes). However, Unicode strings and 8-bit strings cannot 
> be mixed: that is, you cannot match a Unicode string with a byte pattern or 
> vice-versa; similarly, when asking for a substitution, the replacement string 
> must be of the same type as both the pattern and the search string.

--
components: Regular Expressions
messages: 371516
nosy: ezio.melotti, matpi, mrabarnett
priority: normal
severity: normal
status: open
title: group names of bytes regexes are strings
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

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

[Rémi Lapeyre]

Change by Rémi Lapeyre :


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

___
Python tracker 

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

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

[Jakub Stasiak]

Change by Jakub Stasiak :


--
nosy: +jstasiak

___
Python tracker 

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

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

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
pull_requests: +20063
pull_request: https://github.com/python/cpython/pull/20875

___
Python tracker 

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

[issue40890] Dict views should be introspectable

[Pablo Galindo Salgado]

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 

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

[issue40890] Dict views should be introspectable

[Pablo Galindo Salgado]

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


--

___
Python tracker 

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

[issue36346] Prepare for removing the legacy Unicode C API

[Inada Naoki]

Change by Inada Naoki :


--
pull_requests: +20065
pull_request: https://github.com/python/cpython/pull/20878

___
Python tracker 

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

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

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +gvanrossum, levkivskyi

___
Python tracker 

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

[issue36346] Prepare for removing the legacy Unicode C API

[Inada Naoki]

Change by Inada Naoki :


--
pull_requests: +20066
pull_request: https://github.com/python/cpython/pull/20879

___
Python tracker 

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

[issue40976] Clarify motivation for `chain.from_iterable`

[Raymond Hettinger]

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

___
Python tracker 

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

[issue40981] increment is wrong in 3.7

[mike stern]

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
0.4
0.5
0.6
0.7
0.7999
0.8999
0.
1.0999
1.2

what the heck is going on, can someone explain to me

--
assignee: terry.reedy
components: IDLE
messages: 371519
nosy: rskir...@hotmail.com, terry.reedy
priority: normal
severity: normal
status: open
title: increment is wrong in 3.7
type: behavior
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

[issue36144] Dictionary union. (PEP 584)

[Sumit Jaiswal]

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]}
>>> d2 = {'spam': [2, 3, 4]}
>>> d1 | d2
>>> {'spam': [1, 2, 3, 4]}

--
nosy: +justjais

___
Python tracker 

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

[issue40981] increment is wrong in 3.7

[Serhiy Storchaka]

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

[issue40890] Dict views should be introspectable

[Serhiy Storchaka]

Change by Serhiy Storchaka :


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

[issue40981] increment is wrong in 3.7

[mike stern]

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 trust a language behaving crazy like this

the problem is not there in 2.7

why you closed the ticket , who are you

--
status: closed -> open

___
Python tracker 

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

[issue40981] increment is wrong in 3.7

[SilentGhost]

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

___
Python tracker 

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

[issue40981] increment is wrong in 3.7

[mike stern]

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

please don't close this ticket until we understand that there is actually this 
problem in 3.7 and that the problem is fixed

--
nosy:  -SilentGhost
status: closed -> open

___
Python tracker 

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

[issue40981] increment is wrong in 3.7

[Christian Heimes]

Change by Christian Heimes :


--
status: open -> closed

___
Python tracker 

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

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

[mike stern]

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 

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

[issue40981] increment is wrong in 3.7

[mike stern]

mike stern  added the comment:

Christian Heimes why did you close it

--
status: closed -> open

___
Python tracker 

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

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

[Christian Heimes]

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 

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

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

[mike stern]

mike stern  added the comment:

Christian Heimes you haven't tried it on 2.7 did you ?

--
status: closed -> open

___
Python tracker 

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

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

[Christian Heimes]

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 
closed bug. Do not reopen the bug again.

--
status: open -> closed

___
Python tracker 

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

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

[mike stern]

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@roundup.psfhosted.org 
 on behalf of Christian Heimes 

Sent: Monday, June 15, 2020 2:40 AM
To: rskir...@hotmail.com 
Subject: [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 
closed bug. Do not reopen the bug again.

--
status: open -> closed

___
Python tracker 

___

--

___
Python tracker 

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

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

[mike stern]

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-God 
Sent: Monday, June 15, 2020 2:45 AM
To: Python tracker 
Subject: Re: [issue40981] increment is wrong in 3.7 but not in 2.7

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@roundup.psfhosted.org 
 on behalf of Christian Heimes 

Sent: Monday, June 15, 2020 2:40 AM
To: rskir...@hotmail.com 
Subject: [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 
closed bug. Do not reopen the bug again.

--
status: open -> closed

___
Python tracker 

___

--

___
Python tracker 

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

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

[mike stern]

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-God 
Sent: Monday, June 15, 2020 2:45 AM
To: Python tracker 
Subject: Re: [issue40981] increment is wrong in 3.7 but not in 2.7

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@roundup.psfhosted.org 
 on behalf of Christian Heimes 

Sent: Monday, June 15, 2020 2:40 AM
To: rskir...@hotmail.com 
Subject: [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 
closed bug. Do not reopen the bug again.

--
status: open -> closed

___
Python tracker 

___

--

___
Python tracker 

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

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

[Steven D'Aprano]

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 floating point numbers at all.


> you haven't tried it on 2.7 did you ?

We know how Python 2.7 works. Some of us have been using Python for 25 years, 
since version 1.5 or older. Do you think you are the first person to have 
noticed this? There are hundreds of thousands of Python programmers, believe me 
you're not the first, or even the ten-thousandth person to have noticed.

Python 2.7 rounds off the default display of floats to make them look "pretty" 
instead of displaying their actual value. Try this in 2.7 and see what happens:

i=0
while i < 1.2:
i += 0.1
print "default:", i, "actual: %.24f" % i

The calculations are *precisely* the same, only the display is different.

Honestly Mike, this is not a Python issue, it is universal to all languages 
with fixed-size floating point numbers. This is not a bug, it is how numeric 
computing works *everywhere*. People write peer reviewed scientific papers 
about this:

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.22.6768

https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html


If you want to educate yourself on the issue, rather than just rant about not 
trusting the language and abuse people who have been using the language for 
decades, you could do a lot worse than to start here:

https://randomascii.wordpress.com/2012/05/20/thats-not-normalthe-performance-of-odd-floats/

https://randomascii.wordpress.com/2012/04/05/floating-point-complexities/

and take careful note that the author talks about C, probably the most common, 
fundamental and trusted programming language in the world. (Also remember that 
when Bruce Dawson talks about floats in C, they are half the precision of 
Python floats, which are C doubles.)

The bottom line is that floats are not the infinitely precise exact 
mathematical numbers we learn about in school, they are more like the numbers 
you get on a calculator.

--
nosy: +steven.daprano

___
Python tracker 

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