[issue43396] Non-existent method sqlite3.Connection.fetchone() used in docs

[Tore Anderson]

New submission from Tore Anderson :

In https://docs.python.org/3/library/sqlite3.html, the following example code 
is found:

> # Do this instead
> t = ('RHAT',)
> c.execute('SELECT * FROM stocks WHERE symbol=?', t)
> print(c.fetchone())

However this fails as follows:

> Traceback (most recent call last):
>   File "./test.py", line 8, in 
> print(c.fetchone())
> AttributeError: 'sqlite3.Connection' object has no attribute 'fetchone'

I believe the correct code should have been (at least it works for me):

> # Do this instead
> t = ('RHAT',)
> cursor = c.execute('SELECT * FROM stocks WHERE symbol=?', t)
> print(cursor.fetchone())

Tore

--
assignee: docs@python
components: Documentation
messages: 388078
nosy: docs@python, toreanderson
priority: normal
severity: normal
status: open
title: Non-existent method sqlite3.Connection.fetchone() used in docs
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

[issue43395] os.path states that bytes can't represent all MBCS paths under Windows

[Eric L.]

New submission from Eric L. :

The os.path documentation at https://docs.python.org/3/library/os.path.html 
states that:

> Vice versa, using bytes objects cannot represent all file names on Windows 
> (in the standard mbcs encoding), hence Windows applications should use string 
> objects to access all files.

This doesn't sound right and is at least misleading because anything can be 
represented as bytes, as everything (in a computer) is bytes at the end of the 
day, unless mbcs is really using something like half-bytes, which I couldn't 
find any sign of (skimming through the documentation, Microsoft seems to 
interpret it as DBCS, one or two bytes).

I could imagine that the meaning is that some bytes combinations can't be used 
as path under Windows, but I just don't know, and that wouldn't be a valid 
reason to not use bytes under Windows (IMHO).

--
assignee: docs@python
components: Documentation
messages: 388077
nosy: docs@python, ericzolf
priority: normal
severity: normal
status: open
title: os.path states that bytes can't represent all MBCS paths under Windows
type: enhancement
versions: Python 3.10, 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

[issue43394] Compiler warnings on master (-Wstrict-prototypes)

[Brandt Bucher]

Change by Brandt Bucher :


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

[issue43394] Compiler warnings on master (-Wstrict-prototypes)

[Brandt Bucher]

Brandt Bucher  added the comment:


New changeset c61ec7e6b892313cd3ecbaf02227bacb9d5ddaa2 by Brandt Bucher in 
branch 'master':
bpo-43394: Fix -Wstrict-prototypes warnings (GH-24737)
https://github.com/python/cpython/commit/c61ec7e6b892313cd3ecbaf02227bacb9d5ddaa2


--

___
Python tracker 

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

[issue43344] RotatingFileHandler breaks file type associations

[Vinay Sajip]

Change by Vinay Sajip :


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

[issue43060] Convert _decimal C API from pointer array to struct

[hai shi]

hai shi  added the comment:

> True. Is there many external users of this API? I could not find any relevant 
> examples using searchcode.com.

