[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys
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 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
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 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 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 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 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 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 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
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-
[issue45932] EmailMessage incorrectly splits name and address header
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
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
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 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 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
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
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 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 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 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 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 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
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 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 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 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 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
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 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)
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 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
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 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 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 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 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
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
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 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 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 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 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 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
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
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 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
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
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 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 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
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
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 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 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
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 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 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 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
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
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 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
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 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 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 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
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 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 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
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 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 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
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
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
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
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
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( &NewWaitObject, 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 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
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
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
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&t=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 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 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 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 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
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=...} ...} }
[issue40079] NULL pointer deref on error path in _ssl debughelpers.c
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(&ssl_obj->exc_type, &ssl_obj->exc_value, &ssl_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(&ssl_obj->exc_type, &ssl_obj->exc_value, &ssl_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
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
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 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
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 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
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 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_ParseTu
[issue39970] Combined behavior of datetime.datetime.timestamp() and datetime.datetime.utcnow() on non-UTC timezoned machines
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 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 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 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 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
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
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