[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys

[Golubev Alexander]

Golubev Alexander  added the comment:

Any reasons the PR still not merged?

--
nosy: +Fat-Zer

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

[issue46730] Please consider mentioning property without setter when an attribute can't be set

[Alexander]

Alexander  added the comment:

Added the PR. (I have signed the CLA, just haven't got the response yet, 
doesn't affect the discussion I guess)

--

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

[issue46730] Please consider mentioning property without setter when an attribute can't be set

[Alexander]

Change by Alexander :


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

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

[issue46730] Please consider mentioning property without setter when an attribute can't be set

[Alexander]

Alexander  added the comment:

Indeed, the error message does not help to identify the problem. Moreover, it 
collides with similar errors in namedtuple and DynamicClassAttribute which may 
lead to even more confusion.

I made a draft patch that could help with it 
(https://github.com/Alex-Blade/cpython/commit/06df3a72dfe462c8fe4eac60dce0ef059b1738f8),
 but I have a concern related to backwards compatibility (that's why no PR). I 
don't really understand if according to PEP 387 a change in an exception 
message should be considered compatibility breaking?

--
nosy: +Alex-Blade

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

[issue44665] asyncio.create_task() documentation should mention user needs to keep reference to the task

[Alexander Hartl]

Alexander Hartl  added the comment:

I just found this PR when a task of mine spontaneously crashed with a "Task was 
destroyed but it is pending" in the middle of program execution.

I think the warning should be added to `loop.create_task()`, too. Not sure if 
`loop.call_later()` and `loop.call_at()` are also affected?

I think it would be a good idea to add the fire-and-forget example that @bernat 
gave. At the moment, stackoverflow is full of suggestions to just use 
`create_task()` in this case, ignoring the return value. Actually, I think it 
is a true shortcoming that asyncio doesn't provide a fire-and forget 
functionality by itself.

--
nosy: +alexhartl

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

[issue33080] regen-importlib is causing build races against other regen-all targets in Makefile.pre.in

[Alexander Kanavin]

Alexander Kanavin  added the comment:

(removed both the workaround, and regen-all itself)

--

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

[issue33080] regen-importlib is causing build races against other regen-all targets in Makefile.pre.in

[Alexander Kanavin]

Alexander Kanavin  added the comment:

We have long ago updated to a much newer python and removed the workaround, so 
the whatever the issue was, it is completely obsolete. Thanks!

--
resolution:  -> works for me
stage:  -> resolved
status: open -> closed

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

[issue44637] Quoting issue on header Reply-To and other address headers

[Alexander Mohr]

Alexander Mohr  added the comment:

btw my work-around was to set maxheaderlen=sys.maxsize, worked for AWS SES at 
least

--

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

[issue45945] compileall.py throws a traceback when using -j0 and thus 'make install' locks up

[Alexander Kanavin]

Alexander Kanavin  added the comment:

Here's the full log where you can see what happens.

--
Added file: https://bugs.python.org/file50464/log.do_install.1905494

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

[issue45945] compileall.py throws a traceback when using -j0 and thus 'make install' locks up

[Alexander Kanavin]

New submission from Alexander Kanavin :

Hello, Yocto project has had to disable -j0 for compileall, so that it runs 
serially. If it doesn't, then 'make install' locks up sporadically, with 
hanging processes:
```
3837320 ?SN 0:00  \_ make -j 16 -l 52 
STAGING_LIBDIR=/home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-1280438/tmp/work/core2-64-poky-linux/python3/3.10.0-r0/recipe-sysroot/usr/lib
 STAGING_INCDIR=/
 157523 ?SNl0:02  \_ python3.10 -Wi -OO 
/home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-1280438/tmp/work/core2-64-poky-linux/python3/3.10.0-r0/image/usr/lib/python3.10/compileall.py
 -j0 -d /u
 160673 ?SN 0:00  \_ python3.10 -Wi -OO 
/home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-1280438/tmp/work/core2-64-poky-linux/python3/3.10.0-r0/image/usr/lib/python3.10/compileall.py
 -j0 -
 160677 ?SN 0:00  \_ python3.10 -Wi -OO 
/home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-1280438/tmp/work/core2-64-poky-linux/python3/3.10.0-r0/image/usr/lib/python3.10/compileall.py
 -j0 -
 160682 ?SN 0:00  \_ python3.10 -Wi -OO 
/home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-1280438/tmp/work/core2-64-poky-linux/python3/3.10.0-r0/image/usr/lib/python3.10/compileall.py
 -j0 -
 160697 ?SN 0:00  \_ python3.10 -Wi -OO 
/home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-1280438/tmp/work/core2-64-poky-linux/python3/3.10.0-r0/image/usr/lib/python3.10/compileall.py
 -j0 -
 160759 ?SN 0:00  \_ python3.10 -Wi -OO 
/home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-1280438/tmp/work/core2-64-poky-linux/python3/3.10.0-r0/image/usr/lib/python3.10/compileall.py
 -j0 -
 160816 ?SN 0:00  \_ python3.10 -Wi -OO 
/home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-1280438/tmp/work/core2-64-poky-linux/python3/3.10.0-r0/image/usr/lib/python3.10/compileall.py
 -j0 -
...
```

and installation log reveals:
```
poky-linux/python3/3.10.0-r0/image/usr/lib/python3.10/compileall.py \
-j0 -d /usr/lib/python3.10 -f \
-x 'bad_coding|badsyntax|site-packages|lib2to3/tests/data' \

/home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-1280388/tmp/work/core2-64-poky-linux/python3/3.10.0-r0/image/usr/lib/python3.10
Listing 
'/home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-1280388/tmp/work/core2-64-poky-linux/python3/3.10.0-r0/image/usr/lib/python3.10'...
Listing 
'/home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-1280388/tmp/work/core2-64-poky-linux/python3/3.10.0-r0/image/usr/lib/python3.10/asyncio'...
Listing 
'/home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-1280388/tmp/work/core2-64-poky-linux/python3/3.10.0-r0/image/usr/lib/python3.10/collections'...
Listing 
'/home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-1280388/tmp/work/core2-64-poky-linux/python3/3.10.0-r0/image/usr/lib/python3.10/concurrent'...
Listing 
'/home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-1280388/tmp/work/core2-64-poky-linux/python3/3.10.0-r0/image/usr/lib/python3.10/concurrent/futures'...
Listing 
'/home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-1280388/tmp/work/core2-64-poky-linux/python3/3.10.0-r0/image/usr/lib/python3.10/config-3.10-x86_64-linux-gnu'...
Listing 
'/home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-1280388/tmp/work/core2-64-poky-linux/python3/3.10.0-r0/image/usr/lib/python3.10/ctypes'...
Listing 
'/home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-1280388/tmp/work/core2-64-poky-linux/python3/3.10.0-r0/image/usr/lib/python3.10/ctypes/macholib'...
...
Exception in thread Thread-1:
Traceback (most recent call last):
  File 
"/home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-1280388/tmp/work/core2-64-poky-linux/python3/3.10.0-r0/image/usr/lib/python3.10/threading.py",
 line 1009, in _bootstrap_inner
self.run()
  File 
"/home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-1280388/tmp/work/core2-64-poky-linux/python3/3.10.0-r0/image/usr/lib/python3.10/concurrent/futures/process.py",
 line 317, in run
result_item, is_broken, cause = self.wait_result_broken_or_wakeup()
  File 
"/home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-1280388/tmp/work/core2-64-poky-linux/python3/3.10.0-r0/image/usr/lib/python3.10/concurrent/futures/process.py",
 line 376, in wait_result_broken_or_wakeup
worker_sentinels = [p.sentinel for p in self.processes.values()]
  File 
"/home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-1280388/tmp/work/core2-64-poky-linux/python3/3.10.0-r0/image/usr/lib/python3.10/concurrent/futures/process.py",
 line 376, in 
worker_sentinels = [p

[issue45932] EmailMessage incorrectly splits name and address header

[Alexander Mohr]

Change by Alexander Mohr :


--
title: EmailMessage incorrectly splits reply-to header -> EmailMessage 
incorrectly splits name and address header

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

[issue45932] EmailMessage incorrectly splits reply-to header

[Alexander Mohr]

New submission from Alexander Mohr :

If you have a reply-to list that contains a name with a comma it must be 
quoted, however if the line length is just right python with split the name 
incorrectly and not keep the quote.  Note that the CC line keeps the quote in 
the name but the reply-to does not, presumably since the line is slightly 
longer.

example:
from email.message import EmailMessage


def main():
message = EmailMessage()
message['From'] = 'no-re...@farmersbusinessnetwork.com'
message['Reply-To'] = """MEGAN FOOOBAR 
,"KDJEHGI, SCOTT KJUYT" 
"""
message['To'] = """"KDJEHGI, SCOTT KJUYT" """
message['Subject'] = "does not matter"
message['CC'] = """MEGAN FOOOBAR ,"KDJEHGI, 
SCOTT KJUYT" """
message.set_content('foo bar')
print(message.as_string())


if __name__ == '__main__':
main()

--
components: email
messages: 407329
nosy: barry, r.david.murray, thehesiod
priority: normal
severity: normal
status: open
title: EmailMessage incorrectly splits reply-to header
type: behavior
versions: Python 3.8

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

[issue45564] shutil.rmtree and os.walk are implemented using recursion, fail on deep hierarchies

[Alexander Patrakov]

New submission from Alexander Patrakov :

It is possible to create deep directory hierarchies that cannot be removed via 
shutil.rmtree or walked via os.walk, because these functions exceed the 
interpreter recursion limit. This may have security implications for web 
services (e.g. various webdisks) that have to clean up user-created mess or 
walk through it.

[aep@aep-haswell ~]$ mkdir /tmp/badstuff
[aep@aep-haswell ~]$ cd /tmp/badstuff
[aep@aep-haswell badstuff]$ for x in `seq 2048` ; do mkdir $x ; cd $x ; done
[aep@aep-haswell 103]$ cd
[aep@aep-haswell ~]$ python
Python 3.9.7 (default, Oct 10 2021, 15:13:22) 
[GCC 11.1.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import shutil
>>> shutil.rmtree('/tmp/badstuff')
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3.9/shutil.py", line 726, in rmtree
_rmtree_safe_fd(fd, path, onerror)
  File "/usr/lib/python3.9/shutil.py", line 663, in _rmtree_safe_fd
_rmtree_safe_fd(dirfd, fullname, onerror)
  File "/usr/lib/python3.9/shutil.py", line 663, in _rmtree_safe_fd
_rmtree_safe_fd(dirfd, fullname, onerror)
  File "/usr/lib/python3.9/shutil.py", line 663, in _rmtree_safe_fd
_rmtree_safe_fd(dirfd, fullname, onerror)
  [Previous line repeated 992 more times]
  File "/usr/lib/python3.9/shutil.py", line 642, in _rmtree_safe_fd
fullname = os.path.join(path, entry.name)
  File "/usr/lib/python3.9/posixpath.py", line 77, in join
sep = _get_sep(a)
  File "/usr/lib/python3.9/posixpath.py", line 42, in _get_sep
if isinstance(path, bytes):
RecursionError: maximum recursion depth exceeded while calling a Python object
>>> import os
>>> list(os.walk('/tmp/badstuff'))
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3.9/os.py", line 418, in _walk
yield from _walk(new_path, topdown, onerror, followlinks)
  File "/usr/lib/python3.9/os.py", line 418, in _walk
yield from _walk(new_path, topdown, onerror, followlinks)
  File "/usr/lib/python3.9/os.py", line 418, in _walk
yield from _walk(new_path, topdown, onerror, followlinks)
  [Previous line repeated 993 more times]
  File "/usr/lib/python3.9/os.py", line 412, in _walk
new_path = join(top, dirname)
  File "/usr/lib/python3.9/posixpath.py", line 77, in join
sep = _get_sep(a)
  File "/usr/lib/python3.9/posixpath.py", line 42, in _get_sep
if isinstance(path, bytes):
RecursionError: maximum recursion depth exceeded while calling a Python object
>>>

--
components: Library (Lib)
messages: 404687
nosy: Alexander.Patrakov
priority: normal
severity: normal
status: open
title: shutil.rmtree and os.walk are implemented using recursion, fail on deep 
hierarchies
type: crash
versions: Python 3.9

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

[issue45426] PANDAS INSTALLATION PIP FAILED ON WINDOWS 11

[Jimmy Alexander]

Jimmy Alexander  added the comment:

descarga la version 3.10 se supone es estable

pero al momento de instalar PANDAS usando PIP en el CMD de windows 11

FALLA

y empieza a buscar otras vesiones de menores de pandas para intentar instalar 
via pip

pero todas fallan!

--
type:  -> compile error

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

[issue45426] PANDAS INSTALLATION PIP FAILED ON WINDOWS 11

[Jimmy Alexander]

Jimmy Alexander  added the comment:

C:\Users\ufx>pip install pandas
Collecting pandas
  Using cached pandas-1.3.3.tar.gz (4.7 MB)
  Installing build dependencies ... error
  ERROR: Command errored out with exit status 1:
   command: 'C:\Users\ufx\AppData\Local\Programs\Python\Python310\python.exe' 
'C:\Users\ufx\AppData\Local\Temp\pip-standalone-pip-hwkn7bp9\__env_pip__.zip\pip'
 install --ignore-installed --no-user --prefix 
'C:\Users\ufx\AppData\Local\Temp\pip-build-env-q28f4203\overlay' 
--no-warn-script-location --no-binary :none: --only-binary :none: -i 
https://pypi.org/simple -- 'setuptools>=51.0.0' wheel 'Cython>=0.29.21,<3' 
'numpy==1.17.3; python_version=='"'"'3.7'"'"' and 
(platform_machine!='"'"'arm64'"'"' or platform_system!='"'"'Darwin'"'"') and 
platform_machine!='"'"'aarch64'"'"'' 'numpy==1.18.3; 
python_version=='"'"'3.8'"'"' and (platform_machine!='"'"'arm64'"'"' or 
platform_system!='"'"'Darwin'"'"') and platform_machine!='"'"'aarch64'"'"'' 
'numpy==1.19.3; python_version>='"'"'3.9'"'"' and 
(platform_machine!='"'"'arm64'"'"' or platform_system!='"'"'Darwin'"'"') and 
platform_machine!='"'"'aarch64'"'"'' 'numpy==1.19.2; 
python_version=='"'"'3.7'"'"' and platform_machine=='"'"'aarch64'"'"'' 'num
 py==1.19.2; python_version=='"'"'3.8'"'"' and 
platform_machine=='"'"'aarch64'"'"'' 'numpy>=1.20.0; 
python_version=='"'"'3.8'"'"' and platform_machine=='"'"'arm64'"'"' and 
platform_system=='"'"'Darwin'"'"'' 'numpy>=1.20.0; 
python_version=='"'"'3.9'"'"' and platform_machine=='"'"'arm64'"'"' and 
platform_system=='"'"'Darwin'"'"''
   cwd: None
  Complete output (839 lines):
  Ignoring numpy: markers 'python_version == "3.7" and (platform_machine != 
"arm64" or platform_system != "Darwin") and platform_machine != "aarch64"' 
don't match your environment
  Ignoring numpy: markers 'python_version == "3.8" and (platform_machine != 
"arm64" or platform_system != "Darwin") and platform_machine != "aarch64"' 
don't match your environment
  Ignoring numpy: markers 'python_version == "3.7" and platform_machine == 
"aarch64"' don't match your environment
  Ignoring numpy: markers 'python_version == "3.8" and platform_machine == 
"aarch64"' don't match your environment
  Ignoring numpy: markers 'python_version == "3.8" and platform_machine == 
"arm64" and platform_system == "Darwin"' don't match your environment
  Ignoring numpy: markers 'python_version == "3.9" and platform_machine == 
"arm64" and platform_system == "Darwin"' don't match your environment
  Collecting setuptools>=51.0.0
Using cached setuptools-58.2.0-py3-none-any.whl (946 kB)
  Collecting wheel
Using cached wheel-0.37.0-py2.py3-none-any.whl (35 kB)

--

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

[issue45426] PANDAS INSTALLATION PIP FAILED ON WINDOWS 11

[Jimmy Alexander]

New submission from Jimmy Alexander :

Generating code
  Finished generating code
  building 'pandas._libs.parsers' extension
  C:\Program Files (x86)\Microsoft Visual 
Studio\2019\Community\VC\Tools\MSVC\14.28.29910\bin\HostX86\x64\cl.exe /c 
/nologo /Ox /W3 /GL /DNDEBUG /MD -DNPY_NO_DEPRECATED_API=0 -I.\pandas\_libs 
-Ipandas/_libs/src/klib -Ipandas/_libs/src 
-IC:\Users\ufx\AppData\Local\Temp\pip-build-env-e6frjkyc\overlay\Lib\site-packages\numpy\core\include
 -IC:\Users\ufx\AppData\Local\Programs\Python\Python310\include 
-IC:\Users\ufx\AppData\Local\Programs\Python\Python310\Include -IC:\Program 
Files (x86)\Microsoft Visual 
Studio\2019\Community\VC\Tools\MSVC\14.28.29910\include -IC:\Program Files 
(x86)\Windows Kits\NETFXSDK\4.8\include\um -IC:\Program Files (x86)\Windows 
Kits\10\include\10.0.19041.0\ucrt -IC:\Program Files (x86)\Windows 
Kits\10\include\10.0.19041.0\shared -IC:\Program Files (x86)\Windows 
Kits\10\include\10.0.19041.0\um -IC:\Program Files (x86)\Windows 
Kits\10\include\10.0.19041.0\winrt -IC:\Program Files (x86)\Windows 
Kits\10\include\10.0.19041.0\cppwinrt /Tcpandas/_libs/src/parser/io.c /Fo
 build\temp.win-amd64-3.10\Release\pandas/_libs/src/parser/io.obj
  io.c
  pandas/_libs/src/klib\khash.h(705): warning C4090: 'function': different 
'const' qualifiers
  pandas/_libs/src/parser/io.c(139): error C2065: 'ssize_t': undeclared 
identifier
  pandas/_libs/src/parser/io.c(139): error C2146: syntax error: missing ';' 
before identifier 'rv'
  pandas/_libs/src/parser/io.c(139): error C2065: 'rv': undeclared identifier
  pandas/_libs/src/parser/io.c(145): error C2065: 'rv': undeclared identifier
  pandas/_libs/src/parser/io.c(145): warning C4267: 'function': conversion from 
'size_t' to 'unsigned int', possible loss of data
  pandas/_libs/src/parser/io.c(146): error C2065: 'rv': undeclared identifier
  pandas/_libs/src/parser/io.c(157): error C2065: 'rv': undeclared identifier
  pandas/_libs/src/parser/io.c(158): error C2065: 'rv': undeclared identifier
  error: command 'C:\\Program Files (x86)\\Microsoft Visual 
Studio\\2019\\Community\\VC\\Tools\\MSVC\\14.28.29910\\bin\\HostX86\\x64\\cl.exe'
 failed with exit code 2
  
  ERROR: Failed building wheel for pandas
Failed to build pandas
ERROR: Could not build wheels for pandas which use PEP 517 and cannot be 
installed directly

--
components: Windows
messages: 403618
nosy: jdfoxito, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: PANDAS INSTALLATION PIP FAILED ON WINDOWS 11
versions: Python 3.10

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

[issue45223] test_spawn_doesnt_hang (test.test_pty.PtyTest) fails when stdin isn't readable

[Alexander Kanavin]

New submission from Alexander Kanavin :

I am observing the following under yocto's test harness:
==
ERROR: test_spawn_doesnt_hang (test.test_pty.PtyTest)
--
Traceback (most recent call last):
  File "/usr/lib/python3.10/test/test_pty.py", line 316, in 
test_spawn_doesnt_hang
pty.spawn([sys.executable, '-c', 'print("hi there")'])
  File "/usr/lib/python3.10/pty.py", line 181, in spawn
_copy(master_fd, master_read, stdin_read)
  File "/usr/lib/python3.10/pty.py", line 157, in _copy
data = stdin_read(STDIN_FILENO)
  File "/usr/lib/python3.10/pty.py", line 132, in _read
return os.read(fd, 1024)
OSError: [Errno 5] Input/output error


The same tests runs fine in a regular console.

--
messages: 401961
nosy: Alexander Kanavin
priority: normal
severity: normal
status: open
title: test_spawn_doesnt_hang (test.test_pty.PtyTest) fails when stdin isn't 
readable

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

[issue45128] test_multiprocessing fails sporadically on the release artifacts

[Alexander Kanavin]

Alexander Kanavin  added the comment:

I am seeing this one too in my yocto builds of 3.10rc2. What is bizarre is that 
the issue does not occur if the multiprocessing test is run in isolation:

python3 -m test -v test_multiprocessing_fork

but quite reliably does occur (three times in three different spots) if the 
whole test suite is executed:

python3 -m test -v

--
nosy: +Alexander Kanavin

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

[issue44831] Inconsistency between datetime.now() and datetime.fromtimestamp(time.time(), None)

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

Can someone try to replicate this while disabling the C acceleration:

import sys
sys.modules[‘_datetime’] = None

(Before any other imports.)

If anything, this is likely to be a problem with the C implementation.

--

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

[issue15870] PyType_FromSpec should take metaclass as an argument

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

I'll reopen this issue to resume the discussion.  The motivating case - PEP 
3121 refactoring of the ctypes module - is still open.  See bpo-15884.

--
resolution: rejected -> 
stage: resolved -> patch review
status: closed -> open
versions: +Python 3.11 -Python 3.4

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

[issue15787] [meta issue] PEP 3121, 384 Refactoring

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

> The work is now tracked at bpo-1635741.

Which work? bpo-1635741 does not appear to be a meta-issue and in msg381432 it 
loops back here.

--
versions: +Python 3.11 -Python 3.4

___
Python tracker 
<https://bugs.python.org/issue15787>
___
___
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

[Alexander Smirnov]

Alexander Smirnov  added the comment:

the namer was implemented to add "*.log" extension, to avoid broken file 
association problem.

```
log_handler.namer = lambda name: name.replace(".log", "") + ".log"
```

>implemented carefully enough
Could you please share best practices, looks like this documentation is missing.

I created a separate issue related to disregarding of backupCount configuration 
- https://bugs.python.org/issue44753

--

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

[issue44753] backupCount is not respected in TimedRotatingFileHandler when namer is specified

[Alexander Smirnov]

New submission from Alexander Smirnov :

after adding namer callable (like it is described in 
https://bugs.python.org/issue43344) to log handler configuration, it stopped 
removing old files

log_filename = os.path.join(log_dir, "application.log")
log_handler = logging.handlers.TimedRotatingFileHandler(log_filename, 
when='MIDNIGHT', interval=1, backupCount=7)

// after adding this line, old files are not deleted
log_handler.namer = lambda name: name.replace(".log", "") + ".log"

--
components: Library (Lib)
messages: 398326
nosy: alexander.smirnoff
priority: normal
severity: normal
status: open
title: backupCount is not respected in TimedRotatingFileHandler when namer is 
specified
versions: Python 3.8

___
Python tracker 
<https://bugs.python.org/issue44753>
___
___
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

[Alexander Smirnov]

Alexander Smirnov  added the comment:

the problem with namer solution is that it will stop respecting backupCount 
parameter

--
nosy: +alexander.smirnoff

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

[issue44603] REPL: exit when the user types exit instead of asking them to explicitly type exit()

[Taylor Alexander]

Taylor Alexander  added the comment:

Am I correct in thinking that the proposed change only affects the use case 
where a user types exit in to the REPL and hits return? And that any other case 
is unaffected?

I can only imagine that the majority of users who type exit in to the 
interpreter are expecting the REPL to exit.

Stargirl do I recall you mentioning (perhaps on twitter) that there are threads 
online of users expressing frustration with this feature? It would be helpful 
to see what users have said about it.

I would push back against the idea that this is about laziness. It sounds like 
this is about reducing user confusion.

--

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

[issue44603] REPL: exit when the user types exit instead of asking them to explicitly type exit()

[Taylor Alexander]

Taylor Alexander  added the comment:

Makes sense. Thanks for taking a look.

--

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

[issue44603] REPL: exit when the user types exit instead of asking them to explicitly type exit()

[Taylor Alexander]

Taylor Alexander  added the comment:

Hello all. Curious issue. Thanks Stargirl for opening it.

Would it be possible for the __repr__ function to examine the calling commands 
and determine if the origin is the special case where exit is typed in the 
REPL? Then only when Quitter repr is called would the special case be checked. 
I’m not too familiar with Python internals but I know for example when an 
exception occurs a stack trace would include information like that. Probably 
performance of Quitter repr isn’t critical we just don’t want it to have the 
wrong behavior. But if there’s any way to determine in that call if we’re in 
this one special case it seems it would be safe to exit.

--
nosy: +tlalexander

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

[issue44523] weakref.proxy documentation might be outdated

[Alexander Neumann]

New submission from Alexander Neumann :

The documentation currently states:

> Proxy objects are not hashable regardless of the referent; this avoids a 
> number of problems related to their fundamentally mutable nature, and prevent 
> their use as dictionary keys. callback is the same as the parameter of the 
> same name to the ref() function.

However, it seems with commit 96074de573f82fc66a2bd73c36905141a3f1d5c1 
(https://github.com/python/cpython/commit/96074de573f82fc66a2bd73c36905141a3f1d5c1)
 hash/reversed pass throughs have been introduced that enable weakref.proxy to 
be used as a dictionary key. At least the following code fails with Python 3.8 
but works with Python 3.9:

```
import weakref


class Model:
pass


m = Model()
proxy = weakref.proxy(m)
ref = weakref.ref(m)
print(hash(m))
print(hash(ref))
print(hash(proxy))
```

--
assignee: docs@python
components: Documentation
messages: 396637
nosy: aleneum, docs@python
priority: normal
severity: normal
status: open
title: weakref.proxy documentation might be outdated
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

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

[issue44440] logging does not work as documented (setLevel)

[Alexander Dietz]

Alexander Dietz  added the comment:

I was not asking for a solution or a workaround. I simply wanted to submit this 
bug in either the code or the documentation.

--

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

[issue44440] logging does not work as documented (setLevel)

[Alexander Dietz]

New submission from Alexander Dietz :

Using python 3.8.10 and the documentation 
https://docs.python.org/3.8/library/logging.html it seems that either the 
documentation is incorrect/unclear, or that the logging module does not work as 
described. 

Reading on the Logger Object and the setLevel method I created the attached 
python code, which does not work as expected. As I set the level to "DEBUG", 
and the documentation clearly says " Logging messages which are less severe 
than level will be ignored". But having set the level to DEBUG, even the more 
"severe" info message is ignored. That is clearly contradicting the 
documentation!

--
assignee: docs@python
components: Documentation
files: problem.py
messages: 395984
nosy: alex4200, docs@python
priority: normal
severity: normal
status: open
title: logging does not work as documented (setLevel)
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file50114/problem.py

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

[issue43991] asyncio lock does not get released after task is canceled

[Alexander Niederbühl]

Alexander Niederbühl  added the comment:

That makes sense, thanks!

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

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

[issue43991] asyncio lock does not get released after task is canceled

[Alexander Niederbühl]

New submission from Alexander Niederbühl :

If a task gets canceled while holding a lock, the lock is not automatically 
released. Is that expected, it seems like it could cause a deadlock?

Failing test adapted from Lib/test/test_asyncio/test_locks.py (commit 
6bd9288b80):

def test_acquire_cancel(self):
lock = asyncio.Lock()
self.assertTrue(self.loop.run_until_complete(lock.acquire()))

task = self.loop.create_task(lock.acquire())
self.loop.call_soon(task.cancel)
self.assertRaises(
asyncio.CancelledError,
self.loop.run_until_complete, task)
self.assertFalse(lock._waiters)

# Should the lock get released after cancellation?
self.assertFalse(lock.locked())

I stumbled upon this while playing around with TLA+.

--
components: asyncio
messages: 392499
nosy: a.niederbuehl, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: asyncio lock does not get released after task is canceled
type: behavior

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

[issue15443] datetime module has no support for nanoseconds

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

> In telemetry,

a nanosecond often translates to about a foot and 5 hours gets you to Pluto.  
Telemetry is exactly an application where absolute timestamps rarely make any 
sense.

--

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

[issue15443] datetime module has no support for nanoseconds

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

Is there high enough demand for nanoseconds in datetime and time instances?

How often nanosecond timestamps contain anything other than 0s or garbage in 
the last three digits?

In my experience, all people want to do with such timestamps is to convert them 
to something expressed in hours, minutes and seconds rather than just a huge 
number of seconds and back without loosing the value.

A timedelta is almost always a decent replacement for either datetime or time 
in those cases and sometimes it is even preferable because arithmetically it is 
closer to numbers.

--

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

[issue15443] datetime module has no support for nanoseconds

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

@pganssle - let's keep the substantive discussions in the tracker so that they 
are not lost on github.  You wrote:

"""
what is still blocking / needs to be done on this? Beta freeze for Python 3.10 
is coming up at the beginning of May and I think we may have enough time to get 
this in before then. Probably would have been better to get it into an alpha 
release, but if we miss beta freeze it'll get pushed to 3.11, and I do think 
that nanosecond support is a desirable feature for a lot of people.

It might be good for us to get an explicit "to-do" list of concerns to be 
addressed before this can be merged.
"""

I don't think full nanosecond support is feasible to complete in the remaining 
weeks, but we can try to add nanoseconds to timedelta only.  The mixed datetime 
+ timedelta ops will still truncate, but many time-related  operations will be 
enabled.

I would even argue that when nanoseconds precision is required, it is more 
often intervals no longer than a few days and rarely a specific point in time.

--
versions: +Python 3.10 -Python 3.7

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

[issue43714] re.split(), re.sub(): '\Z' must consume end of string if it matched

[Alexander Grigoriev]

Alexander Grigoriev  added the comment:

For example, sed:

$ sed --version
sed (GNU sed) 4.8
Copyright (C) 2020 Free Software Foundation, Inc.

$ sed -e 's/-\?$/x/g' <<<'a-b-'
a-bx

Perl:
$ perl --version

This is perl 5, version 32, subversion 0 (v5.32.0) built for 
x86_64-msys-thread-multi

Copyright 1987-2020, Larry Wall
$ perl -e 'my $x="a-b-"; $x =~ s/-?$/x/g; print $x'
a-bxx

https://www.freeformatter.com/java-regex-tester.html

Java Regular Expression :
-?$
Entry to test against :
a-b-c-
String replacement result:
a-b-cx

During replacement or split, a match consumes the matched character. It's easy 
to forget that "end of line" should be considered a (pseudo)character and must 
also be consumed if it matched.

--

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

[issue43714] re.split(), re.sub(): '\Z' must consume end of string if it matched

[Alexander Grigoriev]

New submission from Alexander Grigoriev :

If '\Z' matches as part of a pattern in re.sub() or re.split(), it should 
consume the end of string, and then '\Z' alone should not match the end of 
string again.

Current behavior:

Python 3.9.2 (tags/v3.9.2:1a79785, Feb 19 2021, 13:44:55) [MSC v.1928 64 bit 
(AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> print(re.split(r'/?\Z', 'a/b/c/d/'))
['a/b/c/d', '', '']
>>> print(re.sub(r'/?\Z', '-', 'a/b/c/d/'))
a/b/c/d--


Wanted behavior:

>>> print(re.split(r'/?\Z', 'a/b/c/d/'))
['a/b/c/d', '']
>>> print(re.sub(r'/?\Z', '-', 'a/b/c/d/'))
a/b/c/d-

--
components: Library (Lib)
messages: 390124
nosy: alegrigoriev
priority: normal
severity: normal
status: open
title: re.split(), re.sub(): '\Z' must consume end of string if it matched
type: behavior
versions: Python 3.9

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

[issue43686] re.match appears to hang with certain combinations of pattern and string

[Alexander Grigoriev]

New submission from Alexander Grigoriev :

Certain patterns and input strings cause re.match to take exponentially longer 
time. This can be expected because of recursive nature of matching some 
patterns, but it can take surprisingly long time with some combination of a 
pattern and input data of moderate length. For example:

import re
import time

t1 = time.monotonic()
re.match(rb'((?: |\t)*)((?:.*?(?:\\(?: |\t)+)?)*)(\s*)$', b'#define EVENT_ 
{\t\\\r\n\tif {\t\\\r\n\t\tmnt_disp;\t\\\r\n\t} }\r\n')
t2 = time.monotonic()
print(r"re.match(rb'((?: |\t)*)((?:.*?(?:\\(?: |\t)+)?)*)(\s*)$', b'#define 
EVENT_ {\t\\\r\n\tif {\t\\\r\n\t\tmnt_disp;\t\\\r\n\t} }\r\n'): %s s" % (t2-t1))
t1 = time.monotonic()
re.match(rb'((?: |\t)*)((?:.*?(?:\\(?: |\t)+)?)*)(\s*)$', b'#define EVENT_D 
{\t\\\r\n\tif {\t\\\r\n\t\tmnt_disp;\t\\\r\n\t} }\r\n')
t2 = time.monotonic()
print(r"re.match(rb'((?: |\t)*)((?:.*?(?:\\(?: |\t)+)?)*)(\s*)$', b'#define 
EVENT_D {\t\\\r\n\tif {\t\\\r\n\t\tmnt_disp;\t\\\r\n\t} }\r\n'): %s s" % 
(t2-t1))
t1 = time.monotonic()
re.match(rb'((?: |\t)*)((?:.*?(?:\\(?: |\t)+)?)*)(\s*)$', b'#define EVENT_DI 
{\t\\\r\n\tif {\t\\\r\n\t\tmnt_disp;\t\\\r\n\t} }\r\n')
t2 = time.monotonic()
print(r"re.match(rb'((?: |\t)*)((?:.*?(?:\\(?: |\t)+)?)*)(\s*)$', b'#define 
EVENT_DI {\t\\\r\n\tif {\t\\\r\n\t\tmnt_disp;\t\\\r\n\t} }\r\n'): %s s" % 
(t2-t1))
t1 = time.monotonic()
re.match(rb'((?: |\t)*)((?:.*?(?:\\(?: |\t)+)?)*)(\s*)$', b'#define EVENT_DIS 
{\t\\\r\n\tif {\t\\\r\n\t\tmnt_disp;\t\\\r\n\t} }\r\n')
t2 = time.monotonic()
print(r"re.match(rb'((?: |\t)*)((?:.*?(?:\\(?: |\t)+)?)*)(\s*)$', b'#define 
EVENT_DIS {\t\\\r\n\tif {\t\\\r\n\t\tmnt_disp;\t\\\r\n\t} }\r\n'): %s s" % 
(t2-t1))
t1 = time.monotonic()
re.match(rb'((?: |\t)*)((?:.*?(?:\\(?: |\t)+)?)*)(\s*)$', b'#define EVENT_DISP 
{\t\\\r\n\tif {\t\\\r\n\t\tmnt_disp;\t\\\r\n\t} }\r\n')
t2 = time.monotonic()
print(r"re.match(rb'((?: |\t)*)((?:.*?(?:\\(?: |\t)+)?)*)(\s*)$', b'#define 
EVENT_DISP {\t\\\r\n\tif {\t\\\r\n\t\tmnt_disp;\t\\\r\n\t} }\r\n'): %s s" % 
(t2-t1))
t1 = time.monotonic()
re.match(rb'((?: |\t)*)((?:.*?(?:\\(?: |\t)+)?)*)(\s*)$', b'#define EVENT_DISPL 
{\t\\\r\n\tif {\t\\\r\n\t\tmnt_disp;\t\\\r\n\t} }\r\n')
t2 = time.monotonic()
print(r"re.match(rb'((?: |\t)*)((?:.*?(?:\\(?: |\t)+)?)*)(\s*)$', b'#define 
EVENT_DISPL {\t\\\r\n\tif {\t\\\r\n\t\tmnt_disp;\t\\\r\n\t} }\r\n'): %s s" % 
(t2-t1))
t1 = time.monotonic()
re.match(rb'((?: |\t)*)((?:.*?(?:\\(?: |\t)+)?)*)(\s*)$', b'#define 
EVENT_DISPLA {\t\\\r\n\tif {\t\\\r\n\t\tmnt_disp;\t\\\r\n\t} }\r\n')
t2 = time.monotonic()
print(r"re.match(rb'((?: |\t)*)((?:.*?(?:\\(?: |\t)+)?)*)(\s*)$', b'#define 
EVENT_DISPLA {\t\\\r\n\tif {\t\\\r\n\t\tmnt_disp;\t\\\r\n\t} }\r\n'): %s s" % 
(t2-t1))
t1 = time.monotonic()
re.match(rb'((?: |\t)*)((?:.*?(?:\\(?: |\t)+)?)*)(\s*)$', b'#define 
EVENT_DISPLAY {\t\\\r\n\tif {\t\\\r\n\t\tmnt_disp;\t\\\r\n\t} }\r\n')
t2 = time.monotonic()
print(r"re.match(rb'((?: |\t)*)((?:.*?(?:\\(?: |\t)+)?)*)(\s*)$', b'#define 
EVENT_DISPLAY {\t\\\r\n\tif {\t\\\r\n\t\tmnt_disp;\t\\\r\n\t} }\r\n'): %s s" % 
(t2-t1))


Does:

re.match(rb'((?: |\t)*)((?:.*?(?:\\(?: |\t)+)?)*)(\s*)$', b'#define EVENT_ 
{\t\\\r\n\tif {\t\\\r\n\t\tmnt_disp;\t\\\r\n\t} }\r\n'): 0.219000409782 s
re.match(rb'((?: |\t)*)((?:.*?(?:\\(?: |\t)+)?)*)(\s*)$', b'#define EVENT_D 
{\t\\\r\n\tif {\t\\\r\n\t\tmnt_disp;\t\\\r\n\t} }\r\n'): 0.452999795109 s
re.match(rb'((?: |\t)*)((?:.*?(?:\\(?: |\t)+)?)*)(\s*)$', b'#define EVENT_DI 
{\t\\\r\n\tif {\t\\\r\n\t\tmnt_disp;\t\\\r\n\t} }\r\n'): 0.952999795109 s
re.match(rb'((?: |\t)*)((?:.*?(?:\\(?: |\t)+)?)*)(\s*)$', b'#define EVENT_DIS 
{\t\\\r\n\tif {\t\\\r\n\t\tmnt_disp;\t\\\r\n\t} }\r\n'): 1.79700020489 s
re.match(rb'((?: |\t)*)((?:.*?(?:\\(?: |\t)+)?)*)(\s*)$', b'#define EVENT_DISP 
{\t\\\r\n\tif {\t\\\r\n\t\tmnt_disp;\t\\\r\n\t} }\r\n'): 3.609001713634 s
re.match(rb'((?: |\t)*)((?:.*?(?:\\(?: |\t)+)?)*)(\s*)$', b'#define EVENT_DISPL 
{\t\\\r\n\tif {\t\\\r\n\t\tmnt_disp;\t\\\r\n\t} }\r\n'): 7.125 s
re.match(rb'((?: |\t)*)((?:.*?(?:\\(?: |\t)+)?)*)(\s*)$', b'#define 
EVENT_DISPLA {\t\\\r\n\tif {\t\\\r\n\t\tmnt_disp;\t\\\r\n\t} }\r\n'): 
14.89099828637 s
re.match(rb'((?: |\t)*)((?:.*?(?:\\(?: |\t)+)?)*)(\s*)$', b'#define 
EVENT_DISPLAY {\t\\\r\n\tif {\t\\\r\n\t\tmnt_disp;\t\\\r\n\t} }\r\n'): 
29.68800081956 s


Perhaps re.match needs to be optimized and/or rewritten in low level language 
(C)

--
components: Library (Lib)
messages: 389949
nosy: alegrigoriev
priority: normal
severity: normal
status: open
title: re.match appears to hang with certain combinations of pattern and string
type: performance
versions: Python 3.9

___
Python tracker 
<https://bugs.python.org/issue43686>
___
___
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 
<https://bugs.python.org/issue35935>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42938] [security][CVE-2021-3177] ctypes double representation BoF

[Alexander Riccio]

Alexander Riccio  added the comment:

Yes, I definitely should. I work on https://bugs.python.org/issue25878 
sometimes, which encompasses this.

--

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

[issue42938] [security][CVE-2021-3177] ctypes double representation BoF

[Alexander Riccio]

Alexander Riccio  added the comment:

Petition to remove all uses of the unchecked string handling functions from 
CPython?

Sidenote: if C4996 was on, this would be a warning.

--
nosy: +Alexander Riccio

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

[issue33935] shutil.copyfile throws incorrect SameFileError on Google Drive File Stream

[Alexander]

Alexander  added the comment:

Hi,
This issue was also confirmed by a Verge3D user (Python 3.7.7)
https://www.soft8soft.com/topic/export-gltf-error

--
nosy: +alexkowel

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

[issue38905] venv python reports wrong sys.executable in a subprocess on Windows

[Alexander Stepanov]

Alexander Stepanov  added the comment:

Another victim of this change in `venv` behavior is Ray, which hangs forever 
because the workers fail to register as parent does not recognize their PIDs.
https://github.com/ray-project/ray/issues/13794

--
nosy: +nirvana-msu

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

[issue42958] filecmp.cmp(shallow=True) isn't actually shallow when only mtime differs

[Alexander Vandenbulcke]

Change by Alexander Vandenbulcke :


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

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

[issue42958] filecmp.cmp(shallow=True) isn't actually shallow when only mtime differs

[Alexander Vandenbulcke]

New submission from Alexander Vandenbulcke :

Consider the case where 2 files are shallow compared where only the mtime 
differs (i.e. the mode and size is identical).

With filecmp.cmp(f1, f2, shallow=True) a deep compare would be performed behind 
the scenes since the guard clauses fell through. This discrepancy is either a 
problem in the docstring or a problem in the comparison itself.

Two options remain:
- the documentation is altered and describes that, in case only the mtime 
differs (i.e. mode and size are equal) a deep compare is performed
- the behaviour is restricted in that effectively only a shallow compare is 
performed
- a shallow compare becomes more restrictive (do not consider the mtime during 
the compare)

My preference is to adjust the function to safeguard the meaning of 'shallow' 
in this context.

--
components: Library (Lib)
messages: 385225
nosy: AlexVndnblcke
priority: normal
severity: normal
status: open
title: filecmp.cmp(shallow=True) isn't actually shallow when only mtime differs
type: behavior

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

[issue42538] AsyncIO strange behaviour

[Alexander Greckov]

Alexander Greckov  added the comment:

Thanks! That's resolved my problem, but this thing wasn't really obvious as for 
me. Probably it would be better to write about this explicitly in docs for the 
create_task. All in all this issue can be closed.

--

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

[issue42538] AsyncIO strange behaviour

[Alexander Greckov]

New submission from Alexander Greckov :

Hi! I've met strange behaviour related to the coroutine execution. Probably 
it's somehow related to the asyncio.Queue get() method. I have the following 
lines of code:
class WeightSource:
def __init__(self):
self._queue = asyncio.Queue(maxsize=1)
def __aiter__(self):
return self
async def __anext__(self):
return await self._queue.get()

async def _preconfigure(app: web.Application) -> None:
setup_db()
# asyncio.create_task(WeightSource.listen_scales('/dev/ttyACM0', 9600)
asyncio.create_task(handle_weight_event_creation()) # coroutine prints 
WEIGHT 
await create_track_tasks()

async def create_track_tasks():
asyncio.create_task(track_scales_availability())
asyncio.create_task(track_crm_availability())

async def track_scales_availability():
async for weight in WeightSource():
print(weight)

When I'm trying to run _preconfigure coroutine (automatically started by 
aiohttp), i see the message: ERROR:asyncio:Task was destroyed but it is 
pending. The strange things two:
The process and loop remains alive (so by the logic error should be not shown) 
and the second thing is when I export PYTHONASYNCIODEBUG=1 everything works 
well without any error. 
On unset this variable the error returns. When I don't use asyncio.Queue and 
just place asyncio.sleep(), coroutine doesn't fall. Error happens inside the 
`async for weight in WeightSource()` statement. Why PYTHONASYNCIODEBUG changes 
behaviour?

--
components: asyncio
files: output.txt
messages: 382307
nosy: Alexander-Greckov, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: AsyncIO strange behaviour
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file49644/output.txt

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

[issue25538] Traceback from __exit__ method is misleading

[Alexander Kurakin]

Change by Alexander Kurakin :


--
nosy: +kuraga

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

[issue42372] A crash in do_richcompare

[Alexander Kurakin]

Alexander Kurakin  added the comment:

Ok, close.

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

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

[issue42372] A crash in do_richcompare

[Alexander Kurakin]

Alexander Kurakin  added the comment:

Thanks for reply!

Is it call of NULL? If so, shoudn't do_richcompare check it?

--

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

[issue42372] A crash in do_richcompare

[Alexander Kurakin]

New submission from Alexander Kurakin :

Sometimes test.py causes a crash in 3.7.9 (and lower to 2018 year or more) on 
Linux.

See also: https://github.com/pandas-dev/pandas/issues/21968

--
components: Interpreter Core
files: issue.zip
messages: 381113
nosy: kuraga
priority: normal
severity: normal
status: open
title: A crash in do_richcompare
type: crash
versions: Python 3.7
Added file: https://bugs.python.org/file49603/issue.zip

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

[issue41904] datetime.datetime.today makes no sense and should be removed

[Alexander Belopolsky]

Change by Alexander Belopolsky :


--
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

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

[issue41904] datetime.datetime.today makes no sense and should be removed

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

I agree that having some of datetime.now([tz]) functionality replicated in 
datetime.today() makes little sense.  However, the presence of this method in 
datetime class is a consequence of datetime being a subclass of the date class. 
The latter was a design mistake IMO, but as other pointed out it is too late to 
do anything about it.

--
assignee:  -> belopolsky

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

[issue41965] distutils.spawn.find_executable() fails to find .py files on Windows

[Alexander Todorov]

Alexander Todorov  added the comment:

@Eryk Sun,
you are of course correct but still don't we need to handle this in Python? 

- find_executable() will search for rst2man.py.exe which doesn't exist so no 
good for the user
- there is also no rst2man.exe which is probably an issue with how docutils 
distributes this script - e.g. it doesn't distribute the wrapper .exe file
- lastly the caller (in my case python-bugzilla) will try to execute rst2man.py 
which will probably fail but at least they would see another failure and are 
more likely to change their own code base

The trouble for me here is that find_executable() will generally not find 
anything that doesn't have .exe suffix on Windows. This is independent of how 
the resulting file would be consumed later.

--

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

[issue41965] distutils.spawn.find_executable() fails to find .py files on Windows

[Alexander Todorov]

New submission from Alexander Todorov :

As part of installing python-bugzilla via pip it searches for `rst2man` or 
`rst2man.py`, see:
https://github.com/python-bugzilla/python-bugzilla/blob/master/setup.py#L81

on Windows venvs there is venv\Scripts\rst2man.py (no .exe or without suffix) 
and when you call find_executable('rst2man.py') if doesn't find it.


The trouble is in this code snippet:

```
_, ext = os.path.splitext(executable)
if (sys.platform == 'win32') and (ext != '.exe'):
executable = executable + '.exe'
```

`ext` here is `.py` and the if condition executes its body so the executable to 
search for becomes `rst2man.py.exe` which doesn't exist.

The extension check has been like that for more than 20 years:
https://github.com/python/cpython/commit/69628b0ad10f89a65902f5b911d1040ed9ae1ca2

but IMO it should be 

```
if (sys.platform == 'win32') and (ext == ''):
executable = executable + '.exe'
```

i.e. add `.exe` only if the file we're looking for doesn't already have an 
extension.


Let me know what you think? I can submit a PR for this.


Related issues:

- https://bugs.python.org/issue2200

- https://bugs.python.org/issue39260

--
components: Distutils
messages: 378150
nosy: Alexander.Todorov, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: distutils.spawn.find_executable() fails to find .py files on Windows
type: behavior

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

[issue40553] Python 3.8.2 Mac freezing/not responding when saving new programs

[Alexander Boeckmann]

Alexander Boeckmann  added the comment:

So over the past week the issue resolved its self. I unfortunately did not get 
a video or a screenshot but thought you might want to know this
So maybe Apple did something or you guys fixed it. Anyways, have a good day!

--

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

[issue40553] Python 3.8.2 Mac freezing/not responding when saving new programs

[Alexander Boeckmann]

Alexander Boeckmann  added the comment:

Hey! I have the exact same thing as described happening! Python freezes when I 
try to save new files which sucks. 
I'm on Catalina: 10.15.6
IDLE: 3.8.5
Brand new MacBook Air
As said earlier the only way out is to force quit. Would taking a video help?
I'll make one anyways

--
nosy: +aboeckmann

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

[issue41560] pathlib.Path.glob fails on empty string

[Alexander Heger]

Alexander Heger  added the comment:

In my code, having been translated form use of `os.path` to `pathlib.Path` the 
change in behaviour caused errors and required significant refactoring.  

Why not just return the empty list if there is no match, as is done in other 
cases when there is no match, except when passing the empty string.  For 
example, in my case, the base path already refers to a potentially existing 
file[name] and I then "glob" for appendices to the filename or suffices (or 
neither or both).  So in this case the glob for empty strong would just return 
the file if it exists.

--

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

[issue41560] pathlib.Path.glob fails on empty string

[Alexander Heger]

New submission from Alexander Heger :

Passing an empty string to pathlib.Path.glob fails.

Example
```
from pathlib import Path
path = Path('./myfile.txt')
path.glob('')
```

The result is:
```
~/Python/lib/python3.8/pathlib.py in glob(self, pattern)
   1129 """
   1130 if not pattern:
-> 1131 raise ValueError("Unacceptable pattern: 
{!r}".format(pattern))
   1132 drv, root, pattern_parts = self._flavour.parse_parts((pattern,))
   1133 if drv or root:

ValueError: Unacceptable pattern: ''
```

This is not the desired or expected behaviour, which would be to just return 
`path` if it exists.  This behaviour is also inconsistent with the 
documentation which states (Python 3.8.5):
"""
Glob the given relative pattern in the directory represented by this path, 
yielding all matching files (of any kind):
"""

And it is in contrast to the behaviour of glob.glob, which is just fine with 
the empty string, returning an empty list.

--
components: Library (Lib)
messages: 375499
nosy: alex.heger
priority: normal
severity: normal
status: open
title: pathlib.Path.glob fails on empty string
type: crash
versions: Python 3.8

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

[issue41450] OSError is not documented in ssl library, but still can be thrown

[Alexander Sibiryakov]

New submission from Alexander Sibiryakov :

See stack trace
[07/15/2020 08:51:14.799: ERROR/kafka.producer.sender] Uncaught error in kafka 
producer I/O thread
Traceback (most recent call last):
File "/usr/local/lib/python3.6/site-packages/kafka/producer/sender.py", line 
60, in run
self.run_once()
File "/usr/local/lib/python3.6/site-packages/kafka/producer/sender.py", line 
160, in run_once
self._client.poll(timeout_ms=poll_timeout_ms)
File "/usr/local/lib/python3.6/site-packages/kafka/client_async.py", line 580, 
in poll
self._maybe_connect(node_id)
File "/usr/local/lib/python3.6/site-packages/kafka/client_async.py", line 390, 
in _maybe_connect
conn.connect()
File "/usr/local/lib/python3.6/site-packages/kafka/conn.py", line 426, in 
connect
if self._try_handshake():
File "/usr/local/lib/python3.6/site-packages/kafka/conn.py", line 505, in 
_try_handshake
self._sock.do_handshake()
File "/usr/local/lib/python3.6/ssl.py", line 1077, in do_handshake
self._sslobj.do_handshake()
File "/usr/local/lib/python3.6/ssl.py", line 689, in do_handshake
self._sslobj.do_handshake()
OSError: [Errno 0] Error

See docs
https://docs.python.org/3.8/library/ssl.html

and see source code:
https://github.com/python/cpython/blob/3.8/Modules/_ssl.c

Probably the best would be to proceed with using SSLError, but short term 
OSError could be documented.

--
assignee: docs@python
components: Documentation
messages: 374644
nosy: docs@python, sibiryakov
priority: normal
severity: normal
status: open
title: OSError is not documented in ssl library, but still can be thrown
type: behavior
versions: Python 3.8

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

[issue41322] unittest: Generator test methods will always be marked as passed

[Alexander Hungenberg]

Alexander Hungenberg  added the comment:

I would also strongly vote for raising an error if the test method is a 
generator - not even silently turn it into a list.

It would be straight forward to implement various checks (like the ones you 
mentioned for generators, coroutines, ...) - and they will absolutely help to 
prevent unintended errors, especially by more junior developers.

--

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

[issue41322] unittest: Generator test methods will always be marked as passed

[Alexander Hungenberg]

New submission from Alexander Hungenberg :

The following testcase will always be marked as passed:

from unittest import TestCase

class BuggyTestCase(TestCase):
def test_generator(self):
self.assertTrue(False)
yield None


It happened to us that someone accidentally made the test method a generator 
function. That error was caught very late, because it always appears to have 
executed correctly.

Maybe an additional check can be introduced in the unittest module, to check if 
a test_ method was executed correctly?

--
components: Library (Lib)
messages: 373807
nosy: defreng
priority: normal
severity: normal
status: open
title: unittest: Generator test methods will always be marked as passed
type: behavior
versions: Python 3.8

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

[issue36098] asyncio: ssl client-server with "slow" read

[Alexander Mohr]

Alexander Mohr  added the comment:

so I did some investigation into the difference between aiohttp + httpx and it 
appears that for some reason httpx does an extra read after the connection is 
closed.

--

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

[issue36098] asyncio: ssl client-server with "slow" read

[Alexander Mohr]

Alexander Mohr  added the comment:

I've updated https://repl.it/@thehesiod/PristineBonyBugs#main.py to contain 
both httpx + aiohttp testcases, and now httpx reproduces almost immediately and 
aiohttp is still ok

--

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

[issue36098] asyncio: ssl client-server with "slow" read

[Alexander Mohr]

Alexander Mohr  added the comment:

as an FYI I've reproduced this with the httpx library as well: 
https://repl.it/repls/PristineBonyBugs#main.py.  It reproduces on this site but 
I've been unable to reproduce it locally.  It does always reproduce on our 
production systems.

what's interesting is that it I can't seem to be able to reproduce it with 
aiohttp either on that site or locally:
https://repl.it/@thehesiod/PristineBonyBugs-1#main.py

does aiohttp do something to avoid this scenario?

--

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

[issue36098] asyncio: ssl client-server with "slow" read

[Alexander Mohr]

Change by Alexander Mohr :


--
nosy: +thehesiod

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

[issue40550] Popen.terminate fails with ProcessLookupError under certain conditions

[Alexander Overvoorde]

Alexander Overvoorde  added the comment:

I understand that it's not a perfect solution, but at least it's a little bit 
closer. Thanks for your patch :)

--

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

[issue40550] Popen.terminate fails with ProcessLookupError under certain conditions

[Alexander Overvoorde]

Alexander Overvoorde  added the comment:

I'm not sure that it is expected since Popen.send_signal does contain the 
following check:

```
def send_signal(self, sig):
"""Send a signal to the process."""
# Skip signalling a process that we know has already died.
if self.returncode is None:
os.kill(self.pid, sig)
```

Additionally, the following program does not raise a ProcessLookupError despite 
the program already having exited:

```
import subprocess
import time

proc = subprocess.Popen(["sh", "-c", "exit 0"])

time.sleep(5)

proc.terminate()
```

--

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

[issue40550] Popen.terminate fails with ProcessLookupError under certain conditions

[Alexander Overvoorde]

New submission from Alexander Overvoorde :

The following program frequently raises a ProcessLookupError exception when 
calling proc.terminate():

```
import threading
import subprocess
import multiprocessing

proc = subprocess.Popen(["sh", "-c", "exit 0"])

q = multiprocessing.Queue()

def communicate_thread(proc):
proc.communicate()

t = threading.Thread(target=communicate_thread, args=(proc,))
t.start()

proc.terminate()

t.join()
```

I'm reproducing this with Python 3.8.2 on Arch Linux by saving the script and 
rapidly executing it like this:

$ bash -e -c "while true; do python3 test.py; done

The (unused) multiprocessing.Queue seems to play a role here because the 
problem vanishes when removing that one line.

--
components: Library (Lib)
messages: 368370
nosy: Alexander Overvoorde
priority: normal
severity: normal
status: open
title: Popen.terminate fails with ProcessLookupError under certain conditions
type: behavior
versions: Python 3.8

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

[issue40145] Pyshellext room for binary size improvement

[Alexander Riccio]

Alexander Riccio  added the comment:

Oh, uh, also, do you prefer I add a commit or a new branch & PR?

--

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

[issue40145] Pyshellext room for binary size improvement

[Alexander Riccio]

Alexander Riccio  added the comment:

Ahh, ok. Even though I question the usefulness of manually maintaining MSBuild 
files instead of something like CMake, I can work with that. Is there a 
preferred way to do it? It looks like I can do a 
Condition="'$(Configuration)|$(Platform)'=='Release|x64'" and merge a bunch of 
things under each one.

--

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

[issue40161] Name collisions in pythoncore, preventing unity/jumbo build

[Alexander Riccio]

New submission from Alexander Riccio :

This isn't a priority issue I'd say. However, fixing it could yield nice 
benefits. I ran into this while experimenting with JUMBO/Unity builds as part 
of a bit of fun I've been having tweaking build options across the CPython 
ecosystem.

Theoretically, a JUMBO/Unity build could reduce code size, improve performance, 
and maybe even help code analysis detect more bugs by building everything in a 
single compilation unit. Link Time Code Generation is great, but usually isn't 
as good as building everything in a single compilation unit.


An example of an interesting thing noticed while compiling as a Unity build:

This exact variable is defined twice in two separate source files, 
itertoolsmodule.c:4303, and and collectionsmodule.c:1774:

PyDoc_STRVAR(length_hint_doc, "Private method returning an estimate of 
len(list(it)).");

...the default Release configuration includes this exact string 12 (!) times.

There's a lot of stuff like that. It's not actually broken, and sometimes it's 
probably inconvenient to fix it (what are you gonna do? put it in a header?), 
but it would be nice.

--
components: Interpreter Core
messages: 365636
nosy: Alexander Riccio
priority: normal
severity: normal
status: open
title: Name collisions in pythoncore, preventing unity/jumbo build
type: compile error
versions: Python 3.9

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

[issue40151] _overlapped room for improvement

[Alexander Riccio]

Change by Alexander Riccio :


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

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

[issue40145] Pyshellext room for binary size improvement

[Alexander Riccio]

Change by Alexander Riccio :


--
pull_requests: +18659
pull_request: https://github.com/python/cpython/pull/19298

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

[issue40151] _overlapped room for improvement

[Alexander Riccio]

New submission from Alexander Riccio :

Similarly to bpo-40145, I've tweaked build options to reduce the size of the
binary.

This patch turns on (for release builds) Whole Program Optimization, MinSpace
optimization, /Ob2 AnySuitable function inlining, /Zo (so that people can still
debug it when lots of code has been optimized out), /OPT:REF dead code
elimination, /OPT:ICF COMDAT folding, Link Time Code Generation, and DebugFull
debugging information creation.

For debug builds, it enables all of that, except instead of the MinSpace
optimization, it's only /Ob2 with custom optimization. My intent is to not
optimize any asserts or similar checks, while still getting the benefit of
dead and duplicate code elimination.


_overlapped.pyd   32 bit unimproved release size: 31KB
_overlapped.pyd   32 bit   improved release size: 29KB
size reduction:   -3KB
 %  size reduction:10%

_overlapped_d.pyd 32 bit unimproved release size: 55KB
_overlapped_d.pyd 32 bit   improved release size: 34KB
size reduction:  -21KB
 %  size reduction:38%




_overlapped.pyd   64 bit unimproved release size: 39KB
_overlapped.pyd   64 bit   improved release size: 36KB
size reduction:   -3KB
 %  size reduction: 8%


_overlapped_d.pyd 64 bit unimproved release size: 74KB
_overlapped_d.pyd 64 bit   improved release size: 41KB
size reduction:  -33KB
 %  size reduction:45%


If this patch is merged, and all 7 million (estimated) Python developers update 
their installation, I calculate that I just saved the PSF 21GB worth of 
bandwidth costs :)

--
components: Windows
messages: 365567
nosy: Alexander Riccio, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: _overlapped room for improvement
type: enhancement
versions: Python 3.9

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

[issue40150] (minor) mismatched argument in overlapped_RegisterWaitWithQueue call to RegisterWaitForSingleObject

[Alexander Riccio]

New submission from Alexander Riccio :

This popped out at me while looking for something else. It's probably not much 
of an actual problem, since the wrong datatype is larger than the correct one, 
but it's worth fixing.

The problem is in overlapped_RegisterWaitWithQueue, at overlapped.c:297 (in 
_overlapped):

if (!RegisterWaitForSingleObject(
, Object, (WAITORTIMERCALLBACK)PostToQueueCallback,
pdata, Milliseconds,
WT_EXECUTEINWAITTHREAD | WT_EXECUTEONLYONCE))


...it stood out to me immediately while I was paging past, since function 
pointer casts of this sort are almost always wrong, and I've seen it too many 
times.

WAITORTIMERCALLBACK is a typedef of WAITORTIMERCALLBACKFUNC:

typedef VOID (NTAPI * WAITORTIMERCALLBACKFUNC) (PVOID, BOOLEAN );

...and PostToQueueCallback is defined as:

static VOID CALLBACK
PostToQueueCallback(PVOID lpParameter, BOOL TimerOrWaitFired)

...where BOOL is an int, and BOOLEAN is an unsigned char. I guess there could 
be some kind of issue down the line if the generated code tries to read the 
BOOLEAN/int from the register/memory location where there's actually an 
unsigned char, but after about an hour of debugging, I can't see it. The 
documentation also states explicitly that this should be either TRUE or FALSE. 
Also, it doesn't matter what we actually pass to PostQueuedCompletionStatus: 
https://devblogs.microsoft.com/oldnewthing/20070525-00/?p=26693

By changing the (incorrect) BOOL declaration to BOOLEAN, then we don't need the 
cast.

--
components: IO
messages: 365565
nosy: Alexander Riccio
priority: normal
severity: normal
status: open
title: (minor) mismatched argument in overlapped_RegisterWaitWithQueue call to 
RegisterWaitForSingleObject
versions: Python 3.9

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

[issue40145] Pyshellext room for binary size improvement

[Alexander Riccio]

Alexander Riccio  added the comment:

If this patch is merged, and all 7 million (estimated) Python developers update 
their installation, I calculate that I just saved the PSF 119GB worth of 
bandwidth costs :)

I'll take my 10 cents in the mail please :D

--

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

[issue40145] Pyshellext room for binary size improvement

[Alexander Riccio]

Change by Alexander Riccio :


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

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

[issue40145] Pyshellext room for binary size improvement

[Alexander Riccio]

New submission from Alexander Riccio :

I've tweaked the pcbuild options for pyshellext to reduce the size of the 
binary.
Since this is a very simple component, there really isn't much benefit of
optimizing for speed, likely the slowest part of this component's lifetime is
simply loading it.

This patch turns on Whole Program Optimization, MinSpace optimization, /Ob2
AnySuitable function inlining (to expose more code to elimination, this does
actually help here), /Zo (so that people can still debug it when lots of code
has been optimized out), turns of C++ RTTI (nobody is using it), /OPT:REF dead
code elimination, /OPT:ICF COMDAT folding, Link Time Code Generation, and
DebugFull debugging information creation.

/Gw global data optimization seemed to do nothing, which makes sense since
there isn't much going on in this project, very little in the way of actual
global data. Disabling C++ exceptions both in the project config (i.e. /EH-),
and disabling stdlib exceptions via _HAS_EXCEPTIONS=0, had no effect.
Strangely, with exceptions disabled and _HAS_EXCEPTIONS=0, exception functions
are still emitted in the binary (as seen in IDA). I presume it has something
to do with the fact that its a dll.

Enabling optimizations (even for Debug builds) should have no effect. The debug
builds were not actually using debugging featuers (not even assert), so nothing
should change.

pyshellext.dll   32 bit unimproved release size: 42KB
pyshellext.dll   32 bit   improved release size: 25KB
size reduction: -17KB
 %  size reduction:   40%

pyshellext_d.dll 32 bit unimproved debug size:   85KB
pyshellext_d.dll 32 bit   improved debug size:   32KB
   size reduction:  -53KB
 %  size reduction:   62%


pyshellext.dll   64 bit unimproved release size: 52KB
pyshellext.dll   64 bit   improved release size: 30KB
   size reduction:  -22KB
 %  size reduction:   42%

pyshellext_d.dll 64 bit unimproved debug size:  105KB
pyshellext_d.dll 64 bit   improved debug size:   38KB
   size reduction:  -67KB
 %  size reduction:   63%

--
components: Windows
messages: 365527
nosy: Alexander Riccio, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Pyshellext room for binary size improvement
versions: Python 3.9

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

[issue40143] shutil.rmtree will frequently fail on Windows under heavy load due to racy deletion

[Alexander Riccio]

New submission from Alexander Riccio :

The "obvious" way to delete a directory tree on Windows is wrong. It's 
inherently racy, since deleting a file on Windows *doesn't actually delete it*, 
instead it marks the file for deletion. The system will eventually get around 
to deleting it, but under heavy load, this might be sometime after an attempt 
is made to delete the parent directory. I've seen this (windows error 145, 
directory is not empty) many times when running the testsuite, and it causes 
all kinds of intermittent failures.

The best way to do things correctly is kinda nuts, and is explained well by 
Niall Douglass here: https://www.youtube.com/watch?v=uhRWMGBjlO8=8m54s

In short, the correct way to do it involves moving each file to a randomly 
named file in %TEMP%, then deleting that, and then doing the same with each 
newly-empty directory.

--
components: Windows
messages: 365520
nosy: Alexander Riccio, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: shutil.rmtree will frequently fail on Windows under heavy load due to 
racy deletion
versions: Python 3.9

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

[issue25878] CPython on Windows builds with /W3, not /W4

[Alexander Riccio]

Alexander Riccio  added the comment:

Ok, so a draft of this produces 34 warnings, but makes way more changes to the 
.vcxproj and .filters files than I think it should: 
https://github.com/ariccio/cpython/commit/60152aa065a3ad861f0359a8ada7f2fbc83a3933

Before I submit a PR, I think I should figure out how to change the defaults 
without Visual Studio adding a bunch of noise to the config - is that 
reasonable?

The warnings appear essentially innocuous - mixing signed/unsigned bytes, some 
benign truncation of constant values, and 3 places where local variables shadow 
the globals, where it looks like the global should've been used - but should be 
checked nonetheless.

The warnings are in the attached file.

--
Added file: https://bugs.python.org/file49017/34PythonWarnings.txt

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

[issue40020] growable_comment_array_add leaks, causes crash

[Alexander Riccio]

Alexander Riccio  added the comment:

Sure, should I open a new issue?

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

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

[issue40082] Assertion failure in trip_signal

[Alexander Riccio]

Alexander Riccio  added the comment:

Hmmm, happens every time I interrupt while attached. Is there some obvious 
gotcha in the docs that I'm missing?

--

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

[issue40082] Assertion failure in trip_signal

[Alexander Riccio]

Alexander Riccio  added the comment:

Lmao the name mangling comes up as a mailto. That's interesting.

--

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

[issue40082] Assertion failure in trip_signal

[Alexander Riccio]

New submission from Alexander Riccio :

While trying to make sense of some static analysis warnings for the Windows 
console IO module, I Ctrl+C'd in the middle of an intentionally absurd __repr__ 
output, and on proceeding in the debugger (which treated it as an exception), I 
immediately hit the assertion right here:

/* Get the Python thread state using PyGILState API, since
   _PyThreadState_GET() returns NULL if the GIL is released.
   For example, signal.raise_signal() releases the GIL. */
PyThreadState *tstate = PyGILState_GetThisThreadState();
assert(tstate != NULL);

...With the stacktrace: 
ucrtbased.dll!issue_debug_notification(const wchar_t * const message) 
Line 28   C++
ucrtbased.dll!__acrt_report_runtime_error(const wchar_t * message) Line 
154 C++
ucrtbased.dll!abort() Line 51   C++
ucrtbased.dll!common_assert_to_stderr_direct(const wchar_t * const 
expression, const wchar_t * const file_name, const unsigned int line_number) 
Line 161C++
ucrtbased.dll!common_assert_to_stderr(const wchar_t * const 
expression, const wchar_t * const file_name, const unsigned int line_number) 
Line 175  C++
ucrtbased.dll!common_assert(const wchar_t * const expression, 
const wchar_t * const file_name, const unsigned int line_number, void * const 
return_address) Line 420   C++
ucrtbased.dll!_wassert(const wchar_t * expression, const wchar_t * 
file_name, unsigned int line_number) Line 443C++
>   python39_d.dll!trip_signal(int sig_num) Line 266C
python39_d.dll!signal_handler(int sig_num) Line 342 C
ucrtbased.dll!ctrlevent_capture(const unsigned long ctrl_type) Line 206 
C++
KernelBase.dll!_CtrlRoutine@4()Unknown
kernel32.dll!@BaseThreadInitThunk@12() Unknown
ntdll.dll!__RtlUserThreadStart()Unknown
ntdll.dll!__RtlUserThreadStart@8() Unknown


...I'm not entirely sure why this happened, but I can tell a few things. 
_PyRuntime.gilstate.autoInterpreterState is NOT null, in fact the gilstate 
object is as displayed in my watch window: 

-   _PyRuntime.gilstate {check_enabled=1 
tstate_current={_value=0 } getframe=0x79e3a570 
{python39_d.dll!threadstate_getframe(_ts *)} ...}   _gilstate_runtime_state
check_enabled   1   int
+   tstate_current  {_value=0 } _Py_atomic_address
getframe0x79e3a570 
{python39_d.dll!threadstate_getframe(_ts *)} _frame *(*)(_ts *)
-   autoInterpreterState0x00e5eff8 {next=0x  
tstate_head=0x00e601c0 {prev=0x  next=0x  ...} ...} 
 _is *
+   next0x_is *
+   tstate_head 0x00e601c0 {prev=0x  
next=0x  interp=0x00e5eff8 {next=0x  ...} ...}   
_ts *
+   runtime 0x7a0e2118 {python39_d.dll!pyruntimestate _PyRuntime} 
{preinitializing=0 preinitialized=1 core_initialized=...} pyruntimestate *
id  0   __int64
id_refcount -1  __int64
requires_idref  0   int
id_mutex0x  void *
finalizing  0   int
+   ceval   {tracing_possible=0 eval_breaker={_value=0 } 
pending={finishing=0 lock=0x00e59390 calls_to_do={_value=...} ...} }   
_ceval_state
+   gc  {trash_delete_later=0x  
trash_delete_nesting=0 enabled=1 ...} _gc_runtime_state
+   modules 0x00bf1228 {ob_refcnt=3 ob_type=0x7a0b1178 
{python39_d.dll!_typeobject PyDict_Type} {ob_base={ob_base=...} ...} }   
_object *
+   modules_by_index0x00750058 {ob_refcnt=1 
ob_type=0x7a0b8210 {python39_d.dll!_typeobject PyList_Type} 
{ob_base={ob_base=...} ...} }   _object *
+   sysdict 0x00bf1298 {ob_refcnt=2 ob_type=0x7a0b1178 
{python39_d.dll!_typeobject PyDict_Type} {ob_base={ob_base=...} ...} }   
_object *
+   builtins0x00bf1f48 {ob_refcnt=88 ob_type=0x7a0b1178 
{python39_d.dll!_typeobject PyDict_Type} {ob_base={ob_base=...} ...} }  
_object *
+   importlib   0x00c0df60 {ob_refcnt=28 ob_type=0x7a0b92d0 
{python39_d.dll!_typeobject PyModule_Type} {ob_base={ob_base=...} ...} }
_object *
num_threads 0   long
pythread_stacksize  0   unsigned int
+   codec_search_path   0x00c4a260 {ob_refcnt=1 
ob_type=0x7a0b8210 {python39_d.dll!_typeobject PyList_Type} 
{ob_base={ob_base=...} ...} }   _object *
+   codec_search_cache  0x00c1f0d8 {ob_refcnt=1 
ob_type=0x7a0b1178 {python39_d.dll!_typeobject PyDict_Type} 
{ob_base={ob_base=...} ...} }   _object *
+   codec_error_registry0x00c14f10 {ob_refcnt=1 
ob_type=0x7a0b1178 {python39_d.dll!_typeobject PyDict_Type} 
{ob_base={ob_base=...} ...} }   _obj

[issue40079] NULL pointer deref on error path in _ssl debughelpers.c

[Alexander Riccio]

New submission from Alexander Riccio :

At line 138 in debughelpers.c, ssl_obj, which was set to NULL on line 122, is 
dereferenced. 

I think the original intent was to actually bubble the error up through the ssl 
object.



Full function:

static void
_PySSL_keylog_callback(const SSL *ssl, const char *line)
{
PyGILState_STATE threadstate;
PySSLSocket *ssl_obj = NULL;  /* ssl._SSLSocket, borrowed ref */
int res, e;
static PyThread_type_lock *lock = NULL;

threadstate = PyGILState_Ensure();

/* Allocate a static lock to synchronize writes to keylog file.
 * The lock is neither released on exit nor on fork(). The lock is
 * also shared between all SSLContexts although contexts may write to
 * their own files. IMHO that's good enough for a non-performance
 * critical debug helper.
 */
if (lock == NULL) {
lock = PyThread_allocate_lock();
if (lock == NULL) {
PyErr_SetString(PyExc_MemoryError, "Unable to allocate lock");
PyErr_Fetch(_obj->exc_type, _obj->exc_value,
_obj->exc_tb);
return;
}
}

ssl_obj = (PySSLSocket *)SSL_get_app_data(ssl);
assert(PySSLSocket_Check(ssl_obj));
if (ssl_obj->ctx->keylog_bio == NULL) {
return;
}

PySSL_BEGIN_ALLOW_THREADS
PyThread_acquire_lock(lock, 1);
res = BIO_printf(ssl_obj->ctx->keylog_bio, "%s\n", line);
e = errno;
(void)BIO_flush(ssl_obj->ctx->keylog_bio);
PyThread_release_lock(lock);
PySSL_END_ALLOW_THREADS

if (res == -1) {
errno = e;
PyErr_SetFromErrnoWithFilenameObject(PyExc_OSError,
 ssl_obj->ctx->keylog_filename);
PyErr_Fetch(_obj->exc_type, _obj->exc_value, _obj->exc_tb);
}
PyGILState_Release(threadstate);
}

--
assignee: christian.heimes
components: SSL
messages: 365114
nosy: Alexander Riccio, christian.heimes
priority: normal
severity: normal
status: open
title: NULL pointer deref on error path in _ssl debughelpers.c
versions: Python 3.9

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

[issue40076] isoformat function drops microseconds part if its value is 000000

[Alexander Bolshakov]

Change by Alexander Bolshakov :


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

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

[issue40076] isoformat function drops microseconds part if its value is 000000

[Alexander Bolshakov]

New submission from Alexander Bolshakov :

isoformat function does not conform to the ISO 8601 and drops microseconds part 
if its value is 00.

The issue can be reproduced using the following code snippet:

for i in range(1,1000):
 timestamp=datetime.datetime.utcnow().isoformat()
 if len(timestamp)!=26:
 print(timestamp)

--
components: Library (Lib)
messages: 365077
nosy: Alexander Bolshakov
priority: normal
severity: normal
status: open
title: isoformat function drops microseconds part if its value is 00
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

[issue19462] Add remove_argument() method to argparse.ArgumentParser

[Alexander Hirner]

Alexander Hirner  added the comment:

@paul j3
FWIW, popping optionals from a cache that is maintained in addition to 
self._actions, makes special conflict handling unnecessary.

i.e.:
for option_string in a.option_strings:
parser._option_string_actions.pop(option_string)

--
nosy: +cybertreiber

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

[issue40020] growable_comment_array_add leaks, causes crash

[Alexander Riccio]

Change by Alexander Riccio :


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

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

[issue40020] growable_comment_array_add leaks, causes crash

[Alexander Riccio]

Alexander Riccio  added the comment:

Sidenote: visual studio was misleading and made this look like a use-after-free 
for a little while, which was interesting.

--
nosy: +pablogsal

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

[issue40020] growable_comment_array_add leaks, causes crash

[Alexander Riccio]

New submission from Alexander Riccio :

growable_comment_array_add in parsetok.c incorrectly uses realloc, which leaks 
the array when allocation fails, and then causes a null pointer deref crash 
later when the array is freed in growable_comment_array_deallocate (the array 
pointer is dereferenced, passing null to free is fine).

It's unlikely that this codepath is reached in normal use, since type comments 
need to be turned on (via the PyCF_TYPE_COMMENTS compiler flag), but I've 
managed to replicate the issue by injecting faults with Application Verifier. 
It's easiest to cause it to fail with a very large number of type comments, but 
presumably this could also happen with some form of heap fragmentation.

The buggy code is:

static int
growable_comment_array_add(growable_comment_array *arr, int lineno, char 
*comment) {
if (arr->num_items >= arr->size) {
arr->size *= 2;
arr->items = realloc(arr->items, arr->size * sizeof(*arr->items));
if (!arr->items) {
return 0;
}
}

arr->items[arr->num_items].lineno = lineno;
arr->items[arr->num_items].comment = comment;
arr->num_items++;
return 1;
}


and the correct code would be something like:

static int
growable_comment_array_add(growable_comment_array *arr, int lineno, char 
*comment) {
if (arr->num_items >= arr->size) {
arr->size *= 2;
void* new_items_array = realloc(arr->items, arr->size * 
sizeof(*arr->items));
if (!new_items_array) {
return 0;
}
arr->items = new_items_array;
}

arr->items[arr->num_items].lineno = lineno;
arr->items[arr->num_items].comment = comment;
arr->num_items++;
return 1;
}

--
components: Interpreter Core
messages: 364644
nosy: Alexander Riccio, benjamin.peterson
priority: normal
severity: normal
status: open
title: growable_comment_array_add leaks, causes crash
type: crash
versions: Python 3.9

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

[issue25878] CPython on Windows builds with /W3, not /W4

[Alexander Riccio]

Alexander Riccio  added the comment:

Ok, so I finally have some proper time to work on this. How would people (who 
are higher up in python than me, obviously) feel about suppressing most of the 
warnings via a user macro in Visual Studio? I've found that it's quite easy to 
add a macro to the project properties (i.e. pyproject), and have it import into 
the "Disable specific warnings" build options. This keeps our build files 
hand-crafted (let's keep the hipsters happy!), and consistent. By doing this, I 
can get it down to ~100 warnings, which are essentially code that we may want 
to keep an eye on.

The following warnings are essentially always spurious for python. C4100 is
everywhere, and is nearly always benign, but would still require a lot of
careful inspection to determine it its truly on purpose. C4127 is fine since C
doesn't have `constexpr`, let alone `if constexpr`, and it's just easier to
use if statements than  `#ifdef`s everywhere. C4152 is used in every module
exports array. 

C4100 (unreferenced formal parameter) 
https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4100?view=vs-2019
C4115 'type' : named type definition in parentheses 
https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-levels-1-and-4-c4115?view=vs-2019
C4127 conditional expression is constant 
https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4127?view=vs-2019
C4131 'function' : uses old-style declarator 
https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4131?view=vs-2019
C4152 non standard extension, function/data ptr conversion in expression 
https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4152?view=vs-2019

These are usually spurious, since zero-sized arrays are common across the C
world, and is one of several ways of implementing dynamic structs (e.g. unsized
arrays, ANYSIZE_ARRAY, etc...). C4204 and C4221 exist all over the place, and
are probably fine as long as we don't make any lifetime mistakes, which of
course is a solved problem in C. Instances of C4244 should each be individually
inspected carefully since they could be bugs, but there are way too many of
them to allow the warning right now. 

C4200 nonstandard extension used : zero-sized array in struct/union 
https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-levels-2-and-4-c4200?view=vs-2019
C4201 nonstandard extension used : nameless struct/union 
https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4201?view=vs-2019
C4204 nonstandard extension used : non-constant aggregate initializer 
https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4204?view=vs-2019
C4221 nonstandard extension used : 'identifier' : cannot be initialized using 
address of automatic variable 
https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4221?view=vs-2019
C4232 nonstandard extension used : 'identifier' : address of dllimport 
'dllimport' is not static, identity not guaranteed 
https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4232?view=vs-2019
 
C4244 'conversion' conversion from 'type1' to 'type2', possible loss of data 
https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-levels-3-and-4-c4244?view=vs-2019
C4245 'conversion' : conversion from 'type1' to 'type2', signed/unsigned 
mismatch 
https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4245?view=vs-2019


Instances of C4389 should each be individually inspected carefully since they
could be bugs, but there are way too many of them to allow the warning right 
now.

C4389 'operator' : signed/unsigned mismatch 
https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4389?view=vs-2019


Instances of C4456 and C4457 are likely ok given the length of many CPython
functions, but should be inspected for mistakes. There are lots of places
where `i` and such are used as variables, and it's there's no way to know
if the author intended it.
C4456 declaration of 'identifier' hides previous local declaration 
https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4456?view=vs-2019
C4457 declaration of 'identifier' hides function parameter 
https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4457?view=vs-2019


Instances of C4701 occur pretty frequently around code that initializes C
objects with the funky PyArg_ParseTuple format string mechanism, since the
compiler has no built in support for understanding custom format strings.
Personally, I would support zero-initializing these variables. Woul

[issue39970] Combined behavior of datetime.datetime.timestamp() and datetime.datetime.utcnow() on non-UTC timezoned machines

[Alexander Belopolsky]

Change by Alexander Belopolsky :


--
resolution: wont fix -> duplicate

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

[issue39970] Combined behavior of datetime.datetime.timestamp() and datetime.datetime.utcnow() on non-UTC timezoned machines

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

This is a duplicate of issue 33293.

--
superseder:  -> Using datetime.datetime.utcnow().timestamp() in Python3.6.0 
can't get correct UTC timestamp.

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

[issue39970] Combined behavior of datetime.datetime.timestamp() and datetime.datetime.utcnow() on non-UTC timezoned machines

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

I am sure this has been reported before – I will try to find the relevant 
issue.  This behavior is correct and documented.  The only improvement that we 
can consider is to make it more explicit that utcnow is deprecated and the 
correct way to obtain the UTC timestamp is

datetime.now(timezone.utc).timestamp()

--

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

[issue31652] make install fails: no module _ctypes

[Alexander Stohr]

Alexander Stohr  added the comment:

Ubuntu 16.04 in a very bare naked setup.
Similar/same problem profile by message and other lines in the log.
Installed libffi6 and libffi-dev => worked.

Not sure if both were needed (or interdependent, 2nd to 1st).

--
nosy: +Alexander Stohr

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

[issue26460] datetime.strptime without a year fails on Feb 29

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

> On Mar 2, 2020, at 6:33 PM, Gregory P. Smith  wrote:
> 
> Change that default to any old year with a leap year (1904?)

In the 21st century, the year 2000 default makes much more sense than 1900. 
Luckily 2000 is also a leap year.

--

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

[issue39680] datetime.astimezone() method does not handle invalid local times as required by PEP 495

[Alexander Belopolsky]

New submission from Alexander Belopolsky :

Let g be a an invalid time in New York spring-forward gap:

>>> g = datetime(2020, 3, 8, 2, 30)

According to PEP 495, conversion of such instance to UTC should return a value 
that corresponds to a valid local time greater than g, but

>>> print(g.astimezone(timezone.utc).astimezone())
2020-03-08 01:30:00-05:00

Also, conversion of the same instance with fold=1 to UTC and back should 
produce a lesser time, but

>>> print(g.replace(fold=1).astimezone(timezone.utc).astimezone())
2020-03-08 03:30:00-04:00

Note that conversion to and from timestamp works correctly:

>>> print(datetime.fromtimestamp(g.timestamp()))
2020-03-08 03:30:00
>>> print(datetime.fromtimestamp(g.replace(fold=1).timestamp()))
2020-03-08 01:30:00

--
assignee: belopolsky
messages: 362241
nosy: belopolsky, p-ganssle
priority: normal
severity: normal
status: open
title: datetime.astimezone() method does not handle invalid local times as 
required by PEP 495
type: behavior
versions: Python 3.9

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

[issue39549] The reprlib.Repr type should permit the “fillvalue” to be set by the user

[Alexander Böhn]

Change by Alexander Böhn :


--
components: +Tests

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