Hm, many teams don't open their code, so we get check all user cases by 
searchcode web. So I have no any better sugesstion about it :(

--

___
Python tracker 

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

[issue43319] A possible misleading expression in the Virtual Environment Tutorial

[cmhzc]

Change by cmhzc :


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

___
Python tracker 

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

[issue43271] AMD64 Windows10 3.x crash with Windows fatal exception: stack overflow

[Guido van Rossum]

Guido van Rossum  added the comment:

Thanks for all your research and the PR!

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

[issue43271] AMD64 Windows10 3.x crash with Windows fatal exception: stack overflow

[David Bolen]

David Bolen  added the comment:

The win10 buildbot is green again, so I think this can be closed.

--

___
Python tracker 

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

[issue43271] AMD64 Windows10 3.x crash with Windows fatal exception: stack overflow

[Guido van Rossum]

Guido van Rossum  added the comment:


New changeset 131d5516409791b170b09a6ef8ed8463c9b09015 by db3l in branch 
'master':
bpo-43271: Re-enable ceval.c optimizations for Windows debug builds (GH-24739)
https://github.com/python/cpython/commit/131d5516409791b170b09a6ef8ed8463c9b09015


--

___
Python tracker 

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

[issue43379] Pasting multiple lines in the REPL is broken since 3.9

[Ned Deily]

Ned Deily  added the comment:

Sorry, I cannot reproduce that behavior. The output you show isn't what I would 
expect, in any case.

$ python3.8
Python 3.8.7 (v3.8.7:6503f05dd5, Dec 21 2020, 12:45:15)
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> def f():
... print("hello world")
...
>>> ^D
$ python3.9
Python 3.9.1 (v3.9.1:1e5d33e9b9, Dec  7 2020, 12:44:01)
[Clang 12.0.0 (clang-1200.0.32.27)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> def f():
... print("hello world")
...
>>> ^D

Note the missing '...' continuation prompts.  So can you verify that the text 
when you paste it includes just a standard linefeed (LF) control character as 
the end-of-line delimiter?  Other possible differences might be whether the 
python in use was linked with the BSD libedit library or with GNU readline but 
that shouldn't make a difference unless you have some non-default options in 
their configuration files.  You can check which one is in use with this:

$ python3.8 -c "import readline;print(readline.__doc__)"
Importing this module enables command line editing using GNU readline.
$ python3.9 -c "import readline;print(readline.__doc__)"
Importing this module enables command line editing using libedit readline.

If all else fails, from where did you obtain the pythons that you are using?  
And in what environment are you running those commands, i.e. the macOS 
Terminal.app?

--
nosy: +ned.deily

___
Python tracker 

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

[issue36067] subprocess terminate() "invalid handle" error when process is gone

[Eryk Sun]

Eryk Sun  added the comment:

> I don't understand why any patch for CPython is needed at all.

If and operation on self._handle fails as an invalid handle (due to an 
underlying STATUS_INVALID_HANDLE or STATUS_OBJECT_TYPE_MISMATCH), then call 
self._handle.Detach() and re-raise the exception.

It wouldn't hurt to also address the case in which coincidentally the handle 
value currently references another process. When the process is spawned, save 
the (process_id, creation_time) via GetProcessId() and GetProcessTimes(). 
Implement a function that validates these values before calling 
WaitForSingleObject(), GetExitCodeProcess(), or TerminateProcess(). If 
validation fails, call self._handle.Detach() and raise OSError.

--
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
stage: needs patch -> 
type: behavior -> enhancement
versions: +Python 3.10, Python 3.9 -Python 2.7, Python 3.6, Python 3.7

___
Python tracker 

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

[issue43370] thread_time not available on python.org OS X builds

[Ned Deily]

Ned Deily  added the comment:

The reason time.thread_time() and several other functions in other modules that 
all depend on features in newer versions of macOS were not available in 
python.org macOS binaries because the installers are meant to support a range 
of operating system releases (rather than just one operating system version as 
with most other distributors) and, up until recently, the only supported way to 
do that was to build the binaries on the oldest supported system. Thus most 
python.org installers in recent years were built on macOS 10.9 where 
time.thread_time() does not exist. As of Python 3.9.1, with the addition of 
support for macOS 11 and Apple Silicon Macs, support for "weak-linking" was 
also added meaning that it is now possible to build Python 3.9.1+ on, say, 
macOS 11 and have it work without crashing on older systems. Currently, we only 
test back as far as 10.9. This feature is in the 10.9+ "universal2" variants 
available for 3.9.1+ releases and for 3.10 pre-releases.

https://docs.python.org/3/whatsnew/3.9.html#notable-changes-in-python-3-9-1

--
nosy: +ned.deily
resolution:  -> out of date
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

[issue43393] Older Python builds are missing a required file on Big Sur

[Ned Deily]

Ned Deily  added the comment:

In summary, the Python binaries provided by python.org macOS installers for 
already end-of-life versions of Python, like 3.5 and earlier 3.x versions, do 
not run on macOS 11 Big Sur and attempting to build these end-of-life versions 
from source will still not produce a fully-functional Python on macOS 11.

For others reading this, per PEP 478, Python 3.5.4 was the last "bugfix" 
release of 3.5 back in August 2017 and, per long-standing release policy, 
binary installers for Windows and macOS are no longer manufactured once a 
version transitions from its "bugfix" to its "security-fix-only" phase. 
Further, Python 3.5 reached "end-of-life" in September 2020, five years after 
its initial release. So, technically, Python 3.5 is totally unsupported by the 
CPython project.

That said, I did take a quick look at this. A web search found a number of 
other similar reports dating back to the initial release of Big Sur last year. 
The error message is definitely not very helpful (the CoreFoundation framework 
remains an essential piece of macOS) and I still have not seen a total 
explanation of what is going on but I'm 99% sure that the problem is that 
python.org macOS installers for Python 3.5 were built for macOS 10.6+ and it is 
likely that there is some old cruft in the macOS CoreFoundation framework that 
Apple decided it no longer wanted to support as of macOS 11 (Apple did a lot of 
"housecleaning" in and leading up to Big Sur, one reason for the numbering 
change from 10.x to 11) and likely bumped a minimum supported version of 
CoreFoundation thus preventing executables that dynamically link to the older 
version to fail on launch, as in this case.

Note that the most recent python.org macOS installers for releases since 3.5 
(including the final bugfix/binary releases of 3.7.x, 3.6.x, and 2.7.x) were 
built for at least macOS 10.9+ and do not exhibit this problem on macOS 11 Big 
Sur. So it's only an issue for 3.5 and earlier 3.x versions of the python.org 
installers, all of which have reached end-of-life.

I'm not aware of any way practical way to workaround this problem and make 
those installer binaries load on Big Sur. Clearly, the best longer-term 
solution is to upgrade to a supported version (like 3.9.x).  But possible 
workarounds:
1. If 3.5.x is absolutely needed, there are third-party distributors that 
continue to support older versions of Python. In particular, the MacPorts 
project provides pre-built binaries of Python 3.5 (and other releases) that run 
on macOS 11 (and for older releases of macOS, too).
2. If the python.org 3.5 is absolutely needed, don't upgrade to Big Sur or run 
MacOS 10.15 (or earlier) in a virtual machine.
3. Build from source on Big Sur.

But keep in mind that, with any of those workarounds, there still is the 
fundamental issue that there were a number of changes in Big Sur that affect 
Python; there are build changes needed and, even when those are overcome, some 
things just don't work correctly on Big Sur without fixes; distutils and ctypes 
find_library of a system library (see Issue41116), come to mind. At the moment, 
only Python 3.9.1 and later are fully supported on Big Sur.

Sorry I don't have a more positive answer.

--
resolution:  -> out of date
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

[issue43271] AMD64 Windows10 3.x crash with Windows fatal exception: stack overflow

[David Bolen]

Change by David Bolen :


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

___
Python tracker 

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

[issue42202] Optimize function annotation

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:


New changeset 8747c1f233fc1a3dd5ee3d8e163317f28b4d7568 by Pablo Galindo in 
branch 'master':
Improve the description of the improvements in bpo-42202 (GH-24738)
https://github.com/python/cpython/commit/8747c1f233fc1a3dd5ee3d8e163317f28b4d7568


--

___
Python tracker 

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

[issue42202] Optimize function annotation

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
nosy: +pablogsal
nosy_count: 7.0 -> 8.0
pull_requests: +23509
pull_request: https://github.com/python/cpython/pull/24738

___
Python tracker 

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

[issue42128] Structural Pattern Matching (PEP 634)

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:


New changeset 0632b1012d4dfa81ffef0d686a4710f6134f77a8 by Pablo Galindo in 
branch 'master':
bpo-42128: Add __match_args__ to structseq-based classes (GH-24732)
https://github.com/python/cpython/commit/0632b1012d4dfa81ffef0d686a4710f6134f77a8


--

___
Python tracker 

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

[issue43376] Add PyComplex_FromString

[Brandt Bucher]

Brandt Bucher  added the comment:

Hm, I didn't realize until now that PyFloat_FromString parses a Python string, 
while PyLong_FromString parses a C string (with very different signatures). 
That's a bit annoying. 

Regardless, I misunderstood the original issue: in this particular case we are 
converting *Python* strings, so just doing the equivalent of a "complex(s)" 
call is fine.

--
resolution:  -> rejected
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

[issue43394] Compiler warnings on master (-Wstrict-prototypes)

[Brandt Bucher]

Change by Brandt Bucher :


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

___
Python tracker 

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

[issue43394] Compiler warnings on master (-Wstrict-prototypes)

[Brandt Bucher]

New submission from Brandt Bucher :

We're getting "function declaration isn’t a prototype [-Wstrict-prototypes]" 
warnings in Modules/_zoneinfo.c and Modules/_xxtestfuzz/fuzzer.c.

I'll have a patch up momentarily.

--
assignee: brandtbucher
components: Build
messages: 388064
nosy: brandtbucher
priority: normal
severity: normal
status: open
title: Compiler warnings on master (-Wstrict-prototypes)
type: compile error
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

[issue43393] Older Python builds are missing a required file on Big Sur

[Kamil Turek]

Change by Kamil Turek :


--
nosy: +kamilturek

___
Python tracker 

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

[issue43391] The comments have invalid license information (broken Python 2.4 URL for Python 3)

[Kamil Turek]

Change by Kamil Turek :


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

___
Python tracker 

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

[issue43162] Enum regression: AttributeError when accessing class variables on instances

[Ethan Furman]

Ethan Furman  added the comment:

You're welcome.  Thank you for pushing the issue!  :-)

--

___
Python tracker 

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

[issue43393] Older Python builds are missing a required file on Big Sur

[Raymond Hettinger]

New submission from Raymond Hettinger :

When I upgraded to Big Sur, all my older builds stopped working.

Do we have any known workarounds or can we publish updated builds that work?

Like a lot of consultants, I still have to help clients maintain older code.  
Having a standard working build is essential.


$ python3.5
dyld: Library not loaded: 
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
  Referenced from: 
/Library/Frameworks/Python.framework/Versions/3.5/Resources/Python.app/Contents/MacOS/Python
  Reason: image not found
Abort trap: 6

--
components: macOS
messages: 388062
nosy: ned.deily, rhettinger, ronaldoussoren
priority: normal
severity: normal
status: open
title: Older Python builds are missing a required file on Big Sur
type: crash

___
Python tracker 

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

[issue43391] The comments have invalid license information (broken Python 2.4 URL for Python 3)

[Kamil Turek]

Change by Kamil Turek :


--
nosy: +kamilturek

___
Python tracker 

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

[issue43340] json.load() can raise UnicodeDecodeError, but this is not documented

[Kamil Turek]

Change by Kamil Turek :


--
nosy: +kamilturek

___
Python tracker 

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

[issue43389] Cancellation ignored by asyncio.wait_for can hang application

[nmatravolgyi]

nmatravolgyi  added the comment:

One more thing. I've figured out that I can fix the cancellation around the 
asyncio.wait_for() with asyncio.shield() like:

try:
await asyncio.shield(wf := 
asyncio.ensure_future(asyncio.wait_for(self.event.wait(), timeout=60.0)))
except asyncio.CancelledError:
wf.cancel()
result = await asyncio.gather(wf, return_exceptions=True)
# here I know there is a cancellation AND I might have a result as well!
raise

However I don't like the idea of writing all that boilerplate for every 
wait_for usage. I still might be overlooking something, but at least I have 
adequate workarounds.

I'm curious what the consensus will be on this issue. I'm certain it should be 
documented though. Right now there is no mention of ignoring/eating a 
cancellation.

--

___
Python tracker 

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

[issue43371] Mock.assert_has_calls works strange

[Kamil Turek]

Change by Kamil Turek :


--
nosy: +kamilturek

___
Python tracker 

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

[issue43382] github CI blocked by the Ubuntu CI with an SSL error

[Neil Schemenauer]

Neil Schemenauer  added the comment:

It seems it is enough to make a new commit.  The CI seems to re-base and re-run 
the PR.  At least, it worked on two of my PRs.

--

___
Python tracker 

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

[issue43389] Cancellation ignored by asyncio.wait_for can hang application

[nmatravolgyi]

nmatravolgyi  added the comment:

I've quickly wanted to create a suitable solution for myself. I made a small 
library with a asyncio.wait_for()-like function using asyncio.wait(). The 
prototype worked, so I put together a small project. When I ran tox and 
realized that this issue with wait_for is only present on py38 and py39 
(possibly py310). The wait_for does not get stuck with py36, py37 and pypy3.

The repo is a little bare bones, but you can run tox after checkout: 
https://github.com/Traktormaster/wait-for2

Right now the tests are set-up that they expect wait_for to get stuck so only 
py38 and py39 passes.

I'm pretty sure the side-effect of returning the future's result when handling 
cancellation is not desired. However I'm not sure how to handle it correctly. 
The repo holds a demo of what I suggested in the beginning of this thread 
(CancelledWithResultError). It works but it is limited.

--

___
Python tracker 

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

[issue43383] imprecise handling of weakref callbacks

[Tim Peters]

Tim Peters  added the comment:

This won't go anywhere without code (preferably minimal) we can run to 
reproduce the complaint. If there were a "general principle" at work here, 
someone else would surely have reported it over the last few decades ;-)

To the contrary, the common confusion is in the _other_ direction: a weakref 
callback _not_ getting invoked when a programmer thinks it "should be". The 
cause for that is always the same: the weakref object died before the weakly 
referenced object died. That was the primary motivation for introducing 
`weakref.finalize()`.

CPython does not, in general, "batch" (or in any other way delay) object 
destruction. An object is destroyed - immediately - when its refcount falls to 
0. In a technical sense, that's also true in the case of cycles (in which case 
the gc module artificially drives refcounts to 0, based on liveness and 
reachability analysis). With very few exceptions, neither does it hang on to 
"hidden" references. The primary exception to that is in interactive shells, 
where the module-global identifier "_" is typically bound, by magic, to the 
object most recently displayed. In the case of exceptions, it's also possible 
for programs to accidentally hang on to the exception object, from which the 
entire chain of stack frames back to the source of the exception can be reached.

So, based on what you said, this is the best attempt I can make:

import sys, weakref

class C:
def __del__(self):
print("__del__ called")

def wrcb(x):
print("weakref callback called")

c = C()
d = {"x" : weakref.ref(c, wrcb)}
print(sys.getrefcount(d["x"]))

#del d["x"]
del c

which displays:

2
__del__ called
weakref callback called

Note the 2! If the moral equivalent in your code displays a number larger than 
2, then there are more references to the weakref object than just as a dict 
value (that's one; the other reference comes from temporarily incrementing the 
refcount of `d["x"]` to pass it as an argument to `getrefcount()`).

If I uncomment the penultimate line, to destroy the weakref before `c` is 
destroyed, the output changes to:

2
__del__ called

So it's all as expected. Can you change that code to demonstrate your case?

--
nosy: +tim.peters

___
Python tracker 

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

[issue43392] Optimize repeated calls to `__import__()`

[Germán Méndez Bravo]

Change by Germán Méndez Bravo :


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

___
Python tracker 

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

[issue43392] Optimize repeated calls to `__import__()`

[Germán Méndez Bravo]

New submission from Germán Méndez Bravo :

A call to `importlib.__import__()` normally locks the import for the module 
being worked on; this, however has a performance impact for modules that are 
already imported and fully initialized. An example of this are inline 
`__import__()` calls in a hot path that is called repeatedly during the life of 
the process.

Proposal: A two steps check in `importlib._bootstrap._find_and_load()` to avoid 
locking when the module has been already imported and it's ready.

--
components: Library (Lib)
messages: 388057
nosy: Kronuz
priority: normal
severity: normal
status: open
title: Optimize repeated calls to `__import__()`
versions: Python 3.10, 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

[issue40701] tempfile mixes str and bytes in an inconsistent manner

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 4.0 -> 5.0
pull_requests: +23505
pull_request: https://github.com/python/cpython/pull/24734

___
Python tracker 

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

[issue40701] tempfile mixes str and bytes in an inconsistent manner

[Gregory P. Smith]

Gregory P. Smith  added the comment:


New changeset 9c7927400cd8f1d283bf7915b6b33fea81b8655d by Eric L in branch 
'master':
bpo-40701: tempfile mixes str and bytes in an inconsistent manner (GH-20442)
https://github.com/python/cpython/commit/9c7927400cd8f1d283bf7915b6b33fea81b8655d


--

___
Python tracker 

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

[issue43382] github CI blocked by the Ubuntu CI with an SSL error

[Gregory P. Smith]

Gregory P. Smith  added the comment:

we may not need that: Closing and reopening the PR worked.  I suspect the 
github CI "rerun" button was "rerun in the exact same config".

--

___
Python tracker 

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

[issue43391] The comments have invalid license information (broken Python 2.4 URL for Python 3)

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

https://www.python.org/download/releases/2.4/license/ is the correct link for 
the Python 2.4 license.

Note that the contributor agreement allows the PSF to distribute the code under 
a different OSS license and so the current Python license applies for whatever 
version of Python you are using applies.

Peter Astrand still owns the copyright to the code he contributed and so the 
notice may not be removed until everything he contributed is gone. Even then, 
it's a courtesy to the author to leave an authorship notice in the code, since 
the original contribution motivated the API, which mostly still is in place. In 
fact, the contrib agreement probably doesn't even allow removing it at all, 
since it requires:

"""
Contributor shall identify each Contribution by placing the following notice in 
its source code adjacent to Contributor's valid copyright notice: "Licensed to 
PSF under a Contributor Agreement." 
"""

This is the original file which was added:

https://github.com/python/cpython/blob/5b3687df2e6dce2c09662ec9287e8f23075c4f1d/Lib/subprocess.py

At that time we did not have contributor agreements in place, AFAIR. The 
contrib agreement came later and allowed the removal of the verbatim 3-clause 
BSD license.

It's probably good idea to remove the reference to Python 2.4 from the 
doc-string.

--
nosy: +lemburg

___
Python tracker 

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

[issue43162] Enum regression: AttributeError when accessing class variables on instances

[Miro Hrončok]

Miro Hrončok  added the comment:

Thank you, Ethan.

--

___
Python tracker 

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

[issue43382] github CI blocked by the Ubuntu CI with an SSL error

[Gregory P. Smith]

Gregory P. Smith  added the comment:

yeah i figured it might require a rebase.  if anyone has the appropriate git 
command to do that to a branch, creating a 2-4 step CLI playbook for people to 
apply to pending PR branches would be useful.

--

___
Python tracker 

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

[issue43375] memory leak in threading ?

[Igor Mandrichenko]

Igor Mandrichenko  added the comment:

Since Timer thread is never joined, should not it be a daemon ?

--

___
Python tracker 

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

[issue43391] The comments have invalid license information (broken Python 2.4 URL for Python 3)

[Jake Gustafson]

Jake Gustafson  added the comment:

*significantly different even than Python 2.7.16's.

--

___
Python tracker 

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

[issue43391] The comments have invalid license information (broken Python 2.4 URL for Python 3)

[Jake Gustafson]

New submission from Jake Gustafson :

Steps to reproduce the issue:
- Run Python 3.7.3 (or later, possibly) with the following code:

import subprocess
import inspect
with open("subprocess-py3.py", 'w') as outs:
outs.write(inspect.getsource(subprocess).replace("\\n","\n"))

The resulting ./subprocess-py3.py contains the source code for subprocess 
including:

# Copyright (c) 2003-2005 by Peter Astrand 
#
# Licensed to PSF under a Contributor Agreement.
# See http://www.python.org/2.4/license for licensing details.

However, the URL is broken, and whatever code Peter Astrand developed may be 
long gone--I'll leave it up to the devs to determine the correct license, but 
the link is broken and the code is significantly different even than Python 
2.4's.

--
assignee: docs@python
components: Documentation
messages: 388049
nosy: docs@python, poikilos
priority: normal
severity: normal
status: open
title: The comments have invalid license information (broken Python 2.4 URL for 
Python 3)
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

[issue41561] test_ssl fails in Ubuntu 20.04: test_min_max_version_mismatch

[Terry J. Reedy]

Change by Terry J. Reedy :


--
nosy:  -terry.reedy

___
Python tracker 

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

[issue43382] github CI blocked by the Ubuntu CI with an SSL error

[Brandt Bucher]

Brandt Bucher  added the comment:

Closing and reopening may work, or pushing an empty commit. I know that's 
helped appease some GitHub CI weirdness in the past.

--

___
Python tracker 

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

[issue43162] Enum regression: AttributeError when accessing class variables on instances

[Ethan Furman]

Change by Ethan Furman :


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

[issue42128] Structural Pattern Matching (PEP 634)

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
pull_requests: +23504
pull_request: https://github.com/python/cpython/pull/24733

___
Python tracker 

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

[issue43382] github CI blocked by the Ubuntu CI with an SSL error

[Christian Heimes]

Christian Heimes  added the comment:

Yeah, that's the annoying part. Users have to rebase all their PRs in order to 
make CI pass. It's going to be painful. :(

--

___
Python tracker 

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

[issue42128] Structural Pattern Matching (PEP 634)

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

Opened https://github.com/python/cpython/pull/24732

> I'm also not entirely sure how "unnamed fields" work, or what they're used 
> for. Presumably, we'd want to end the __match_args__ tuple upon hitting one 
> of these?

AFAIK, they should be just excluded from __match_args__

--

___
Python tracker 

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

[issue42128] Structural Pattern Matching (PEP 634)

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
pull_requests: +23503
pull_request: https://github.com/python/cpython/pull/24732

___
Python tracker 

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

[issue43382] github CI blocked by the Ubuntu CI with an SSL error

[Ned Deily]

Ned Deily  added the comment:

You may have to refresh the PR so that is uses the latest HEAD that includes 
the config change.

--

___
Python tracker 

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

[issue42128] Structural Pattern Matching (PEP 634)

[Brandt Bucher]

Brandt Bucher  added the comment:

Yeah, probably.

I'm not too familiar with the design of those objects... would it make more 
sense to have the implementation be a single descriptor shared by all derived 
types, or should we precompute the tuple of strings when each new type is 
defined?

I'm also not entirely sure how "unnamed fields" work, or what they're used for. 
Presumably we'd want to end the __match_args__ tuple upon hitting one of these?

--

___
Python tracker 

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

[issue43382] github CI blocked by the Ubuntu CI with an SSL error

[Gregory P. Smith]

Gregory P. Smith  added the comment:

How do I get a CI run on a PR to actually pickup this change?  clicking rerun 
failed.

--

___
Python tracker 

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

[issue43383] imprecise handling of weakref callbacks

[Mark Dickinson]

Mark Dickinson  added the comment:

One more thing: I'm assuming that everything in sight is single-threaded? With 
more than one Python thread (even if that thread is auxiliary to anything 
you're doing - e.g., if you're working at an IPython prompt, there will likely 
be at least a couple of extra Python threads around), there's always the 
exciting possibility that the cyclic garbage collection can end up running on 
an essentially arbitrary Python thread; it would be good to rule that 
possibility out.

--

___
Python tracker 

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

[issue43383] imprecise handling of weakref callbacks

[Mark Dickinson]

Mark Dickinson  added the comment:

Have you tried doing a "gc.get_referrers" on your weakref, to verify that there 
aren't any references that you don't expect to be there?

Another diagnostic would be to run with cyclic garbage collection disabled (via 
gc.disable). If you're seeing different behaviour with gc disabled versus 
enabled, that would at least confirm the presence of reference cycles.

> Are local variables/stack frames cleaned lazily? Is the last accessed
> value of a dictionary cached internally, increasing its reference count?

My knowledge of current Python internals isn't as deep as it used to be, but 
I'd be quite surprised if either of these were true.

--

___
Python tracker 

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

[issue43378] Pattern Matching section in tutorial refers to | as or

[Raymond Hettinger]

Change by Raymond Hettinger :


--
nosy: +Daniel Moisset, brandtbucher, gvanrossum, willingc

___
Python tracker 

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

[issue42128] Structural Pattern Matching (PEP 634)

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Should __match_args__ be added to Objects/structseq.c ?

--
nosy: +rhettinger

___
Python tracker 

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

[issue43383] imprecise handling of weakref callbacks

[Konrad Schwarz]

Konrad Schwarz  added the comment:

> If I understand correctly, the reported bug is that you're seeing a weakref 
> callback being executed
> after the weakref.ref instance it's attached to is deleted. Is that correct?

Exactly.  I del what should be the only reference to the weakref.ref/proxy, 
then del the weakref.ref's referent.
The weakref.ref's callback is executed.

> Do you have a minimal example we can use to reproduce the effect? Without 
> such an example, there's not
> much of a realistic path to moving this forward.

Unfortunately, not at the moment.

> However, my suspicion is that that's not what's actually happening here. I 
> suspect that when you say
> "after the corresponding weak reference has been deleted with del", that the 
> "del" statement you refer
> to is not actually deleting the last reference to the weakref.ref object, so 
> the weakref still exists
> after the "del". One easy way that this could happen is if the weakref is 
> part of a reference cycle
> (and I know from personal experience that it's horribly easy to accidentally 
> *create* reference cycles
> via weakref callbacks, especially if those callbacks refer to instance 
> methods).

I tried to be as punctilious as I could to prevent this sort of thing from 
happening.
The weird thing is that the error does not occur when I single step the code in 
PDB.
It must be something internal to CPython, some sort of optimization.
Are local variables/stack frames cleaned lazily?  Is the last accessed value of 
a
dictionary cached internally, increasing its reference count?

I've worked around the problem by double checking in the callback method that 
it actually should execute;
i.e. in my case, that the object has not been removed (del) from a dictionary 
(which should be the
single reference to the object).

If the problem does indeed lie with CPython, but has too much of a 
performance/maintenance impact,
perhaps a caveat could be added to the documentation to the effect of "The 
lifetime of an object
may be longer than what a programmer expects causing a weakref's callback to be 
invoked at
a surprising time; it is good practice to program the callback defensively."

--

___
Python tracker 

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

[issue42782] shutil.move creates a new directory even on failure

[Senthil Kumaran]

Change by Senthil Kumaran :


--
stage: resolved -> patch review

___
Python tracker 

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

[issue43390] Set the SA_ONSTACK in PyOS_setsig to play well with other VMs like Golang

[Gregory P. Smith]

Change by Gregory P. Smith :


--
type:  -> resource usage

___
Python tracker 

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

[issue43390] Set the SA_ONSTACK in PyOS_setsig to play well with other VMs like Golang

[Gregory P. Smith]

Change by Gregory P. Smith :


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

___
Python tracker 

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

[issue43162] Enum regression: AttributeError when accessing class variables on instances

[Ethan Furman]

Ethan Furman  added the comment:


New changeset 44e580f448016b86807465a186d03d9074e2b589 by Ethan Furman in 
branch 'master':
bpo-43162: [Enum] update docs, renable doc tests (GH-24487)
https://github.com/python/cpython/commit/44e580f448016b86807465a186d03d9074e2b589


--

___
Python tracker 

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

[issue35935] threading.Event().wait() not interruptable with Ctrl-C on Windows

[Eryk Sun]

Eryk Sun  added the comment:

Alexander, I wrote the above sample function to be slotted directly into the 
existing design based on the SIGINT event. I wasn't looking to rewrite 
everything using user-mode APCs and alertable waits. A change like that could 
have ramifications for applications that already use alertable waits, depending 
on how resiliently they're designed.

> Originally, Windows devised an APC mechanism to simulate asynchronous
> delivery of Posix signal to threads. 

IIRC, Iterix (i.e. SUA -- replaced nowadays by WSL) used Asynchronous Procedure 
Calls (APCs) to implement Unix signals. But APCs certainly weren't devised 
solely for the purpose of the providing signals in the POSIX subsystem. They're 
an evolution of Asynchronous System Traps (ASTs) in DEC VMS. (The lead designer 
of NT and most of the development team originally designed and implemented VMS 
at DEC. They began working at Microsoft to design the NT system and OS/2, 
Win32, and POSIX subsystems starting in late 1988.) Kernel-mode and user-mode 
APCs are fundamental and critical to NT (e.g. thread termination uses an APC), 
and particularly the I/O system, which uses a special kernel-mode APC for I/O 
request completion. (An I/O request is often serviced in an arbitrary thread 
context. Buffered I/O completion has to be queued back to the calling thread in 
order to copy from a system buffer to the user buffer.)

> Those APCs are invoked during alertable wait functions. Delivery 
> of an APS also aborts the wait with WAIT_IO_COMPLETION return code.

WAIT_IO_COMPLETION is the same as STATUS_USER_APC, because I/O completion 
routines are queued as user-mode APCs (e.g. by ReadFileEx). Using the name 
"WAIT_IO_COMPLETION" clarifies the intent in this case. In general, I prefer 
"STATUS_USER_APC".

> An APC queue can be processed at any time by calling an alertable 
> wait function with zero timeout, for example SleepEx(0, TRUE).

The user-mode APC queue can also be pumped by calling the NtTestAlert() system 
function. For example:

import ctypes
ntdll = ctypes.WinDLL('ntdll')
kernel32 = ctypes.WinDLL('kernel32', use_last_error=True)

@ctypes.WINFUNCTYPE(None, ctypes.c_void_p)
def apc(p):
print('spam APC')

hthread = ctypes.c_void_p(-2)
kernel32.QueueUserAPC(apc, hthread, None)


>>> ntdll.NtTestAlert(hthread)
spam APC
0

--

___
Python tracker 

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

[issue43390] Set the SA_ONSTACK in PyOS_setsig to play well with other VMs like Golang

[Gregory P. Smith]

New submission from Gregory P. Smith :

PyOS_setsig currently sets the struct sigaction context.sa_flags = 0 before 
calling sigaction.

Other virtual machines such as Golang depend on signals using SA_ONSTACK such 
that signal handlers use a specially allocated stack that runtime sets up for 
reliability reasons as they use tiny stacks on normal threads.

SA_ONSTACK is a no-op flag in the typical case where no sigaltstack() call has 
been made to setup an alternate signal handling stack.  (as in 99.99% of all 
CPython applications)

When a C/C++ extension module is linked with cgo to call into a Golang library, 
doing this increases reliability.

As much as I try to dissuade anyone from creating and relying on hidden 
complexity multi-VM-hybrids in a single process like this, some people do, and 
this one line change helps.

Golang references:
  https://golang.org/pkg/os/signal/#hdr-Go_programs_that_use_cgo_or_SWIG
 and
  https://go-review.googlesource.com/c/go/+/298269/ (which clarifies that 
SA_RESTART is no longer a requirement. Good. Because Python won't get along 
well with that one.)

--
assignee: gregory.p.smith
components: Interpreter Core
messages: 388036
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title: Set the SA_ONSTACK in PyOS_setsig to play well with other VMs like Golang
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

[issue43382] github CI blocked by the Ubuntu CI with an SSL error

[Ned Deily]

Ned Deily  added the comment:

3.7 backport is now merged, too.

--

___
Python tracker 

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

[issue43295] datetime.strptime emits IndexError on parsing 'z' as %z

[miss-islington]

Change by miss-islington :


--
pull_requests: +23501
pull_request: https://github.com/python/cpython/pull/24729

___
Python tracker 

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

[issue43295] datetime.strptime emits IndexError on parsing 'z' as %z

[miss-islington]

Change by miss-islington :


--
pull_requests: +23500
pull_request: https://github.com/python/cpython/pull/24728

___
Python tracker 

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

[issue43295] datetime.strptime emits IndexError on parsing 'z' as %z

[miss-islington]

miss-islington  added the comment:


New changeset 04f6fbb6969e9860783b9ab4dc24b6fe3c6dab8d by Noor Michael in 
branch 'master':
bpo-43295: Fix error handling of datetime.strptime format string '%z' (GH-24627)
https://github.com/python/cpython/commit/04f6fbb6969e9860783b9ab4dc24b6fe3c6dab8d


--
nosy: +miss-islington

___
Python tracker 

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

[issue43355] __future__.annotations breaks inspect.signature()

[Eric V. Smith]

Eric V. Smith  added the comment:

I think this is all about: should inspect.signature() resolve string 
annotations into actual types (via get_type_hints, or whatever)? I don't use 
expect much, so I can't offer an opinion there.

--

___
Python tracker 

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

[issue43389] Cancellation ignored by asyncio.wait_for can hang application

[nmatravolgyi]

New submission from nmatravolgyi :

I have found myself debugging a *very* not intuitive behavior regarding 
asyncio.wait_for that I'd consider a bug/deficiency. The problem very simply 
put: wait_for will return the wrapped future's result even when it is being 
cancelled, ignoring the cancellation as it has never existed.

This will make parallel execution-waits hang forever if some simple conditions 
are met. From the perspective of this snippet every task must exit so it just 
needs to wait. I know cancellation *can* be ignored, but it is discouraged by 
the documentation for this reason exactly.

tasks = [...]
for t in tasks:
t.cancel()
results = await asyncio.gather(*tasks, return_exceptions=True)

I already know that this behavior has been chosen because otherwise the 
returned value would be lost. But for many applications, losing an explicit 
cancellation error/event is just as bad.

The reason why ignoring the cancellation is critical is because the cancelling 
(arbiter) task cannot reliably solve it. In most cases having repeated 
cancellations in a polling wait can solve this, but it is ugly and does not 
work if the original wait_for construct is in a loop and will always ignore the 
cancellation.

The most sensible solution would be to allow the user to handle both the return 
value and the cancellation if they do happen at once. This can be done by 
subclassing the CancelledError as CancelledWithResultError and raising that 
instead. If the user code does not handle that exception specifically then the 
user "chose" to ignore the result. Even if this is not intuitive, it would give 
the user the control over what really is happening. Right now, the user cannot 
prefer to handle the cancellation or both.

Lastly, I may have overlooked something trivial to make this work well. Right 
now I'm considering replacing all of the asyncio.wait_for constructs with 
asyncio.wait constructs. I can fully control all tasks and cancellations with 
that. I've made a simple demonstration of my problem, maybe someone can shed 
some light onto it.

--
components: asyncio
files: aio_wait_for_me.py
messages: 388032
nosy: asvetlov, nmatravolgyi, yselivanov
priority: normal
severity: normal
status: open
title: Cancellation ignored by asyncio.wait_for can hang application
type: behavior
versions: Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49849/aio_wait_for_me.py

___
Python tracker 

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

[issue43382] github CI blocked by the Ubuntu CI with an SSL error

[Brandt Bucher]

Brandt Bucher  added the comment:

@ned.deily, I think the 3.7 backport needs RM approval (or something?):

https://github.com/python/cpython/pull/24716

The others branches are fine now... thanks, Christian!

--

___
Python tracker 

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

[issue39199] Improve the AST documentation

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
pull_requests: +23499
pull_request: https://github.com/python/cpython/pull/24727

___
Python tracker 

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

[issue43383] imprecise handling of weakref callbacks

[Mark Dickinson]

Mark Dickinson  added the comment:

If I understand correctly, the reported bug is that you're seeing a weakref 
callback being executed after the weakref.ref instance it's attached to is 
deleted. Is that correct?

Do you have a minimal example we can use to reproduce the effect? Without such 
an example, there's not much of a realistic path to moving this forward.

Without the code: I can't see a plausible mechanism by which the callback could 
execute after the weakref.ref has ceased to exist.

However, my suspicion is that that's not what's actually happening here. I 
suspect that when you say "after the corresponding weak reference has been 
deleted with del", that the "del" statement you refer to is not actually 
deleting the last reference to the weakref.ref object, so the weakref still 
exists after the "del". One easy way that this could happen is if the weakref 
is part of a reference cycle (and I know from personal experience that it's 
horribly easy to accidentally *create* reference cycles via weakref callbacks, 
especially if those callbacks refer to instance methods).

Furthermore, if the weakref exists as part of a cycle and that cycle is being 
collected by the garbage collector, I could see how the callback could be 
sometimes executed and sometimes not depending on the exact order in which the 
cycle is cleaned up.

--
nosy: +mark.dickinson, pitrou

___
Python tracker 

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

[issue43355] __future__.annotations breaks inspect.signature()

[Eric Engestrom]

Eric Engestrom  added the comment:

(... and I had the window open for too long and didn't notice Ken's reply 
before mine ^^')

@kj: thanks for the workaround! it's good to be able to change our code and not 
have to depend on a yet-to-be-released patch on each python version :)

That said, typing.get_type_hints() only returns the type hint, whereas our 
current test checks for other things (like the default value) which need to 
match (I think) for cython's use of `__signature__`? (I inherited all this 
code, so I'm not familiar with it and its history, and I'm beginning to 
question this test's necessity.)

--

___
Python tracker 

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

[issue35935] threading.Event().wait() not interruptable with Ctrl-C on Windows

[Alexander Grigoriev]

Alexander Grigoriev  added the comment:

@ericsun:

Windows calls the console event handler in a separate thread. The console event 
handler receives CTRL_C_EVENT, CTRL_BREAK_EVENT, console close, logoff, system 
shutdown events.

Originally, Windows devised an APC mechanism to simulate asynchronous delivery 
of Posix signal to threads. Those APCs are invoked during alertable wait 
functions. Delivery of an APS also aborts the wait with WAIT_IO_COMPLETION 
return code.

An APC can be queued by QueueUserAPC function.

An APC queue can be processed at any time by calling an alertable wait function 
with zero timeout, for example SleepEx(0, TRUE).

If you need an APC to break wait for asynchronous input (like console or serial 
port), use overlapped I/O with GetOverlappedResultEx function. To cancel the 
I/O request, use CancelIo function on the thread which issued the request. Note 
that you still need to wait for the cancelled request to complete the 
cancellation with GetOverlappedResult.

--
nosy: +alegrigoriev

___
Python tracker 

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

[issue43382] github CI blocked by the Ubuntu CI with an SSL error

[Paul Ganssle]

Change by Paul Ganssle :


--
nosy: +p-ganssle

___
Python tracker 

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

[issue43388] shutil._fastcopy_sendfile() makes wrong (?) assumption about sendfile() return value

[Lorenz Hüdepohl]

New submission from Lorenz Hüdepohl :

Since version 3.8, the shutil.copyfile() function tries to make use of 
os.sendfile(). Currently, this is done in a loop that aborts as soon as 
sendfile() returns 0, as it is assumed that this signifies the end of the file.

The problem: the return value of sendfile() is simply the amount of bytes that 
could be successfully copied in that one syscall, with no guarantee that a 
return value of 0 only happens when there is truly no data left to copy. Some 
other urgent task could have interrupted the kernel before any data was copied. 
At least, I could not find documentation to the contrary.

(Note: This might or might not be actual behavior of current Linux kernels 
today, but the spec of sendfile() certainly allows this)


In any case, in that same routine the size of the source file is anyway 
requested in an os.fstat() call, one could thus restructure the loop like this, 
for example:


filesize = os.fstat(infd).st_size
offset = 0
while offset < filesize:
   sent = os.sendfile(outfd, infd, offset, blocksize)
   offset += sent

(Error handling etc. left out for clarity, just to point out the new structure)

This would also optimize the case of an empty input file, in that case the loop 
is never entered and no os.sendfile() call is issued, at all.

In the normal case, it would also save the unnecessary last os.sendfile() call, 
when 'offset' has already grown to 'filesize'. (This was the actual reason for 
me to look into this in the first place, a filesystem bug where sendfile() 
called with an offset set to the file's size returns "EAGAIN" in certain cases. 
But this is another topic entirely and has nothing to do with Python, of 
course.)


Note that in Modules/posixmodule.c os_sendfile_impl() there is also another 
loop around individual actual sendfile() system call, but a return value of 0 
there would also exit that loop and be passed up:

do {
Py_BEGIN_ALLOW_THREADS
#ifdef __APPLE__
ret = sendfile(in_fd, out_fd, offset, , , flags);
#else
ret = sendfile(in_fd, out_fd, offset, count, , , flags);
#endif
Py_END_ALLOW_THREADS
} while (ret < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals()));


Kind regards,
  Lorenz

--
components: Library (Lib)
messages: 388027
nosy: lhuedepohl
priority: normal
severity: normal
status: open
title: shutil._fastcopy_sendfile() makes wrong (?) assumption about sendfile() 
return value
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

[issue42782] shutil.move creates a new directory even on failure

[Senthil Kumaran]

Change by Senthil Kumaran :


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

[issue42782] shutil.move creates a new directory even on failure

[Senthil Kumaran]

Senthil Kumaran  added the comment:


New changeset bf566847f5a97e6ce391f8fb94185ee756cb94a2 by Senthil Kumaran in 
branch '3.9':
[3.9] bpo-42782: Fail fast for permission errors in shutil.move() (GH-24001) 
(#24725)
https://github.com/python/cpython/commit/bf566847f5a97e6ce391f8fb94185ee756cb94a2


--

___
Python tracker 

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

[issue43355] __future__.annotations breaks inspect.signature()

[Eric Engestrom]

Eric Engestrom  added the comment:

Sorry, I just realized you asked for the "success" value as well.

For python 3.7-3.9 without the `import annotations`, and for python 3.10, the 
type annotation is a class, ie. ``.

--

___
Python tracker 

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

[issue42782] shutil.move creates a new directory even on failure

[miss-islington]

miss-islington  added the comment:


New changeset 59e857650cf49a5e28cb82acc2641b1b53efeeeb by Miss Islington (bot) 
in branch '3.8':
bpo-42782: Fail fast for permission errors in shutil.move() (GH-24001)
https://github.com/python/cpython/commit/59e857650cf49a5e28cb82acc2641b1b53efeeeb


--

___
Python tracker 

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

[issue42782] shutil.move creates a new directory even on failure

[Senthil Kumaran]

Change by Senthil Kumaran :


--
pull_requests: +23498
pull_request: https://github.com/python/cpython/pull/24725

___
Python tracker 

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

[issue42782] shutil.move creates a new directory even on failure

[miss-islington]

Change by miss-islington :


--
pull_requests: +23497
pull_request: https://github.com/python/cpython/pull/24724

___
Python tracker 

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

[issue43355] __future__.annotations breaks inspect.signature()

[Ken Jin]

Ken Jin  added the comment:

@eric.smith, here's a summarized version. I hope it helps:

def foo(x: str) -> str: ...

In Python 3.7 - 3.9 with from __future__ import annotations, inspect.signature 
sees foo's parameter as:



Without the future import (and also in Python 3.10):



The reason for the difference in 3.10 (IIRC) is that inspect.signature auto 
converts all strings to typing.ForwardRef internally and then resolves them. 
This is a result of PEP 563 becoming default (also mentioned here 
https://docs.python.org/3.10/whatsnew/3.10.html#pep-563-postponed-evaluation-of-annotations-becomes-default
 )

Prior to 3.10, the future import treats function annotations as strings and 
inspect.signature _doesn't_ convert them. I don't know of this is a bug or 
intentional. Especially considering what PEP 563 has to say: 
https://www.python.org/dev/peps/pep-0563/#resolving-type-hints-at-runtime

@1ace, a possible workaround if you want full compatibility regardless of the 
future import is to use typing.get_type_hints:

(The result doesn't change even with from __future__ import annotations. This 
also works from 3.7-3.10)
>>> from typing import get_type_hints
>>> get_type_hints(foo)
{'x': , 'return': }

--
nosy: +kj

___
Python tracker 

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

[issue43369] [sqlite3] Handle out-of-memory errors in sqlite3_column_*()

[Erlend Egeberg Aasland]

Erlend Egeberg Aasland  added the comment:

Quoting from the SQLite docs:
"As long as the input parameters are correct, these routines will only fail if 
an out-of-memory error occurs during a format conversion"

--

___
Python tracker 

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

[issue43369] [sqlite3] Handle out-of-memory errors in sqlite3_column_*()

[Erlend Egeberg Aasland]

Change by Erlend Egeberg Aasland :


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

___
Python tracker 

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

[issue43368] Empty bytestrings are not longer returned on SQLite.

[Berker Peksag]

Change by Berker Peksag :


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

[issue43368] Empty bytestrings are not longer returned on SQLite.

[Berker Peksag]

Berker Peksag  added the comment:


New changeset 3b4b2cf418707c79f96689e401e3c703c0fdd4d2 by Mariusz Felisiak in 
branch 'master':
bpo-43368: Fix fetching empty bytes in sqlite3 (GH-24706)
https://github.com/python/cpython/commit/3b4b2cf418707c79f96689e401e3c703c0fdd4d2


--

___
Python tracker 

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

[issue41561] test_ssl fails in Ubuntu 20.04: test_min_max_version_mismatch

[Christian Heimes]

Christian Heimes  added the comment:

Downstream has asked me to file a separate bug for internal error during 
handshake. The problem is tracked at 
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1917625 .

--

___
Python tracker 

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

[issue43382] github CI blocked by the Ubuntu CI with an SSL error

[Christian Heimes]

Christian Heimes  added the comment:

Downstream has asked me to file a separate bug for internal error during 
handshake. The problem is tracked at 
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1917625 .

--

___
Python tracker 

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

[issue43387] Enable pydoc to run as background job

[digitaldragon]

Change by digitaldragon :


--
versions: +Python 3.10, Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

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

[issue43075] ReDoS in urllib.request

[Tal Einat]

Change by Tal Einat :


--
keywords: +newcomer friendly

___
Python tracker 

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

[issue43355] __future__.annotations breaks inspect.signature()

[Eric Engestrom]

Eric Engestrom  added the comment:

Sure thing.

Putting the reproducing code in `test_foo.py` and running `docker run --rm -it 
-v $PWD:/code python sh -c 'pip install pytest && pytest -vvv 
/code/test_foo.py'` yields:

```
Collecting pytest
  Downloading pytest-6.2.2-py3-none-any.whl (280 kB)
 || 280 kB 516 kB/s
Collecting toml
  Downloading toml-0.10.2-py2.py3-none-any.whl (16 kB)
Collecting py>=1.8.2
  Downloading py-1.10.0-py2.py3-none-any.whl (97 kB)
 || 97 kB 1.6 MB/s
Collecting attrs>=19.2.0
  Downloading attrs-20.3.0-py2.py3-none-any.whl (49 kB)
 || 49 kB 1.8 MB/s
Collecting iniconfig
  Downloading iniconfig-1.1.1-py2.py3-none-any.whl (5.0 kB)
Collecting packaging
  Downloading packaging-20.9-py2.py3-none-any.whl (40 kB)
 || 40 kB 833 kB/s
Collecting pluggy<1.0.0a1,>=0.12
  Downloading pluggy-0.13.1-py2.py3-none-any.whl (18 kB)
Collecting pyparsing>=2.0.2
  Downloading pyparsing-2.4.7-py2.py3-none-any.whl (67 kB)
 || 67 kB 1.5 MB/s
Installing collected packages: pyparsing, toml, py, pluggy, packaging, 
iniconfig, attrs, pytest
Successfully installed attrs-20.3.0 iniconfig-1.1.1 packaging-20.9 
pluggy-0.13.1 py-1.10.0 pyparsing-2.4.7 pytest-6.2.2 toml-0.10.2
= test session starts ==
platform linux -- Python 3.9.2, pytest-6.2.2, py-1.10.0, pluggy-0.13.1 -- 
/usr/local/bin/python
cachedir: .pytest_cache
rootdir: /code
collected 1 item

code/test_foo.py::test_foo FAILED[100%]

=== FAILURES ===
___ test_foo ___

def test_foo():
expected = (
Parameter("x", Parameter.POSITIONAL_OR_KEYWORD, annotation=str),
)

actual = tuple(signature(foo).parameters.values())

>   assert expected == actual
E   assert (,) == (,)
E At index 0 diff:  != 
E Full diff:
E - (,)
E ? -   -
E + (,)

code/test_foo.py:16: AssertionError
=== short test summary info 
FAILED code/test_foo.py::test_foo - assert (,) == (

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

[issue43387] Enable pydoc to run as background job

[digitaldragon]

New submission from digitaldragon :

The pydoc tool can serve a website for browsing the docs interactively with the 
-p or -b option. While serving, it enters a simple command line interface:
Server commands: [b]rowser, [q]uit
server> 

Because it is reading from stdin, it is not possible to straightforwardly run 
the progress in the background of a linux shell. Normally, this is achieved by 
appending a & to the command, starting it in the background, or using the 
shell's job control features to put it in the background after starting 
normally: Usually Ctrl-Z and issuing the command 'bg'.

In both cases, any attempt to read from stdin causes a SIGTTIN signal, 
suspending the process if not caught. The webserver then cannot process any 
requests.

I reproduced the behavior in python versions 3.5, 3.7, 3.8 and 3.9. In 2.7, no 
interactive interface is present.

Possible fixes:
- remove the interactive command line altogether (it does not offer more 
functionality than the -b flag, and the shell's handling of Ctrl-C, which sends 
a SIGINT anyway)
- catch SIGTTIN (handles a subsequent sending-to-background)
- detecting if started in background (https://stackoverflow.com/a/24862213, 
can't handle subsequent sending-to-background)

--
components: Library (Lib)
messages: 388017
nosy: digitaldragon
priority: normal
severity: normal
status: open
title: Enable pydoc to run as background job
type: behavior
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

[issue43382] github CI blocked by the Ubuntu CI with an SSL error

[Ivan Marton]

Change by Ivan Marton :


--
nosy: +martonivan

___
Python tracker 

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

[issue43386] test_ctypes hangs inside Portage build env since 'subprocess: Use vfork() instead of fork() [...]'

[Michał Górny]

Michał Górny  added the comment:

Nevermind, I've been testing wrong and this is most likely our fault.  I'm 
sorry about the noise.  I am going to investigate further and reopen if it 
turns out the problem's on CPython end.

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

[issue43376] Add PyComplex_FromString

[Mark Dickinson]

Mark Dickinson  added the comment:

I'd imagine "PyComplex_FromString" would be of limited utility in parsing 
complex data produced by something other than Python, because of Python's 
quirks with "j" rather than "i". But I guess you're talking about a case where 
the creation of the text file involved using the repr or str of Python complex 
values?

But I don't see any reason in principle why it shouldn't/couldn't be added.

--
nosy: +mark.dickinson

___
Python tracker 

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

[issue43386] test_ctypes hangs inside Portage build env since 'subprocess: Use vfork() instead of fork() [...]'

[Michał Górny]

New submission from Michał Górny :

So I've finally found time to bisect this.

Long story short, test_ctypes started hanging on Gentoo package builds since 
3.10.0a2.  Previously, the test took less than a second.  Now, it just keeps 
running for minutes until I kill it.

The weird thing is that I can't reproduce it when running it manually.  I've 
tried hard to rebuild Portage-like environment to make it hang, to no avail.

I've finally gotten around to bisecting it, and established that the problem is 
caused by the following change:

```
commit 976da903a746a5455998e9ca45fbc4d3ad3479d8
Author: Alexey Izbyshev 
Date:   2020-10-24 02:47:01 +0200

bpo-35823: subprocess: Use vfork() instead of fork() on Linux when safe 
(GH-11671)
[...]
```

After running the test with a timeout, I get the following backtrace:

```
test_issue_8959_a (ctypes.test.test_callbacks.SampleCallbacksTestCase) ... 
Timeout (0:00:30)!
Thread 0x7f72f2507740 (most recent call first):
  File 
"/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/subprocess.py",
 line 1773 in _execute_child
  File 
"/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/subprocess.py",
 line 962 in __init__
  File 
"/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/ctypes/util.py",
 line 289 in _findSoname_ldconfig
  File 
"/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/ctypes/util.py",
 line 329 in find_library
  File 
"/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/ctypes/test/test_callbacks.py",
 line 183 in test_issue_8959_a
  File 
"/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/unittest/case.py",
 line 549 in _callTestMethod
  File 
"/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/unittest/case.py",
 line 592 in run
  File 
"/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/unittest/case.py",
 line 652 in __call__
  File 
"/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/unittest/suite.py",
 line 122 in run
  File 
"/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/unittest/suite.py",
 line 84 in __call__
  File 
"/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/unittest/suite.py",
 line 122 in run
  File 
"/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/unittest/suite.py",
 line 84 in __call__
  File 
"/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/unittest/suite.py",
 line 122 in run
  File 
"/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/unittest/suite.py",
 line 84 in __call__
  File 
"/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/unittest/suite.py",
 line 122 in run
  File 
"/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/unittest/suite.py",
 line 84 in __call__
  File 
"/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/unittest/suite.py",
 line 122 in run
  File 
"/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/unittest/suite.py",
 line 84 in __call__
  File 
"/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/unittest/runner.py",
 line 176 in run
  File 
"/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/test/support/__init__.py",
 line 959 in _run_suite
  File 
"/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/test/support/__init__.py",
 line 1082 in run_unittest
  File 
"/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/test/libregrtest/runtest.py",
 line 211 in _test_module
  File 
"/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/test/libregrtest/runtest.py",
 line 236 in _runtest_inner2
  File 
"/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/test/libregrtest/runtest.py",
 line 272 in _runtest_inner
  File 
"/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/test/libregrtest/runtest.py",
 line 155 in _runtest
  File 
"/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/test/libregrtest/runtest.py",
 line 195 in runtest
  File 
"/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/test/libregrtest/main.py",
 line 319 in rerun_failed_tests
  File 
"/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/test/libregrtest/main.py",
 line 696 in _main
  File 
"/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/test/libregrtest/main.py",
 line 639 in main
  File 
"/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/test/libregrtest/main.py",
 line 717 in main
  File 
"/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/test/__main__.py",
 line 2 in 
  File 
"/var/tmp/portage/dev-lang/python-3.10.0_alpha6/work/Python-3.10.0a6/Lib/runpy.py",
 line 87 in 

[issue43385] heapq fails to sort tuples by datetime correctly

[Steven D'Aprano]

Steven D'Aprano  added the comment:

Heaps are not sorted lists! It is true that a sorted list is a heap, but heaps 
are not necessarily sorted.

Here is another heap which is not sorted:

>>> L = []
>>> for n in (9, 7, 8, 11, 4):
... heapq.heappush(L, n)
... 
>>> L
[4, 7, 8, 11, 9]


https://en.wikipedia.org/wiki/Heap_(data_structure)


Also:

>>> L = [9, 8, 7, 2, 3, 5, 4, 1, 0, 6]
>>> heapq.heapify(L)
>>> L
[0, 1, 4, 2, 3, 5, 7, 8, 9, 6]


If we change the order of the initial values, the heap changes too:


>>> L = [9, 8, 7, 2, 3, 5, 4, 1, 0, 6]
>>> L.reverse()
>>> heapq.heapify(L)
>>> L
[0, 4, 1, 6, 5, 3, 2, 7, 8, 9]

--
nosy: +steven.daprano
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

[issue43385] heapq fails to sort tuples by datetime correctly

[Michał Kozik]

New submission from Michał Kozik :

Tuples (datetime, description) all are sorted by the date except one entry 
(2021-03-09) which is out of order:

Expected order: Actual order:
2021-03-04 Event E  2021-03-04 Event E
2021-03-07 Event B  2021-03-07 Event B
2021-03-08 Event C  2021-03-08 Event C
2021-03-09 Event A  2021-03-11 Event D
2021-03-11 Event D  2021-03-09 Event A

In REPL it can be replicated by pasting the following code:

import heapq
from datetime import datetime

event_a = (datetime.strptime('2021-03-09', '%Y-%m-%d'), "Event A")
event_b = (datetime.strptime('2021-03-07', '%Y-%m-%d'), "Event B")
event_c = (datetime.strptime('2021-03-08', '%Y-%m-%d'), "Event C")
event_d = (datetime.strptime('2021-03-11', '%Y-%m-%d'), "Event D")
event_e = (datetime.strptime('2021-03-04', '%Y-%m-%d'), "Event E")

events = []
heapq.heappush(events, event_a)
heapq.heappush(events, event_b)
heapq.heappush(events, event_c)
heapq.heappush(events, event_d)
heapq.heappush(events, event_e)

expected_list = [event_e, event_b, event_c, event_a, event_d]

assert events == expected_list

--
components: Library (Lib)
files: test_heapq.py
messages: 388012
nosy: mike.koikos
priority: normal
severity: normal
status: open
title: heapq fails to sort tuples by datetime correctly
type: behavior
versions: Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49848/test_heapq.py

___
Python tracker 

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