? >>> dom.toxml() '

\n\n\n

' # No Text nodes in the root list :(. >>> dom.childNodes [, , ] # But they all exist fine under

. >>> dom.childNodes[2].childNodes [, , , , ] ---------- components: XML messages: 380872 nosy: vapier priority: normal severity: normal status: open title: xml.dom.minidom parsing omits Text nodes in top level versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 05:23:37 2020 From: report at bugs.python.org (Ed Catmur) Date: Fri, 13 Nov 2020 10:23:37 +0000 Subject: [New-bugs-announce] [issue42342] asyncio.open_connection(local_addr=('localhost', port)) fails with TypeError: AF_INET address must be a pair (host, port) Message-ID: <1605263017.45.0.821115077968.issue42342@roundup.psfhosted.org> New submission from Ed Catmur : Context: CentOS 7.8.2003, Python 3.8 from SCL. localhost has IPv4 and IPv6 bindings, IPv6 first: $ python -c "import socket;print(socket.getaddrinfo('localhost',0,type=socket.SOCK_STREAM))" [(, , 6, '', ('::1', 0, 0, 0)), (, , 6, '', ('127.0.0.1', 0))] import asyncio async def main(): await asyncio.open_connection('localhost', 9990, local_addr=('localhost', 9991)) asyncio.run(main()) Traceback (most recent call last): File "async.py", line 4, in asyncio.run(main()) File "/opt/rh/rh-python38/root/usr/lib64/python3.8/asyncio/runners.py", line 43, in run return loop.run_until_complete(main) File "/opt/rh/rh-python38/root/usr/lib64/python3.8/asyncio/base_events.py", line 608, in run_until_complete return future.result() File "async.py", line 3, in main await asyncio.open_connection('10.10.10.10', 9990, local_addr=('localhost', 9991)) File "/opt/rh/rh-python38/root/usr/lib64/python3.8/asyncio/streams.py", line 52, in open_connection transport, _ = await loop.create_connection( File "/opt/rh/rh-python38/root/usr/lib64/python3.8/asyncio/base_events.py", line 1002, in create_connection sock = await self._connect_sock( File "/opt/rh/rh-python38/root/usr/lib64/python3.8/asyncio/base_events.py", line 904, in _connect_sock sock.bind(laddr) TypeError: AF_INET address must be a pair (host, port) It looks like this has a similar root cause to issue 35302 - we should be filtering local addrinfos by family for valid combinations. ---------- components: asyncio messages: 380874 nosy: asvetlov, ecatmur2, yselivanov priority: normal severity: normal status: open title: asyncio.open_connection(local_addr=('localhost', port)) fails with TypeError: AF_INET address must be a pair (host, port) type: behavior versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 06:17:53 2020 From: report at bugs.python.org (Antti Haapala) Date: Fri, 13 Nov 2020 11:17:53 +0000 Subject: [New-bugs-announce] [issue42343] threading.local documentation should be on the net... Message-ID: <1605266273.51.0.273989729799.issue42343@roundup.psfhosted.org> New submission from Antti Haapala : The current documentation of `thread.local` is ---- Thread-Local Data Thread-local data is data whose values are thread specific. To manage thread-local data, just create an instance of local (or a subclass) and store attributes on it: mydata = threading.local() mydata.x = 1 The instance?s values will be different for separate threads. class threading.local A class that represents thread-local data. For more details and extensive examples, see the documentation string of the _threading_local module. ---- There is no link to the `_threading_local` module docs in the documentation and none of the content from the modules docstrings appear anywhere on docs.python.org website. This is rather annoying because the docstring contains completely non-trivial information including that threading.local can be subclassed and that the __init__ will be run once for each thread for each instance where attributes are accessed. ---------- assignee: docs at python components: Documentation messages: 380875 nosy: docs at python, ztane priority: normal severity: normal status: open title: threading.local documentation should be on the net... type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 08:42:06 2020 From: report at bugs.python.org (=?utf-8?q?J=C3=BCrgen_Gmach?=) Date: Fri, 13 Nov 2020 13:42:06 +0000 Subject: [New-bugs-announce] [issue42344] SimpleNamespace: update documentation regarding comparison Message-ID: <1605274926.75.0.147847269171.issue42344@roundup.psfhosted.org> New submission from J?rgen Gmach : When tinkering around with `SimpleNamespace` I tried to figure out the reasons for using it over just the `class NS: pass` alternative. One reason is the comparison, which is not a plain `id` comparison, but an attribute comparison. When looking at the documentation of the imaginary python implementation, where only dicts are compared, the reader (me) could think you can compare it to classes. https://docs.python.org/3/library/types.html?highlight=simplenamespace#types.SimpleNamespace ``` >>> from types import SimpleNamespace >>> simple_ns = SimpleNamespace(a=1, b="two") >>> class NS: pass >>> class_ns = NS() >>> class_ns.a = 1 >>> class_ns.b = "two" >>> simple_ns == class_ns >>> False ``` Actually, the C implementation compares the types, too. https://github.com/python/cpython/blob/bc777047833256bc6b10b2c7b46cce9e9e6f956c/Objects/namespaceobject.c#L163-L171 While the documentation says the Python impl is "roughly equivalent", I's still suggest to update the documentation. If there is some agreement, I'd create a pull request. ---------- messages: 380882 nosy: jugmac00 priority: normal severity: normal status: open title: SimpleNamespace: update documentation regarding comparison _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 09:11:55 2020 From: report at bugs.python.org (Dominik V.) Date: Fri, 13 Nov 2020 14:11:55 +0000 Subject: [New-bugs-announce] [issue42345] Equality of typing.Literal depends on the order of arguments Message-ID: <1605276715.65.0.853257843244.issue42345@roundup.psfhosted.org> New submission from Dominik V. : [PEP 586](https://www.python.org/dev/peps/pep-0586/#shortening-unions-of-literals) specifies that Literal[v1, v2, v3] is equivalent to Union[Literal[v1], Literal[v2], Literal[v3]] Since the equality of Unions doesn't take into account the order of arguments, Literals parametrized with multiple arguments should not be order dependent either. However they seem to: >>> Literal[1, 2] == Literal[2, 1] False Compare with the equivalent form: >>> Union[Literal[1], Literal[2]] == Union[Literal[2], Literal[1]] True In addition to that, the PEP specifies that nested Literals should be equivalent to the flattened version (https://www.python.org/dev/peps/pep-0586/#legal-parameters-for-literal-at-type-check-time). This section is titled "Legal parameters for Literal at type check time" but since the PEP doesn't specify runtime behavior differently, I think it makes sense to assume it is the same. It seems to be different though: >>> Literal[Literal[1, 2], 3] typing.Literal[typing.Literal[1, 2], 3] >>> Literal[Literal[1, 2], 3] == Literal[1, 2, 3] False Also the flattening follows from the above definition `Literal[v1, v2, v3] == Union[Literal[v1], Literal[v2], Literal[v3]]` and the fact that Unions are flattened. ---------- messages: 380888 nosy: Dominik V. priority: normal severity: normal status: open title: Equality of typing.Literal depends on the order of arguments type: behavior versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 09:23:09 2020 From: report at bugs.python.org (STINNER Victor) Date: Fri, 13 Nov 2020 14:23:09 +0000 Subject: [New-bugs-announce] [issue42346] [subinterpreters] Deny os.fork() in subinterpreters? Message-ID: <1605277389.1.0.366726177524.issue42346@roundup.psfhosted.org> New submission from STINNER Victor : _PyInterpreterState_DeleteExceptMain() contains the following check: PyThreadState *tstate = _PyThreadState_Swap(gilstate, NULL); if (tstate != NULL && tstate->interp != runtime->interpreters->main) { return _PyStatus_ERR("not main interpreter"); } os.fork() is allow in subinterpreters and PyOS_AfterFork_Child() doesn't seem to update runtime->interpreters->main. Either we should update runtime->interpreters->main after fork in the child process, or os.fork() should be denied in subinterpreters. In bpo-37266, I denied the creation of daemon threads in subinterpreters. But I had to revert this change: see bpo-40234. ---------- components: Subinterpreters messages: 380891 nosy: vstinner priority: normal severity: normal status: open title: [subinterpreters] Deny os.fork() in subinterpreters? versions: Python 3.10 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 09:54:33 2020 From: report at bugs.python.org (Ash Holland) Date: Fri, 13 Nov 2020 14:54:33 +0000 Subject: [New-bugs-announce] [issue42347] loop.call_exception_handler documentation is lacking Message-ID: <1605279273.64.0.105745281435.issue42347@roundup.psfhosted.org> New submission from Ash Holland : The call_exception_handler documentation lists seven permissible context keys, but the docstring lists nine, and there are two keys referred to in the default_exception_handler implementation that aren't listed in either. The docstring (but not the documentation) mentions "task" ("Task instance") and "asyncgen" ("Asynchronous generator that caused the exception."), though at least "asyncgen" doesn't appear to be used in any exception handler in stdlib as far as I can tell. No documentation mentions "source_traceback" or "handle_traceback", but they're used by the default exception handler and are also provided by e.g. aiohttp: https://github.com/aio-libs/aiohttp/blob/a8d9ec3f1667463e80545b1cacc7833d1ff305e9/aiohttp/client_reqrep.py#L750 ---------- assignee: docs at python components: Documentation, asyncio messages: 380895 nosy: asvetlov, docs at python, sorrel, yselivanov priority: normal severity: normal status: open title: loop.call_exception_handler documentation is lacking type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 10:38:16 2020 From: report at bugs.python.org (Batuhan Taskaya) Date: Fri, 13 Nov 2020 15:38:16 +0000 Subject: [New-bugs-announce] [issue42348] Language Reference: Set items Message-ID: <1605281896.65.0.701198414223.issue42348@roundup.psfhosted.org> New submission from Batuhan Taskaya : The data types section of the language reference (https://docs.python.org/3.10/reference/datamodel.html#the-standard-type-hierarchy) has this description directly under the Set type (which has 2 childs, set and frozenset). > These represent unordered, finite sets of unique, immutable objects. I feel like this wording is a bit confusing, considering the items doesn't have to be immutable at all. Can we replace this with hashable? ---------- messages: 380901 nosy: BTaskaya priority: normal severity: normal status: open title: Language Reference: Set items _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 12:23:56 2020 From: report at bugs.python.org (Mark Shannon) Date: Fri, 13 Nov 2020 17:23:56 +0000 Subject: [New-bugs-announce] [issue42349] Compiler front-end produces a broken CFG Message-ID: <1605288236.63.0.535930114151.issue42349@roundup.psfhosted.org> New submission from Mark Shannon : The front-end of the bytecode compiler produces a broken CFG. A number of "basic-block"s have terminators before their end. This makes the back-end optimizations unsafe as they rely of a well-formed CFG. The fix is simple. Insert a check that the CFG is well-formed before doing any optimizations, then fix up the front-end. Once done, we can be more aggressive with optimizations without worrying that things will break for no apparent reason. ---------- assignee: Mark.Shannon messages: 380911 nosy: BTaskaya, Mark.Shannon, pablogsal, yselivanov priority: normal severity: normal status: open title: Compiler front-end produces a broken CFG type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 12:51:36 2020 From: report at bugs.python.org (STINNER Victor) Date: Fri, 13 Nov 2020 17:51:36 +0000 Subject: [New-bugs-announce] [issue42350] Calling os.fork() at Python exit logs: AttributeError: 'NoneType' object has no attribute '_at_fork_reinit' Message-ID: <1605289896.09.0.326897860295.issue42350@roundup.psfhosted.org> New submission from STINNER Victor : The following code logs an error: --- Exception ignored in: Traceback (most recent call last): File "/home/vstinner/python/master/Lib/threading.py", line 1508, in _after_fork thread._reset_internal_locks(True) File "/home/vstinner/python/master/Lib/threading.py", line 847, in _reset_internal_locks self._tstate_lock._at_fork_reinit() AttributeError: 'NoneType' object has no attribute '_at_fork_reinit' --- Code: --- #!/usr/bin/python3 import atexit import subprocess def preexec(): pass def exit_handler(): proc = subprocess.Popen( ["pwd"], preexec_fn=preexec, ) proc.communicate() if __name__ == "__main__": atexit.register(exit_handler) --- It is a regression caused by the following bpo-40089 fix: commit 87255be6964979b5abdc4b9dcf81cdcfdad6e753 Author: Victor Stinner Date: Tue Apr 7 23:11:49 2020 +0200 bpo-40089: Add _at_fork_reinit() method to locks (GH-19195) ---------- components: Library (Lib) messages: 380912 nosy: vstinner priority: normal severity: normal status: open title: Calling os.fork() at Python exit logs: AttributeError: 'NoneType' object has no attribute '_at_fork_reinit' versions: Python 3.10, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 12:59:24 2020 From: report at bugs.python.org (E. Paine) Date: Fri, 13 Nov 2020 17:59:24 +0000 Subject: [New-bugs-announce] [issue42351] Setup.py: UnicodeDecodeError in grep_headers_for Message-ID: <1605290364.26.0.484718067569.issue42351@roundup.psfhosted.org> New submission from E. Paine : When compiling the master branch (i.e. running 'make'), I get a UnicodeDecodeError as follows: Traceback (most recent call last): File "/home/elisha/Documents/Python/cp0/cpython/./setup.py", line 2619, in main() File "/home/elisha/Documents/Python/cp0/cpython/./setup.py", line 2589, in main setup(# PyPI Metadata (PEP 301) File "/home/elisha/Documents/Python/cp0/cpython/Lib/distutils/core.py", line 148, in setup dist.run_commands() File "/home/elisha/Documents/Python/cp0/cpython/Lib/distutils/dist.py", line 966, in run_commands self.run_command(cmd) File "/home/elisha/Documents/Python/cp0/cpython/Lib/distutils/dist.py", line 985, in run_command cmd_obj.run() File "/home/elisha/Documents/Python/cp0/cpython/Lib/distutils/command/build.py", line 135, in run self.run_command(cmd_name) File "/home/elisha/Documents/Python/cp0/cpython/Lib/distutils/cmd.py", line 313, in run_command self.distribution.run_command(command) File "/home/elisha/Documents/Python/cp0/cpython/Lib/distutils/dist.py", line 985, in run_command cmd_obj.run() File "/home/elisha/Documents/Python/cp0/cpython/Lib/distutils/command/build_ext.py", line 340, in run self.build_extensions() File "/home/elisha/Documents/Python/cp0/cpython/./setup.py", line 471, in build_extensions self.detect_modules() File "/home/elisha/Documents/Python/cp0/cpython/./setup.py", line 1825, in detect_modules self.detect_ctypes() File "/home/elisha/Documents/Python/cp0/cpython/./setup.py", line 2205, in detect_ctypes if grep_headers_for('ffi_prep_cif_var', ffi_headers): File "/home/elisha/Documents/Python/cp0/cpython/./setup.py", line 246, in grep_headers_for if function in f.read(): File "/home/elisha/Documents/Python/cp0/cpython/Lib/codecs.py", line 322, in decode (result, consumed) = self._buffer_decode(data, self.errors, final) UnicodeDecodeError: 'utf-8' codec can't decode byte 0x92 in position 4210: invalid start byte The problematic file it is trying to read is /usr/include/OMX_Other.h which is part of the libomxil-bellagio package (a copy of this package can be downloaded from https://www.archlinux.org/packages/extra/x86_64/libomxil-bellagio/download/). More specifically, there are several characters in the comments which cannot be decoded correctly (the first of these is on line 93). The fix is a very simple one and is just to add errors='replace' to line 244 of setup.py (I cannot see this having any ill-effects). I couldn't find who to nosy for this so apologies about that. ---------- components: Build messages: 380913 nosy: epaine priority: normal severity: normal status: open title: Setup.py: UnicodeDecodeError in grep_headers_for type: compile error versions: Python 3.10, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 13:47:56 2020 From: report at bugs.python.org (Ross Barnowski) Date: Fri, 13 Nov 2020 18:47:56 +0000 Subject: [New-bugs-announce] [issue42352] A string representation of slice objects with colon syntax Message-ID: <1605293276.23.0.88839506976.issue42352@roundup.psfhosted.org> New submission from Ross Barnowski : It would be nice if there were a way to get a string representation of a slice object in extended indexing syntax, e.g. ``` >>> myslice = slice(None, None, 2) >>> print(myslice) '::2' ``` One motivating use-case is in descriptive error messages, e.g. ``` TypeError(f"Can't slice {myobj}, try list({myobj})[{myslice}]") ``` In this case, it is much more natural for `myslice` to use the extended indexing syntax than the slice str/repr. Perhaps this could be done via __str__, or if that is too big a change, maybe via __format__ e.g. `f"{myslice:asidx}"` It's simple enough to write a conversion function, but this feels like a feature that would fit best upstream. I searched the issue tracker, PRs on GitHub, and the Python documentation and didn't see any related issues/PRs/articles. xref: https://github.com/networkx/networkx/pull/4304 ---------- messages: 380921 nosy: rossbar priority: normal severity: normal status: open title: A string representation of slice objects with colon syntax type: enhancement versions: Python 3.10 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 14:27:03 2020 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 13 Nov 2020 19:27:03 +0000 Subject: [New-bugs-announce] [issue42353] Proposal: re.prefixmatch method (alias for re.match) Message-ID: <1605295623.12.0.914188426549.issue42353@roundup.psfhosted.org> New submission from Gregory P. Smith : A well known anti-pattern in Python is use of re.match when you meant to use re.search. re.fullmatch was added in 3.4 via https://bugs.python.org/issue16203 for similar reasons. re.prefixmatch would be similar: we want the re.match behavior, but want the code to be obvious about its intent. This documents the implicit ^ in the name. The goal would be to allow linters to ultimately flag re.match as the anti-pattern when in 3.10+ mode. Asking people to use re.prefixmatch or re.search instead. This would help avoid bugs where people mean re.search but write re.match. The implementation is trivial. This is **not** a decision to deprecate the widely used in 25 years worth of code's re.match name. That'd be painful and is unlikely to be worth doing without spreading it over a 8+ year timeline. ---------- components: Library (Lib) messages: 380928 nosy: gregory.p.smith priority: normal severity: normal stage: needs patch status: open title: Proposal: re.prefixmatch method (alias for re.match) type: enhancement versions: Python 3.10 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 13 15:00:30 2020 From: report at bugs.python.org (Trey Hunner) Date: Fri, 13 Nov 2020 20:00:30 +0000 Subject: [New-bugs-announce] [issue42354] Tuple unpacking with * causes SyntaxError in with ... as ... Message-ID: <1605297630.46.0.898037335486.issue42354@roundup.psfhosted.org> New submission from Trey Hunner : The below code worked on Python 3.5, 3.6, 3.7, and 3.8, but it now crashes on Python 3.9. from contextlib import contextmanager @contextmanager def open_files(names): yield names # This would actually return file objects with open_files(['file1.txt', 'file2.txt']) as (first, *rest): print(first, rest) The error shown is: with open_files(['file1.txt', 'file2.txt']) as (first, *rest): ^ SyntaxError: invalid syntax ---------- messages: 380932 nosy: trey priority: normal severity: normal status: open title: Tuple unpacking with * causes SyntaxError in with ... as ... type: behavior versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 05:27:36 2020 From: report at bugs.python.org (Batuhan Taskaya) Date: Sat, 14 Nov 2020 10:27:36 +0000 Subject: [New-bugs-announce] [issue42355] symtable: get_namespace doesn't check whether if there are multiple namespaces or no namespaces at all Message-ID: <1605349656.21.0.301673967264.issue42355@roundup.psfhosted.org> New submission from Batuhan Taskaya : >>> table = symtable.symtable("A = 1", "", "exec") >>> table.lookup("A") >>> table.lookup("A").get_namespace() Traceback (most recent call last): File "", line 1, in File "/usr/local/lib/python3.10/symtable.py", line 312, in get_namespace raise ValueError("name is bound to multiple namespaces") ValueError: name is bound to multiple namespaces >>> table.lookup("A").get_namespaces() () ---------- assignee: BTaskaya components: Library (Lib) messages: 380969 nosy: BTaskaya, benjamin.peterson priority: normal severity: normal status: open title: symtable: get_namespace doesn't check whether if there are multiple namespaces or no namespaces at all versions: Python 3.10 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 06:36:46 2020 From: report at bugs.python.org (Tomek H) Date: Sat, 14 Nov 2020 11:36:46 +0000 Subject: [New-bugs-announce] [issue42356] Dict inline manipulations Message-ID: <1605353806.22.0.174145034354.issue42356@roundup.psfhosted.org> New submission from Tomek H : With Python3.9 there is a great feature for merging `dict`s: {1: 'a'} | {2: 'b'} => {1: 'a', 2: 'b'} It would be very handy to filter out a dict with a similar fashion (for example & operator with a list/tuple/frozenset of keys you want to get back): {1: 'a', 2: 'b', 3: 'c'} & [1, 3, 4] == {1: 'a', 3: 'c'} {1: 'a', 2: 'b', 3: 'c'} & {1, 3, 4} == {1: 'a', 3: 'c'} Also, omitting specified keys (for example - operator with a list/tuple/frozenset of keys you want to suppress): {1: 'a', 2: 'b', 3: 'c'} - [3, 4] == {1: 'a', 2: 'b'} {1: 'a', 2: 'b', 3: 'c'} - {3, 4} == {1: 'a', 2: 'b'} Regards! ---------- components: Interpreter Core messages: 380972 nosy: tomek.hlawiczka priority: normal severity: normal status: open title: Dict inline manipulations type: enhancement versions: Python 3.10 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 10:36:37 2020 From: report at bugs.python.org (Maiyun Zhang) Date: Sat, 14 Nov 2020 15:36:37 +0000 Subject: [New-bugs-announce] [issue42357] Wrong Availability for signal.SIGCHLD Message-ID: <1605368197.47.0.575674573541.issue42357@roundup.psfhosted.org> New submission from Maiyun Zhang : The availability for `signal.SIGCHLD` is not correct. This seems to be present since Python 3.7 ---------- assignee: docs at python components: Documentation messages: 380981 nosy: docs at python, myzhang1029 priority: normal severity: normal status: open title: Wrong Availability for signal.SIGCHLD versions: Python 3.10 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 15:01:41 2020 From: report at bugs.python.org (Dennis Clarke) Date: Sat, 14 Nov 2020 20:01:41 +0000 Subject: [New-bugs-announce] [issue42358] Python 3.9.0 unable to detect ax_cv_c_float_words_bigendian value on nigendan system Message-ID: <1605384101.77.0.568061256015.issue42358@roundup.psfhosted.org> New submission from Dennis Clarke : Seems related to issue42173 where the idea on the table was, simply to drop Solaris support and to quote Mr Stinner to "let the code slowly die". Regardless of this sort of neglect there are people who do try to use Python on big endian risc systems such as Solaris or Debian Linux in fact. Wherein a trivial configure reveals : alpha$ ../Python-3.9.0/configure --prefix=/opt/bw \ > --enable-shared --disable-optimizations \ > --enable-loadable-sqlite-extensions \ > --enable-ipv6 --with-pydebug --without-dtrace \ > --with-openssl=/opt/bw --with-ssl-default-suites=openssl \ > --without-gcc configure: WARNING: unrecognized options: --without-gcc checking build system type... sparc-sun-solaris2.10 checking host system type... sparc-sun-solaris2.10 checking for python3.9... no checking for python3... python3 checking for --enable-universalsdk... no checking for --with-universal-archs... no checking MACHDEP... "sunos5" checking for gcc... /opt/developerstudio12.6/bin/cc -std=iso9899:2011 -m64 -xarch=sparc -g -errfmt=error -errshort=full -xstrconst -xildoff -xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc -ftrap=%none -xbuiltin=%none -xunroll=1 -xs -xdebugformat=dwarf -errtags=yes -errwarn=%none -erroff=%none -L/opt/bw/lib -R/opt/bw/lib checking whether the C compiler works... yes . . . checking for __fpu_control... no checking for __fpu_control in -lieee... no checking for --with-libm=STRING... default LIBM="-lm" checking for --with-libc=STRING... default LIBC="" checking for x64 gcc inline assembler... no checking whether float word ordering is bigendian... unknown configure: error: Unknown float word ordering. You need to manually preset ax_cv_c_float_words_bigendian=no (or yes) according to your system. So it seems that the m4/ax_c_float_words_bigendian.m4 needs to be manually hacked or the configure script itself is at fault. I will give this a try on big endian IBM Power and also IBM Power9 ppc64le as well as FreeBSD running in RISC-V rv64imafdc little endian and see what happens. I suspect that the little endian systems will be no great concern as the bulk of Python devs seem to have never seen anything else other than little endian systems running Red Hat. To hack around this floating point endian test with blunt force : alpha$ alpha$ diff -u configure.orig configure --- configure.orig Mon Oct 5 15:07:58 2020 +++ configure Sat Nov 14 19:37:13 2020 @@ -14425,7 +14425,7 @@ else -ax_cv_c_float_words_bigendian=unknown +ax_cv_c_float_words_bigendian=yes cat confdefs.h - <<_ACEOF >conftest.$ac_ext /* end confdefs.h. */ @@ -14442,9 +14442,9 @@ fi if $GREP seesnoon conftest.$ac_objext >/dev/null ; then if test "$ax_cv_c_float_words_bigendian" = unknown; then - ax_cv_c_float_words_bigendian=no + ax_cv_c_float_words_bigendian=yes else - ax_cv_c_float_words_bigendian=unknown + ax_cv_c_float_words_bigendian=yes fi fi alpha$ alpha$ diff -u m4/ax_c_float_words_bigendian.m4.orig m4/ax_c_float_words_bigendian.m4 --- m4/ax_c_float_words_bigendian.m4.orig Mon Oct 5 15:07:58 2020 +++ m4/ax_c_float_words_bigendian.m4 Sat Nov 14 19:35:44 2020 @@ -42,7 +42,7 @@ [AC_CACHE_CHECK(whether float word ordering is bigendian, ax_cv_c_float_words_bigendian, [ -ax_cv_c_float_words_bigendian=unknown +ax_cv_c_float_words_bigendian=yes AC_COMPILE_IFELSE([AC_LANG_SOURCE([[ double d = 90904234967036810337470478905505011476211692735615632014797120844053488865816695273723469097858056257517020191247487429516932130503560650002327564517570778480236724525140520121371739201496540132640109977779420565776568942592.0; @@ -54,9 +54,9 @@ fi if $GREP seesnoon conftest.$ac_objext >/dev/null ; then if test "$ax_cv_c_float_words_bigendian" = unknown; then - ax_cv_c_float_words_bigendian=no + ax_cv_c_float_words_bigendian=yes else - ax_cv_c_float_words_bigendian=unknown + ax_cv_c_float_words_bigendian=yes fi fi alpha$ This is a hack of course and it gets past the endian test sickness. Shortly thereafter the compile fails due to a trivial C99 code problem : /opt/developerstudio12.6/bin/cc -std=iso9899:2011 -m64 -xarch=sparc -g -errfmt=error -errshort=full -xstrconst -xildoff -xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc -ftrap=%none -xbuiltin=%none -xunroll=1 -xs -xdebugformat=dwarf -errtags=yes -errwarn=%none -erroff=%none -L/opt/bw/lib -R/opt/bw/lib -c -O -std=iso9899:2011 -m64 -xarch=sparc -g -errfmt=error -errshort=full -xstrconst -xildoff -xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc -ftrap=%none -xbuiltin=%none -xunroll=1 -xs -xdebugformat=dwarf -errtags=yes -errwarn=%none -erroff=%none -L/opt/bw/lib -R/opt/bw/lib -D_REENTRANT -std=iso9899:2011 -m64 -xarch=sparc -g -errfmt=error -errshort=full -xstrconst -xildoff -xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc -ftrap=%none -xbuiltin=%none -xunroll=1 -xs -xdebugformat=dwarf -errtags=yes -errwarn=%none -erroff=%none -L/opt/bw/lib -R/opt/bw/lib -I../Python-3.9.0/Include/internal -IObjects -IInclude -IPython -I. -I../Python-3.9.0/Include -I/opt/bw/include -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -I/opt/bw/include -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -xcode=pic32 -DPy_BUILD_CORE -o Objects/exceptions.o ../Python-3.9.0/Objects/exceptions.c "../Python-3.9.0/Objects/exceptions.c", line 2313: error: void function cannot return value cc: acomp failed for ../Python-3.9.0/Objects/exceptions.c gmake: *** [Makefile:1781: Objects/exceptions.o] Error 2 However that is a separate issue that has been around for at least a year or so. 2313 return Py_TYPE(self)->tp_free((PyObject *)self); ??? Why try to return anything here ? Why can we not do the same as line 2319 ? 2306 2307 static void 2308 MemoryError_dealloc(PyBaseExceptionObject *self) 2309 { 2310 BaseException_clear(self); 2311 2312 if (!Py_IS_TYPE(self, (PyTypeObject *) PyExc_MemoryError)) { 2313 Py_TYPE(self)->tp_free((PyObject *)self); 2314 } 2315 2316 _PyObject_GC_UNTRACK(self); 2317 2318 if (memerrors_numfree >= MEMERRORS_SAVE) 2319 Py_TYPE(self)->tp_free((PyObject *)self); 2320 else { 2321 self->dict = (PyObject *) memerrors_freelist; 2322 memerrors_freelist = self; 2323 memerrors_numfree++; 2324 } 2325 } 2326 The compile may then continue but eventually a bucket of tests fail. Perhaps an Oracle/Fujitsu SPARC based built bot or site would help here? -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ---------- components: Installation messages: 380987 nosy: blastwave priority: normal severity: normal status: open title: Python 3.9.0 unable to detect ax_cv_c_float_words_bigendian value on nigendan system versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 14 20:20:28 2020 From: report at bugs.python.org (Andy Harrington) Date: Sun, 15 Nov 2020 01:20:28 +0000 Subject: [New-bugs-announce] [issue42359] tutorial: list is a class Message-ID: <1605403228.0.0.0141370845785.issue42359@roundup.psfhosted.org> New submission from Andy Harrington : Documentation in Tutorial section 9.3.3 seems to be stuck in Python 2: "In Python, the term method is not unique to class instances: other object types can have methods as well. For example, list objects have methods called append, insert, remove, sort, and so on." In Python 3 built-in types are derived from Object, so list is now a class, right? ---------- assignee: docs at python components: Documentation messages: 380997 nosy: andyharrington, docs at python priority: normal severity: normal status: open title: tutorial: list is a class versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 15 04:14:25 2020 From: report at bugs.python.org (Alejandro Gonzalez) Date: Sun, 15 Nov 2020 09:14:25 +0000 Subject: [New-bugs-announce] [issue42360] In the namedtuple documentation, mention that typename should match the variable name for the class to be pickle-able Message-ID: <1605431665.76.0.57179948955.issue42360@roundup.psfhosted.org> New submission from Alejandro Gonzalez : I think the namedtuple documentation should mention that, for classes created with it to be pickle-able, the typename argument must match the name of the variable the class is being assigned to. Otherwise you get an error like this: ---------------------------------------------- >>> Foo = namedtuple("Bar", "x,y") >>> pickle.dumps(Foo(1, 2)) Traceback (most recent call last): File "", line 1, in _pickle.PicklingError: Can't pickle : attribute lookup Bar on __main__ failed ---------------------------------------------- While it is indeed odd to do such naming in the first place, it should be admissible in other circumstances not involving pickling, and it is not obvious that pickling won't work if you do so. The pickle documentation does mention this, though: [...]Similarly, classes are pickled by named reference, so the same restrictions in the unpickling environment apply.[...] but for someone who encounters this error it might be difficult to figure it out from that passage. The added documentation in namedtuple could include a pointer to that section of pickle's documentation. ---------- assignee: docs at python components: Documentation messages: 381007 nosy: alegonz, docs at python priority: normal severity: normal status: open title: In the namedtuple documentation, mention that typename should match the variable name for the class to be pickle-able type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 15 07:29:16 2020 From: report at bugs.python.org (Ronald Oussoren) Date: Sun, 15 Nov 2020 12:29:16 +0000 Subject: [New-bugs-announce] [issue42361] Use Tcl/Tk 8.6.10 in build-installer.py when building on recent macOS Message-ID: <1605443356.85.0.637246166587.issue42361@roundup.psfhosted.org> New submission from Ronald Oussoren : As discussed before we want to switch to Tcl/Tk 8.6.10 when building the installer on a recent version of macOS. The build on macOS 10.9 should continue to use 8.6.8 due to build issues. PR is forthcoming (currently running tests) ---------- assignee: ronaldoussoren components: Tkinter, macOS messages: 381014 nosy: ned.deily, ronaldoussoren priority: normal severity: normal stage: needs patch status: open title: Use Tcl/Tk 8.6.10 in build-installer.py when building on recent macOS type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 15 09:39:28 2020 From: report at bugs.python.org (Ronald Oussoren) Date: Sun, 15 Nov 2020 14:39:28 +0000 Subject: [New-bugs-announce] [issue42362] Switch to clang as default compiler in build-installer.py Message-ID: <1605451168.78.0.88186037593.issue42362@roundup.psfhosted.org> New submission from Ronald Oussoren : build-installer.py still defaults to gcc as the default compiler, even though clang has been the system compiler for ages (and gcc is an alias in anything remotely recent). PR is forthcoming ---------- assignee: ronaldoussoren components: macOS messages: 381015 nosy: ned.deily, ronaldoussoren priority: normal severity: normal stage: needs patch status: open title: Switch to clang as default compiler in build-installer.py type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 15 10:51:14 2020 From: report at bugs.python.org (Jim Lin) Date: Sun, 15 Nov 2020 15:51:14 +0000 Subject: [New-bugs-announce] [issue42363] I think it will be better to output self._state for debugging Message-ID: <1605455474.5.0.172346256047.issue42363@roundup.psfhosted.org> New submission from Jim Lin : I think the exception "raise ValueError("Pool not running")" is not easy for a programmer to quickly know the problem of their code. Therefore, I add the value of self._state when throwing the ValueError. ---------- components: Library (Lib) messages: 381016 nosy: jimlinntu priority: normal severity: normal status: open title: I think it will be better to output self._state for debugging versions: Python 3.10 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 15 18:14:56 2020 From: report at bugs.python.org (Mathias MICHEL) Date: Sun, 15 Nov 2020 23:14:56 +0000 Subject: [New-bugs-announce] [issue42364] Typo in french doc translation Message-ID: <1605482096.39.0.136403894956.issue42364@roundup.psfhosted.org> New submission from Mathias MICHEL : In https://docs.python.org/fr/3/tutorial/inputoutput.html, ? 7.1.3. Formatage de cha?nes ? la main After the code block the sentence between () should replace `donc` by `dont`: (Remarquez que l'espace s?parant les colonnes vient de la mani?re dont print() fonctionne : il ajoute toujours des espaces entre ses arguments.) ---------- assignee: docs at python components: Documentation messages: 381043 nosy: docs at python, matm priority: normal severity: normal status: open title: Typo in french doc translation type: compile error versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 15 20:02:01 2020 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 16 Nov 2020 01:02:01 +0000 Subject: [New-bugs-announce] [issue42365] Python launcher: sort order in "Installed versions" off with 3.10 Message-ID: <1605488521.14.0.00117878681965.issue42365@roundup.psfhosted.org> New submission from Guido van Rossum : I installed Python 3.10 on Windows and now the sort order of the versions printed by `py -0` is kind of weird: ``` Installed Pythons found by C:\WINDOWS\py.exe Launcher for Windows -3.9-64 * -3.8-64 -3.7-64 -3.6-64 -3.5-64 -3.10-64 ``` I'm guessing we're going to have to parse the versions... (I accidentally first reported this in https://github.com/brettcannon/python-launcher/issues/42.) ---------- components: Windows messages: 381049 nosy: gvanrossum, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal stage: needs patch status: open title: Python launcher: sort order in "Installed versions" off with 3.10 type: behavior versions: Python 3.10 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 03:14:55 2020 From: report at bugs.python.org (Ma Lin) Date: Mon, 16 Nov 2020 08:14:55 +0000 Subject: [New-bugs-announce] [issue42366] Use MSVC2019 and /Ob3 option to compile Windows builds Message-ID: <1605514495.3.0.110639328789.issue42366@roundup.psfhosted.org> New submission from Ma Lin : MSVC2019 has a new option `/Ob3`, it specifies more aggressive inlining than /Ob2: https://docs.microsoft.com/en-us/cpp/build/reference/ob-inline-function-expansion?view=msvc-160 If use this option in MSVC2017, it will emit a warning: cl : Command line warning D9002 : ignoring unknown option '/Ob3' Just apply `Ob3.diff`, get this improvement: (Python 3.9 branch, No PGO, build.bat -p X64) +-------------------------+----------+------------------------------+ | Benchmark | baseline | ob3 | +=========================+==========+==============================+ | 2to3 | 563 ms | 552 ms: 1.02x faster (-2%) | +-------------------------+----------+------------------------------+ | chameleon | 16.5 ms | 16.1 ms: 1.03x faster (-3%) | +-------------------------+----------+------------------------------+ | chaos | 200 ms | 197 ms: 1.02x faster (-2%) | +-------------------------+----------+------------------------------+ | crypto_pyaes | 186 ms | 184 ms: 1.01x faster (-1%) | +-------------------------+----------+------------------------------+ | deltablue | 13.0 ms | 12.6 ms: 1.03x faster (-3%) | +-------------------------+----------+------------------------------+ | dulwich_log | 94.5 ms | 93.9 ms: 1.01x faster (-1%) | +-------------------------+----------+------------------------------+ | fannkuch | 806 ms | 761 ms: 1.06x faster (-6%) | +-------------------------+----------+------------------------------+ | float | 211 ms | 199 ms: 1.06x faster (-6%) | +-------------------------+----------+------------------------------+ | genshi_text | 48.3 ms | 47.7 ms: 1.01x faster (-1%) | +-------------------------+----------+------------------------------+ | go | 446 ms | 437 ms: 1.02x faster (-2%) | +-------------------------+----------+------------------------------+ | hexiom | 16.6 ms | 15.9 ms: 1.04x faster (-4%) | +-------------------------+----------+------------------------------+ | json_dumps | 19.9 ms | 19.3 ms: 1.03x faster (-3%) | +-------------------------+----------+------------------------------+ | json_loads | 45.5 us | 43.9 us: 1.04x faster (-3%) | +-------------------------+----------+------------------------------+ | logging_format | 21.4 us | 20.7 us: 1.03x faster (-3%) | +-------------------------+----------+------------------------------+ | logging_silent | 343 ns | 319 ns: 1.07x faster (-7%) | +-------------------------+----------+------------------------------+ | mako | 29.0 ms | 27.6 ms: 1.05x faster (-5%) | +-------------------------+----------+------------------------------+ | meteor_contest | 168 ms | 162 ms: 1.04x faster (-3%) | +-------------------------+----------+------------------------------+ | nbody | 256 ms | 244 ms: 1.05x faster (-5%) | +-------------------------+----------+------------------------------+ | nqueens | 168 ms | 162 ms: 1.04x faster (-4%) | +-------------------------+----------+------------------------------+ | pathlib | 175 ms | 168 ms: 1.04x faster (-4%) | +-------------------------+----------+------------------------------+ | pickle | 17.9 us | 17.3 us: 1.04x faster (-4%) | +-------------------------+----------+------------------------------+ | pickle_dict | 41.0 us | 33.2 us: 1.24x faster (-19%) | +-------------------------+----------+------------------------------+ | pickle_list | 6.73 us | 5.89 us: 1.14x faster (-12%) | +-------------------------+----------+------------------------------+ | pickle_pure_python | 829 us | 793 us: 1.05x faster (-4%) | +-------------------------+----------+------------------------------+ | pidigits | 243 ms | 243 ms: 1.00x faster (-0%) | +-------------------------+----------+------------------------------+ | pyflate | 1.21 sec | 1.18 sec: 1.03x faster (-2%) | +-------------------------+----------+------------------------------+ | raytrace | 947 ms | 915 ms: 1.03x faster (-3%) | +-------------------------+----------+------------------------------+ | regex_compile | 291 ms | 284 ms: 1.03x faster (-2%) | +-------------------------+----------+------------------------------+ | regex_dna | 217 ms | 222 ms: 1.02x slower (+2%) | +-------------------------+----------+------------------------------+ | regex_effbot | 3.97 ms | 4.13 ms: 1.04x slower (+4%) | +-------------------------+----------+------------------------------+ | regex_v8 | 35.2 ms | 34.6 ms: 1.02x faster (-2%) | +-------------------------+----------+------------------------------+ | richards | 134 ms | 131 ms: 1.02x faster (-2%) | +-------------------------+----------+------------------------------+ | scimark_fft | 616 ms | 599 ms: 1.03x faster (-3%) | +-------------------------+----------+------------------------------+ | scimark_lu | 248 ms | 241 ms: 1.03x faster (-3%) | +-------------------------+----------+------------------------------+ | scimark_monte_carlo | 187 ms | 179 ms: 1.04x faster (-4%) | +-------------------------+----------+------------------------------+ | scimark_sor | 361 ms | 343 ms: 1.05x faster (-5%) | +-------------------------+----------+------------------------------+ | scimark_sparse_mat_mult | 7.71 ms | 7.04 ms: 1.10x faster (-9%) | +-------------------------+----------+------------------------------+ | spectral_norm | 249 ms | 245 ms: 1.02x faster (-2%) | +-------------------------+----------+------------------------------+ | sqlalchemy_declarative | 237 ms | 246 ms: 1.04x slower (+4%) | +-------------------------+----------+------------------------------+ | sqlalchemy_imperative | 40.6 ms | 41.2 ms: 1.02x slower (+2%) | +-------------------------+----------+------------------------------+ | sqlite_synth | 4.64 us | 5.47 us: 1.18x slower (+18%) | +-------------------------+----------+------------------------------+ | sympy_expand | 738 ms | 718 ms: 1.03x faster (-3%) | +-------------------------+----------+------------------------------+ | sympy_integrate | 35.6 ms | 34.7 ms: 1.03x faster (-3%) | +-------------------------+----------+------------------------------+ | sympy_sum | 298 ms | 295 ms: 1.01x faster (-1%) | +-------------------------+----------+------------------------------+ | sympy_str | 484 ms | 471 ms: 1.03x faster (-3%) | +-------------------------+----------+------------------------------+ | telco | 11.3 ms | 9.76 ms: 1.16x faster (-14%) | +-------------------------+----------+------------------------------+ | tornado_http | 256 ms | 254 ms: 1.01x faster (-1%) | +-------------------------+----------+------------------------------+ | unpack_sequence | 94.3 ns | 90.5 ns: 1.04x faster (-4%) | +-------------------------+----------+------------------------------+ | unpickle | 23.6 us | 22.6 us: 1.05x faster (-5%) | +-------------------------+----------+------------------------------+ | unpickle_list | 6.63 us | 6.17 us: 1.07x faster (-7%) | +-------------------------+----------+------------------------------+ | unpickle_pure_python | 589 us | 560 us: 1.05x faster (-5%) | +-------------------------+----------+------------------------------+ | xml_etree_parse | 213 ms | 209 ms: 1.02x faster (-2%) | +-------------------------+----------+------------------------------+ | xml_etree_iterparse | 155 ms | 149 ms: 1.04x faster (-4%) | +-------------------------+----------+------------------------------+ | xml_etree_generate | 149 ms | 145 ms: 1.03x faster (-3%) | +-------------------------+----------+------------------------------+ | xml_etree_process | 117 ms | 115 ms: 1.01x faster (-1%) | +-------------------------+----------+------------------------------+ Not significant (5): django_template; genshi_xml; logging_simple; python_startup; python_startup_no_site ---------- components: Windows files: Ob3.diff keywords: patch messages: 381076 nosy: malin, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Use MSVC2019 and /Ob3 option to compile Windows builds type: performance versions: Python 3.10 Added file: https://bugs.python.org/file49600/Ob3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 04:54:11 2020 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 16 Nov 2020 09:54:11 +0000 Subject: [New-bugs-announce] [issue42367] Restore os.makedirs ability to apply mode to all directories created Message-ID: <1605520451.51.0.153670810596.issue42367@roundup.psfhosted.org> New submission from Gregory P. Smith : os.makedirs used to pass its mode argument on down recursively so that every level of directory it created would have the specified permissions. That was removed in Python 3.7 as https://bugs.python.org/issue19930 as if it were a mis-feature. Maybe it was in one situation, but it was also a desirable *feature*. It wasn't a bug. We've got 15 year old code depending on that and the only solution for it to work on Python 3.7-3.9 is to reimplement recursive directory creation. :( This feature needs to be brought back. Rather than flip flop on the API, adding an flag to indicate if the permissions should be applied recursively or not seems like the best way forward. The "workaround" documented in the above bug is invalid. umask cannot be used to control the intermediate directory creation permissions as that is a process wide global that would impact other threads or signal handlers. umask also cannot be used as umask does not allow setting of special bits such as stat.S_ISVTX. result: Our old os.makedirs() code that tried to set the sticky bit (ISVTX) on all directories now fails to set it at all levels. ---------- components: Library (Lib) keywords: 3.7regression messages: 381082 nosy: gregory.p.smith, serhiy.storchaka priority: normal severity: normal stage: needs patch status: open title: Restore os.makedirs ability to apply mode to all directories created type: behavior versions: Python 3.10 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 05:42:46 2020 From: report at bugs.python.org (Dan Gheorghe Haiduc) Date: Mon, 16 Nov 2020 10:42:46 +0000 Subject: [New-bugs-announce] [issue42368] Make set ordered Message-ID: <1605523366.24.0.798043055827.issue42368@roundup.psfhosted.org> New submission from Dan Gheorghe Haiduc : Now that dicts are ordered[1], would it by any chance make sense to also order sets? A use case that I ran into is trying to reproducibly get a random.choice from a set (after calling random.seed). At first I did not need reproducibility, and I just called random.choice(list(my_set)). Later when I did need it, it was difficult to find out what was wrong. Then I realized that sets are unordered, and that order is not dependent on random.seed. It seems there are also some other confused newbies out there.[2][3] Thank you for the powerful language that is Python! [1] https://www.python.org/dev/peps/pep-0468 [2] https://stackoverflow.com/q/11929701/235463 [3] https://stackoverflow.com/q/36317520/235463 ---------- components: Interpreter Core messages: 381088 nosy: danuker priority: normal severity: normal status: open title: Make set ordered type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 06:07:51 2020 From: report at bugs.python.org (Thomas) Date: Mon, 16 Nov 2020 11:07:51 +0000 Subject: [New-bugs-announce] [issue42369] Reading ZipFile not thread-safe Message-ID: <1605524871.74.0.395089652548.issue42369@roundup.psfhosted.org> New submission from Thomas : According to https://docs.python.org/3.5/whatsnew/changelog.html#id108 bpo-14099, reading multiple ZipExtFiles should be thread-safe, but it is not. I created a small example where two threads try to read files from the same ZipFile simultaneously, which crashes with a Bad CRC-32 error. This is especially surprising since all files in the ZipFile only contain 0-bytes and have the same CRC. My use case is a ZipFile with 82000 files. Creating multiple ZipFiles from the same "physical" zip file is not a satisfactory workaround because it takes several seconds each time. Instead, I open it only once and clone it for each thread: with zipfile.ZipFile("/tmp/dummy.zip", "w") as dummy: pass def clone_zipfile(z): z_cloned = zipfile.ZipFile("/tmp/dummy.zip") z_cloned.NameToInfo = z.NameToInfo z_cloned.fp = open(z.fp.name, "rb") return z_cloned This is a much better solution for my use case than locking. I am using multiple threads because I want to finish my task faster, but locking defeats that purpose. However, this cloning is somewhat of a dirty hack and will break when the file is not a real file but rather a file-like object. Unfortunately, I do not have a solution for the general case. ---------- files: test.py messages: 381090 nosy: Thomas priority: normal severity: normal status: open title: Reading ZipFile not thread-safe versions: Python 3.7, Python 3.8 Added file: https://bugs.python.org/file49601/test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 09:56:27 2020 From: report at bugs.python.org (STINNER Victor) Date: Mon, 16 Nov 2020 14:56:27 +0000 Subject: [New-bugs-announce] [issue42370] test_ttk_guionly: test_to() fails on the GitHub Ubuntu job Message-ID: <1605538587.9.0.222465124321.issue42370@roundup.psfhosted.org> New submission from STINNER Victor : Seen on the Ubuntu job on a GitHub PR: https://github.com/python/cpython/pull/23315/checks?check_run_id=1406797840 ====================================================================== FAIL: test_to (tkinter.test.test_ttk.test_widgets.SpinboxTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/runner/work/cpython/cpython/Lib/tkinter/test/test_ttk/test_widgets.py", line 1175, in test_to self.assertEqual(self.spin.get(), '5') AssertionError: '4' != '5' - 4 + 5 ---------- components: Tests, Tkinter messages: 381101 nosy: vstinner priority: normal severity: normal status: open title: test_ttk_guionly: test_to() fails on the GitHub Ubuntu job versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 10:00:17 2020 From: report at bugs.python.org (=?utf-8?q?Bengt_L=C3=BCers?=) Date: Mon, 16 Nov 2020 15:00:17 +0000 Subject: [New-bugs-announce] [issue42371] Missing colon in timezone suffix raises ValueError Message-ID: <1605538817.4.0.335687964648.issue42371@roundup.psfhosted.org> New submission from Bengt L?ers : I am trying to parse ISO8601-formatted datetime strings with timezones. This works fine when there is a colon separating the hour and minute digits: >>> import datetime >>> datetime.datetime.fromisoformat('2020-11-16T11:00:00+00:00') >>> datetime.datetime(2020, 11, 16, 11, 0, tzinfo=datetime.timezone.utc) However this fails when there is no colon between the hour and the minute digits: >>> import datetime >>> datetime.datetime.fromisoformat('2020-11-16T11:00:00+0000') Traceback (most recent call last): File "", line 1, in ValueError: Invalid isoformat string: '2020-11-16T11:00:00+0000' This behavior is unexpected, as the ISO8601 standard allows omitting the colon in the string and defining the timezone as "?hhmm ": https://en.wikipedia.org/wiki/ISO_8601#Time_offsets_from_UTC As a workaround, I normalized the timezone suffixes before parsing: >>> if iso8601_string.endswith('+0000'): >>> return iso8601_string[:-len('+0000')] + '+00:00' >>> if iso8601_string.endswith('+00'): >>> return iso8601_string[:-len('+00')] + '+00:00' >>> if iso8601_string.endswith('-0000'): >>> return iso8601_string[:-len('-0000')] + '+00:00' >>> if iso8601_string.endswith('-00'): >>> return iso8601_string[:-len('-00')] + '+00:00' This only works for the UTC timezone. I would be nice to have a more general solution which can handle any timezone. I tested this with CPython 3.8. `.fromisoformat()` was added in 3.7, so earlier versions should not be affected by this: https://docs.python.org/3/library/datetime.html#datetime.date.fromisoformat ---------- components: Library (Lib) messages: 381102 nosy: Bengt.L?ers priority: normal severity: normal status: open title: Missing colon in timezone suffix raises ValueError type: behavior versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 10:25:18 2020 From: report at bugs.python.org (Alexander Kurakin) Date: Mon, 16 Nov 2020 15:25:18 +0000 Subject: [New-bugs-announce] [issue42372] A crash in do_richcompare Message-ID: <1605540318.0.0.905589187248.issue42372@roundup.psfhosted.org> 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 _______________________________________ From report at bugs.python.org Mon Nov 16 10:30:58 2020 From: report at bugs.python.org (Mark Shannon) Date: Mon, 16 Nov 2020 15:30:58 +0000 Subject: [New-bugs-announce] [issue42373] PEP 626 does not specify behavior of tracing for keywords. Message-ID: <1605540658.6.0.769594046154.issue42373@roundup.psfhosted.org> New submission from Mark Shannon : PEP 626 doesn't cover which keywords are to be traced if they occur on a line by themselves. Some keywords, like `break`, in Python have behavior associated with them. Others, like `else` are just syntax and don't do anything. Currently, it is not clear which keywords get traced and which do not. I'd like to update the PEP to include the following: Keywords can be broken down into five groups. 1. Must have an attendant expression ( "if", "while", "for", "await") These keywords are not traced, since their expressions are. 2. Have an optional expression and perform non-local control flow ( "return", "yield", "raise", "except" ) These keywords are traced. If on a different line from the expression, they will generate additional events. 3. Pure syntax ( "else", "try", "finally" ) These keywords are not traced. 4. Local control flow ( "break", continue", "pass" ) These keywords are traced 5. Expressions ( "None", "True", "False" ) Treated like other expressions Examples: 1. if ( 2. test 3. ): will generate an event for line 2. 1. return ( 2. x 3. ): will generate an event for line 2, then line 1. 1. try: 2. None 3. finally: 4. pass Will generate an event for line 2, then line 4. Note that whatever changes, the invariant remains that if a line is in `co_lines()` then it will generate trace events, and if it isn't then it won't. ---------- assignee: Mark.Shannon messages: 381114 nosy: Mark.Shannon, nedbat, pablogsal priority: normal severity: normal status: open title: PEP 626 does not specify behavior of tracing for keywords. versions: Python 3.10 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 12:43:28 2020 From: report at bugs.python.org (Lysandros Nikolaou) Date: Mon, 16 Nov 2020 17:43:28 +0000 Subject: [New-bugs-announce] [issue42374] Unparenthesized walrus is not allowed in genexps Message-ID: <1605548608.59.0.339929146872.issue42374@roundup.psfhosted.org> New submission from Lysandros Nikolaou : While a walrus is valid withing generator expressions in 3.8, it's not in 3.9 and onward. ? cpython git:(master) ? python3.8 Python 3.8.6 (default, Oct 3 2020, 16:26:47) [GCC 9.3.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> i = 2 >>> a = [1, 2, 3, 4] >>> (b := i + j for j in a) at 0x7f231e78c740> ? cpython git:(master) python3.10 Python 3.10.0a1+ (heads/master:b580ed1, Oct 19 2020, 15:52:12) [GCC 9.3.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> i = 2 >>> a = [1, 2, 3, 4] >>> (b := i + j for j in a) File "", line 1 (b := i + j for j in a) ^ SyntaxError: invalid syntax This is a regression introduced by the new parser. ---------- components: Interpreter Core keywords: 3.9regression messages: 381133 nosy: gvanrossum, lys.nikolaou, pablogsal, terry.reedy priority: normal severity: normal status: open title: Unparenthesized walrus is not allowed in genexps type: behavior versions: Python 3.10, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 13:18:59 2020 From: report at bugs.python.org (David CARLIER) Date: Mon, 16 Nov 2020 18:18:59 +0000 Subject: [New-bugs-announce] [issue42375] subprocess DragonFlyBSD build update Message-ID: <1605550739.82.0.393092749269.issue42375@roundup.psfhosted.org> Change by David CARLIER : ---------- components: Extension Modules nosy: devnexen priority: normal pull_requests: 22211 severity: normal status: open title: subprocess DragonFlyBSD build update type: enhancement versions: Python 3.10 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 14:27:21 2020 From: report at bugs.python.org (Christian Heimes) Date: Mon, 16 Nov 2020 19:27:21 +0000 Subject: [New-bugs-announce] [issue42376] Add helpers to populate modules in C Message-ID: <1605554841.18.0.0577877222829.issue42376@roundup.psfhosted.org> New submission from Christian Heimes : It's currently inconvenient and sometimes error-prone to initialize module members in C. Even stdlib modules are sometimes missing error checks or have reference counting issues in error path. I propose add three helpers to deal with common cases: 1) declaration of simple attributes (int, str, bool, float) in an array of structs 2) creation and addition of a new type from a type spec 3) creation and addition a new exception object (1) Simple attribute declaration uses a NULL terminated array of PyModuleConst_Def. The internal definition of the type can be hidden by macros. Example: static PyModuleConst_Def example_constants[] = { PyModuleConst_None("none_value"), PyModuleConst_Long("integer", 42), PyModuleConst_Bool("false_value", 0), PyModuleConst_Bool("true_value", 1), PyModuleConst_String("somestring", "Hello"), PyModuleConst_LongMacro(EXAMPLE_INT), PyModuleConst_StringMacro(EXAMPLE_STRING), {NULL}, } A new function "int PyModule_AddConstants(PyObject *module, PyModuleConst_Def *def)" populates the module object with attributes. (2) Type initialization The function "PyTypeObject * PyModule_AddNewTypeFromSpec(PyObject *module, PyType_Spec *spec, PyObject *base)" is PyType_FromModuleAndSpec() + PyModule_AddType(). Additionally to PyType_FromModuleAndSpec() it also handles "base" argument with single type instance. The extra feature avoids "PyTuple_Pack(1, baseclass)" in the caller. The function adds a strong reference to the module object and returns a borrowed reference. The borrowed reference is designed module state assignment. (3) exception creation The function "PyObject* PyModule_AddNewException(PyObject *module, const char *name, const char *doc, PyObject *base, PyObject *dict)" creates a new exception, calculates the attribute name for the qualified exception name, and adds the exception to the module. It's PyErr_NewExceptionWithDoc() + PyModule_AddObjectRef(). Note about (1): I first proposed to add PyModuleDef.m_constants, however we cannot extend the struct easily becaues it conflicts with stable ABI. Petr mentioned that he has plans to deal with the issue. Also see discussion https://discuss.python.org/t/define-module-constants-in-pymoduledef/5749 ---------- assignee: christian.heimes components: C API messages: 381144 nosy: christian.heimes priority: normal severity: normal stage: patch review status: open title: Add helpers to populate modules in C type: enhancement versions: Python 3.10 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 14:43:56 2020 From: report at bugs.python.org (Daniel Pinyol) Date: Mon, 16 Nov 2020 19:43:56 +0000 Subject: [New-bugs-announce] [issue42377] allow typing.cast with TYPE_CHECKING Message-ID: <1605555836.68.0.0424607174157.issue42377@roundup.psfhosted.org> Change by Daniel Pinyol : ---------- nosy: dpinol priority: normal severity: normal status: open title: allow typing.cast with TYPE_CHECKING type: behavior versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 14:48:22 2020 From: report at bugs.python.org (Ed Catmur) Date: Mon, 16 Nov 2020 19:48:22 +0000 Subject: [New-bugs-announce] [issue42378] logging reopens file with same mode, possibly truncating Message-ID: <1605556102.98.0.0941471383568.issue42378@roundup.psfhosted.org> New submission from Ed Catmur : If a logging.FileHandler is configured with mode='w', or if logging.basicConfig is called with filemode='w' (as suggested by the Basic Logging Tutorial https://docs.python.org/3/howto/logging.html#logging-basic-tutorial) and if some code logs during shutdown, after logging has closed its handlers (asyncio is prone to do this, e.g.), then logging.FileHandler._open will reopen the log file with the same mode as it was originally opened with, potentially truncating it and losing valuable information: import atexit atexit.register(lambda: logging.info("so long")) import logging logging.basicConfig(filename='test.log', filemode='w', level=logging.INFO) logging.info("super important stuff") $ python truncate.py $ cat test.log INFO:root:so long I have a hunch that the fix to issue 26789 will potentially make things worse, as previously at least there was a chance that logging had been fully unloaded so that the call to open would fail. https://stackoverflow.com/questions/39838616/why-is-python-logging-framework-losing-messages ---------- components: Library (Lib) messages: 381146 nosy: ecatmur2 priority: normal severity: normal status: open title: logging reopens file with same mode, possibly truncating type: behavior versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 15:37:40 2020 From: report at bugs.python.org (Rose Ridder) Date: Mon, 16 Nov 2020 20:37:40 +0000 Subject: [New-bugs-announce] [issue42379] Optional List Args Persist Across Objects Message-ID: <1605559060.44.0.109457389682.issue42379@roundup.psfhosted.org> New submission from Rose Ridder : When creating several objects in one program, if there are lists passed into functions as optional arguments, those lists are persistent across all objects. ---------- components: ctypes files: PythonObjectListIssue.py messages: 381153 nosy: rosadenderon priority: normal severity: normal status: open title: Optional List Args Persist Across Objects type: behavior versions: Python 3.7 Added file: https://bugs.python.org/file49604/PythonObjectListIssue.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 16:36:20 2020 From: report at bugs.python.org (h-vetinari) Date: Mon, 16 Nov 2020 21:36:20 +0000 Subject: [New-bugs-announce] [issue42380] Build windows binaries with MS VS2019 16.8+ / MSVC 19.28+ Message-ID: <1605562580.81.0.356035250253.issue42380@roundup.psfhosted.org> New submission from h-vetinari : While Visual Studio 16.8 (<-> MSVC 19.28) has _just_ been released, I think it would be worthwhile to consider upgrading the compiler toolchain that's used to build the CPython windows binaries, particularly before the release of 3.10. That's because many libraries (e.g. numpy/scipy) are stuck to the same compilers as CPython for ABI-compatibility, and generally, MSVC is by far the lowest common denominator in terms of C/C++ compliance, cf. https://github.com/scipy/scipy/blob/master/doc/source/toolchain.rst For example, dropping python 3.6 support in scipy should finally enable them to use C++14/C++17, since python 3.7+ is built with Visual Studio 15.7, which has essentially complete support, cf. https://en.cppreference.com/w/cpp/compiler_support & https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B#Internal_version_numbering. However (& as far as I can tell), the windows compiler version for CPython hasn't moved since the release of 3.7, cf. https://pythondev.readthedocs.io/windows.html#python-and-visual-studio-version-matrix (I know that's not an official page, but vstinner can hardly be considered a questionable source), and every release without upgrading the toolchain means another year of waiting for the ecosystem to unlock more modern C/C++. The reason why Visual Studio 16.8 is particularly interesting, is that MS has for a very long time not paid attention to C compliance, and only recently completed C99 support, with C11/C17 following in 16.8 (though as of yet without optional aspects of the standard like atomics, threading, VLAs, complex types, etc.), cf. https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-support-arriving-in-msvc/. Looking at the table from https://github.com/scipy/scipy/blob/master/doc/source/toolchain.rst, it would be cool if we could add the last line as follows =================== ============== =================== CPython MS Visual C++ C Standard =================== ============== =================== 2.7, 3.0, 3.1, 3.2 9.0 C90 3.3, 3.4 10.0 C90 & some of C99 3.5, 3.6 14.0 C90 & most of C99 3.7 15.7 C90 & most of C99 3.8 15.7 C90 & most of C99 3.9 15.7 C90 & most of C99 3.10 16.8 C99, C11*, C17 =================== ============== =================== * [comment about lack of C11 optionals] ---------- components: Windows messages: 381167 nosy: h-vetinari, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Build windows binaries with MS VS2019 16.8+ / MSVC 19.28+ type: enhancement versions: Python 3.10 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 16 17:42:21 2020 From: report at bugs.python.org (Lysandros Nikolaou) Date: Mon, 16 Nov 2020 22:42:21 +0000 Subject: [New-bugs-announce] [issue42381] Allow unparenthesized walrus in set comprehensions Message-ID: <1605566541.23.0.501801430054.issue42381@roundup.psfhosted.org> New submission from Lysandros Nikolaou : Since unparenthesized walruses are allowed in list comprehensions and in generator expressions, should we maybe allow them in set comprehensions as well? ---------- components: Interpreter Core messages: 381173 nosy: gvanrossum, lys.nikolaou, pablogsal priority: normal severity: normal status: open title: Allow unparenthesized walrus in set comprehensions type: behavior versions: Python 3.10 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 01:56:21 2020 From: report at bugs.python.org (Pedro Algarvio) Date: Tue, 17 Nov 2020 06:56:21 +0000 Subject: [New-bugs-announce] [issue42382] No easy way to get the distribution which provided a importlib.metadata.EntryPoint Message-ID: <1605596181.46.0.7808505308.issue42382@roundup.psfhosted.org> New submission from Pedro Algarvio : With `pkg_resources` an `EntryPoint` has a dist attribute which allows you to get the distribution that provided that specific entry-point, however, with `importlib.metafata` and `importlib_metadata` that's not an east task. ```python USE_IMPORTLIB_METADATA_STDLIB = USE_IMPORTLIB_METADATA = False try: # Py3.8+ import importlib.metadata USE_IMPORTLIB_METADATA_STDLIB = True except ImportError: # < Py3.8 backport package import importlib_metadata USE_IMPORTLIB_METADATA = True def get_distribution_from_entry_point(entry_point): loaded_entry_point = entry_point.load() if isinstance(loaded_entry_point, types.ModuleType): module_path = loaded_entry_point.__file__ else: module_path = sys.modules[loaded_entry_point.__module__].__file__ if USE_IMPORTLIB_METADATA_STDLIB: distributions = importlib.metadata.distributions else: distributions = importlib_metadata.distributions for distribution in distributions(): try: relative = pathlib.Path(module_path).relative_to( distribution.locate_file("") ) except ValueError: pass else: if relative in distribution.files: return distribution ``` The above solution has the additional drawback that you're iterating the distributions list, once per EntryPoint, which, was already iterated to get the entry-points listing. I propose we attach the Distribution instance to each of the found EntryPoint to avoid this low performance workaround. I don't have an issue with providing a pull-request, but should that pull request be done against `importlib_metadata` or `importlib.metadata`? ---------- components: Library (Lib) messages: 381211 nosy: jaraco, s0undt3ch priority: normal severity: normal status: open title: No easy way to get the distribution which provided a importlib.metadata.EntryPoint type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 02:26:31 2020 From: report at bugs.python.org (Andrey Bienkowski) Date: Tue, 17 Nov 2020 07:26:31 +0000 Subject: [New-bugs-announce] [issue42383] Pdb does not correclty restart the target if it changes the current directory Message-ID: <1605597991.66.0.0396733980212.issue42383@roundup.psfhosted.org> New submission from Andrey Bienkowski : This was mentioned in #31121, but I believe this deserves its own separate issue. If the debug target is specified using a relative path and later the current directory is changed, pdb tries to search for the target in the new current directory. This currently causes pdb to be unable to exit, which is what #31121 and #14743 are about, but even if they are fixed we would still be left with pdb exiting instead of restarting the target. This issues is about the latter. To reproduce (same as #31121): $ mkdir foo $ cat > foo/script.py import os os.chdir('foo') $ python3 -m pdb foo/script.py > /home/user/foo/script.py(1)() -> import os (Pdb) c The program finished and will be restarted Traceback (most recent call last): File "/usr/lib64/python3.8/pdb.py", line 1704, in main pdb._runscript(mainpyfile) File "/usr/lib64/python3.8/pdb.py", line 1570, in _runscript with io.open_code(filename) as fp: FileNotFoundError: [Errno 2] No such file or directory: 'foo/script.py' Uncaught exception. Entering post mortem debugging Running 'cont' or 'step' will restart the program > /usr/lib64/python3.8/pdb.py(1570)_runscript() -> with io.open_code(filename) as fp: ---------- messages: 381213 nosy: hexagonrecursion priority: normal severity: normal status: open title: Pdb does not correclty restart the target if it changes the current directory _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 02:46:41 2020 From: report at bugs.python.org (Andrey Bienkowski) Date: Tue, 17 Nov 2020 07:46:41 +0000 Subject: [New-bugs-announce] [issue42384] Inconsistent sys.path between python and pdb Message-ID: <1605599201.78.0.619329509169.issue42384@roundup.psfhosted.org> New submission from Andrey Bienkowski : The first entry in sys.path is different between `python foo.py` and `python -m pdb foo.py`. In the former it is the absolute path to the parent directory of foo.py while in the later it is a relative path (unless the debug target was specified using an absolute path). The meaning of the absolute path does not change when the current directory changes (e.g. via os.chdir()) while the meaning of the relative path does. Like any environment inconsistency between regular program execution and the debugger this may lead to bugs that mysteriously vanish when you try to debug them. $ cat > print-path.py import sys from pprint import pprint pprint(sys.path) $ python3 print-path.py ['/home/user', '/usr/lib64/python38.zip', '/usr/lib64/python3.8', '/usr/lib64/python3.8/lib-dynload', '/usr/lib64/python3.8/site-packages', '/usr/lib/python3.8/site-packages'] $ python3 -m pdb print-path.py > /home/user/print-path.py(1)() -> import sys (Pdb) c ['', '/usr/lib64/python38.zip', '/usr/lib64/python3.8', '/usr/lib64/python3.8/lib-dynload', '/usr/lib64/python3.8/site-packages', '/usr/lib/python3.8/site-packages'] ---------- messages: 381215 nosy: hexagonrecursion priority: normal severity: normal status: open title: Inconsistent sys.path between python and pdb _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 04:01:11 2020 From: report at bugs.python.org (Antony Lee) Date: Tue, 17 Nov 2020 09:01:11 +0000 Subject: [New-bugs-announce] [issue42385] Should enum.auto's behavior be adjusted for StrEnum to return the enum name? Message-ID: <1605603671.61.0.469483986721.issue42385@roundup.psfhosted.org> New submission from Antony Lee : Currently, enum.auto doesn't work with the new (Py3.10) StrEnum: `class E(enum.StrEnum): a = enum.auto()` results in `TypeError: 1 is not a string`. I would guess that the most reasonable behavior for auto() in a StrEnum would be to return the name itself, as implemented in the AutoName example at https://docs.python.org/3.10/library/enum.html#using-automatic-values. I believe that this may just be a matter of copying the corresponding `_generate_next_value_` implementation into the definition of StrEnum? ---------- components: Library (Lib) messages: 381220 nosy: Antony.Lee priority: normal severity: normal status: open title: Should enum.auto's behavior be adjusted for StrEnum to return the enum name? versions: Python 3.10 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 06:37:00 2020 From: report at bugs.python.org (Forrest Jiang) Date: Tue, 17 Nov 2020 11:37:00 +0000 Subject: [New-bugs-announce] [issue42386] Update icons for macOS 11 Message-ID: <1605613020.8.0.947392604088.issue42386@roundup.psfhosted.org> New submission from Forrest Jiang <17jiangz1 at gmail.com>: macOS Big Sur has updated default folder, file, drive icons, as well as introduced new guidelines for app icons: https://developer.apple.com/design/human-interface-guidelines/macos/icons-and-images/app-icon/ The current icons on macOS should probably be updated for consistency. ---------- components: macOS messages: 381224 nosy: 17jiangz1, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: Update icons for macOS 11 type: enhancement versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 06:54:28 2020 From: report at bugs.python.org (Andrey Bienkowski) Date: Tue, 17 Nov 2020 11:54:28 +0000 Subject: [New-bugs-announce] [issue42387] Pdb should restore the execution environment before reexecuting the target Message-ID: <1605614068.9.0.0418270403043.issue42387@roundup.psfhosted.org> New submission from Andrey Bienkowski : When the target exits, pdb automatically restarts it. If the target changed something before exiting the changes will remain unless pdb explicitly undoes them. While working on #42383 I had an idea: it would be useful if pdb reverted the changes the target makes to the execution environment (to a reasonable extent) before restarting it. This includes: 1. os.getcwd() - currently not reverted 2. os.environ - I did not check if this is currently restored or not 3. sys.argv - --/-- 4. sys.path - --/-- ---------- components: Library (Lib) messages: 381225 nosy: hexagonrecursion priority: normal severity: normal status: open title: Pdb should restore the execution environment before reexecuting the target _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 08:56:29 2020 From: report at bugs.python.org (ThiefMaster) Date: Tue, 17 Nov 2020 13:56:29 +0000 Subject: [New-bugs-announce] [issue42388] subprocess.check_output(['echo', 'test'], text=True, input=None) fails Message-ID: <1605621389.6.0.523205188314.issue42388@roundup.psfhosted.org> New submission from ThiefMaster : `subprocess.check_output(['echo', 'test'], text=True, input=None)` fails with `AttributeError: 'bytes' object has no attribute 'encode'` due to the function only checking for `universal_newlines` but not `text`: https://github.com/python/cpython/blob/2ffba2a1027909e1dd697bf8ec2a03fba7618020/Lib/subprocess.py#L423 This is inconsistent with the docs, which state that "text was added as a more readable alias for universal_newlines.". ---------- components: Library (Lib) messages: 381234 nosy: ThiefMaster priority: normal severity: normal status: open title: subprocess.check_output(['echo', 'test'], text=True, input=None) fails type: behavior versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 10:16:09 2020 From: report at bugs.python.org (Christian Heimes) Date: Tue, 17 Nov 2020 15:16:09 +0000 Subject: [New-bugs-announce] [issue42389] test_multiprocessing: @requires_hashdigest() prevents test discovery Message-ID: <1605626169.06.0.31570225205.issue42389@roundup.psfhosted.org> New submission from Christian Heimes : The helper function "install_tests_in_module_dict" uses subclass checks to detect test cases in module globals: if issubclass(base, BaseTestCase): ... elif issubclass(base, unittest.TestCase): ... However @requires_hashdigest() returns a function object, not a class instance. None of the tests marked with @requires_hashdigest() are executed any more. ---------- components: Tests messages: 381245 nosy: christian.heimes, vstinner priority: normal severity: normal status: open title: test_multiprocessing: @requires_hashdigest() prevents test discovery type: behavior versions: Python 3.10, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 10:24:52 2020 From: report at bugs.python.org (William Meehan) Date: Tue, 17 Nov 2020 15:24:52 +0000 Subject: [New-bugs-announce] [issue42390] Other Python implementations may not expose the module name in datetime type names Message-ID: <1605626692.16.0.204778938981.issue42390@roundup.psfhosted.org> Change by William Meehan : ---------- components: Tests nosy: wmeehan priority: normal severity: normal status: open title: Other Python implementations may not expose the module name in datetime type names versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 12:48:09 2020 From: report at bugs.python.org (Ram Rachum) Date: Tue, 17 Nov 2020 17:48:09 +0000 Subject: [New-bugs-announce] [issue42391] Clarify documentation of TestCase.assertIs Message-ID: <1605635289.18.0.924357331254.issue42391@roundup.psfhosted.org> New submission from Ram Rachum : Writing the patch now. ---------- assignee: docs at python components: Documentation messages: 381263 nosy: cool-RR, docs at python priority: normal severity: normal status: open title: Clarify documentation of TestCase.assertIs type: enhancement versions: Python 3.10 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 14:04:05 2020 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 17 Nov 2020 19:04:05 +0000 Subject: [New-bugs-announce] [issue42392] remove the 'loop' parameter from __init__ in all classes in asyncio.locks Message-ID: <1605639845.5.0.800535008799.issue42392@roundup.psfhosted.org> New submission from Yury Selivanov : asyncio.Lock and other primitives should no longer accept the `loop` parameter. They should also stop storing the current loop in the `self._loop` attribute. Instead, they should use `get_running_loop()` whenever they need to access the loop. ---------- components: asyncio messages: 381275 nosy: asvetlov, yselivanov priority: normal severity: normal status: open title: remove the 'loop' parameter from __init__ in all classes in asyncio.locks versions: Python 3.10 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 15:56:09 2020 From: report at bugs.python.org (Erlend Egeberg Aasland) Date: Tue, 17 Nov 2020 20:56:09 +0000 Subject: [New-bugs-announce] [issue42393] Raise overflow errors iso. deprecation warnings in socket.htons and socket.ntohs (was deprecated in 3.7) Message-ID: <1605646569.63.0.541454109275.issue42393@roundup.psfhosted.org> New submission from Erlend Egeberg Aasland : Silent truncation was deprecated in Python 3.7 in bpo-28332 with commit 6a7d3480fc8fe4c60538547d2935083ccff0f631 by Serhiy Storchaka. It should be ok to turn these into OverflowError's starting with Python 3.10. ---------- components: Library (Lib) files: error_iso_warning.patch keywords: patch messages: 381284 nosy: erlendaasland, pablogsal, serhiy.storchaka priority: normal severity: normal status: open title: Raise overflow errors iso. deprecation warnings in socket.htons and socket.ntohs (was deprecated in 3.7) versions: Python 3.10 Added file: https://bugs.python.org/file49605/error_iso_warning.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 16:37:45 2020 From: report at bugs.python.org (Christopher Contaxis) Date: Tue, 17 Nov 2020 21:37:45 +0000 Subject: [New-bugs-announce] [issue42394] Exception handling on boolean comparisons Message-ID: <1605649065.52.0.985109845114.issue42394@roundup.psfhosted.org> New submission from Christopher Contaxis : Python 3.8.6 will not produce an exception when comparing values in an and/or statement that normally produces an exception standalone. val = 0 low = 1 high = "2" The following makes sense: val >= low : False val <= high : Exception, cant compare int and str val <= high and val >= low : Exception, cant compare int and str The following doesn't make sense (doesn't produce an exception): val >= low and val <= high : False ---------- messages: 381289 nosy: CanisUrsa priority: normal severity: normal status: open title: Exception handling on boolean comparisons type: behavior versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 17:11:06 2020 From: report at bugs.python.org (Tom Gringauz) Date: Tue, 17 Nov 2020 22:11:06 +0000 Subject: [New-bugs-announce] [issue42395] aclosing was not added to __all__ in contextlib Message-ID: <1605651066.03.0.0238603994476.issue42395@roundup.psfhosted.org> New submission from Tom Gringauz : Related to this PR https://github.com/python/cpython/pull/21545 ---------- components: Library (Lib) messages: 381296 nosy: tomgrin10 priority: normal severity: normal status: open title: aclosing was not added to __all__ in contextlib _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 17 17:20:31 2020 From: report at bugs.python.org (Tom Gringauz) Date: Tue, 17 Nov 2020 22:20:31 +0000 Subject: [New-bugs-announce] [issue42396] Add a whatsnew entry about async contextlib.nullcontext Message-ID: <1605651631.83.0.908096382344.issue42396@roundup.psfhosted.org> Change by Tom Gringauz : ---------- nosy: tomgrin10 priority: normal severity: normal status: open title: Add a whatsnew entry about async contextlib.nullcontext _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 05:13:31 2020 From: report at bugs.python.org (sagewang) Date: Wed, 18 Nov 2020 10:13:31 +0000 Subject: [New-bugs-announce] =?utf-8?b?W2lzc3VlNDIzOTddIGxzdHJpcCDlpIQ=?= =?utf-8?b?55CG5Ye6546wYnVn?= Message-ID: <1605694411.96.0.528193518903.issue42397@roundup.psfhosted.org> New submission from sagewang <786607676 at qq.com>: >>> "prefix_prj_t_suffix".strip().lstrip('prefix_prj_').rstrip('_suffix') 't' >>> "data_prj_t_suffix".strip().lstrip('data_prj_').rstrip('_suffix') '' ---------- components: Extension Modules messages: 381323 nosy: wsqat priority: normal severity: normal status: open title: lstrip ????bug type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 05:47:58 2020 From: report at bugs.python.org (STINNER Victor) Date: Wed, 18 Nov 2020 10:47:58 +0000 Subject: [New-bugs-announce] [issue42398] Race condition in "make regen-all" when running jobs in parallel Message-ID: <1605696478.69.0.28023827375.issue42398@roundup.psfhosted.org> New submission from STINNER Victor : When building the Fedora package of Python 3.10, *sometimes* the "make regen-all" fail to build with errors like: ------------ /builddir/build/BUILD/Python-3.9.0/Modules/_weakref.c:131:5: error: '_WEAKREF_GETWEAKREFCOUNT_METHODDEF' undeclared here (not in a function) 131 | _WEAKREF_GETWEAKREFCOUNT_METHODDEF | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /builddir/build/BUILD/Python-3.9.0/Modules/_weakref.c:132:5: error: expected '}' before '_WEAKREF__REMOVE_DEAD_WEAKREF_METHODDEF' 132 | _WEAKREF__REMOVE_DEAD_WEAKREF_METHODDEF | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ------------ Example: https://src.fedoraproject.org/rpms/python3.9/pull-request/40 The _WEAKREF_GETWEAKREFCOUNT_METHODDEF macro is defined by Modules/clinic/_weakref.c.h which is included by Modules/_weakref.c (at line 13). It seems like while Modules/_weakref.o was being built, Modules/clinic/_weakref.c.h was being generated "at the same time". The "make regen-all" command runs "make clinic" and "make regen-importlib" targets: * "make regen-importlib" builds Modules/_weakref.o from Modules/_weakref.c and Modules/clinic/_weakref.c.h * "make clinic" always rewrites "Modules/clinic/_weakref.c.h" file On Fedora, packages are built using MAKEFLAGS="-j" where is a number, like "-j4". Since there is no dependency between "clinic" and "regen-importlib" targets, these two targets *can* be run in parallel. It seems like "make clinic" always rewrites *all* generated files and the half of writes are *not* atomic. Attached PR makes all writes of clinic.py atomic *and* also avoids modifying the file modification file if the content does not change, as done in other "make regen-all" targets (using Tools/scripts/update_file.py). ---------- components: Build messages: 381325 nosy: vstinner priority: normal severity: normal status: open title: Race condition in "make regen-all" when running jobs in parallel versions: Python 3.10, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 09:12:57 2020 From: report at bugs.python.org (Alex) Date: Wed, 18 Nov 2020 14:12:57 +0000 Subject: [New-bugs-announce] [issue42399] Error upon pip usage. Message-ID: <1605708777.18.0.67455987247.issue42399@roundup.psfhosted.org> New submission from Alex : MacOS catalina 10.15.6 Python -version 3.9 although experienced on 3.8 too. pip -version 20.2.4 Any time I send a command using pip including; pip install, pip freeze, pip list etc. I get this error. Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/3.8/bin/pip", line 8, in sys.exit(main()) File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/pip/_internal/cli/main.py", line 73, in main command = create_command(cmd_name, isolated=("--isolated" in cmd_args)) File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/pip/_internal/commands/__init__.py", line 104, in create_command module = importlib.import_module(module_path) File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/importlib/__init__.py", line 127, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "", line 1014, in _gcd_import File "", line 991, in _find_and_load File "", line 975, in _find_and_load_unlocked File "", line 671, in _load_unlocked File "", line 783, in exec_module File "", line 219, in _call_with_frames_removed File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/pip/_internal/commands/list.py", line 9, in from pip._internal.cli.req_command import IndexGroupCommand File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/pip/_internal/cli/req_command.py", line 22, in from pip._internal.req.constructors import ( File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/pip/_internal/req/__init__.py", line 10, in from .req_install import InstallRequirement File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/pip/_internal/req/req_install.py", line 10, in import uuid File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/uuid.py", line 57, in _AIX = platform.system() == 'AIX' File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/platform.py", line 891, in system return uname().system File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/platform.py", line 857, in uname processor = _syscmd_uname('-p', '') File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/platform.py", line 613, in _syscmd_uname output = subprocess.check_output(('uname', option), File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/subprocess.py", line 411, in check_output return run(*popenargs, stdout=PIPE, timeout=timeout, check=True, File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/run/__init__.py", line 145, in __new__ process = cls.create_process(command, stdin, cwd=cwd, env=env, shell=shell) File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/run/__init__.py", line 121, in create_process shlex.split(command), File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/shlex.py", line 311, in split return list(lex) File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/shlex.py", line 300, in __next__ token = self.get_token() File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/shlex.py", line 109, in get_token raw = self.read_token() File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/shlex.py", line 140, in read_token nextchar = self.instream.read(1) AttributeError: 'tuple' object has no attribute 'read' ---------- components: Library (Lib) messages: 381339 nosy: alki284 priority: normal severity: normal status: open title: Error upon pip usage. type: crash versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 11:34:13 2020 From: report at bugs.python.org (Christian Heimes) Date: Wed, 18 Nov 2020 16:34:13 +0000 Subject: [New-bugs-announce] [issue42400] Ubuntu tests hangs on test_ttk_guionly and test_heading_callback Message-ID: <1605717253.68.0.337301988887.issue42400@roundup.psfhosted.org> New submission from Christian Heimes : The Ubuntu test runner on Azure have been blocked and eventually failed by an issue related to tkinter tests. My PRs ran into the issue at least three times today. Example: https://github.com/python/cpython/pull/23360/checks?check_run_id=1418826919 0:19:06 load avg: 0.00 running: test_ttk_guionly (19 min 1 sec) 0:19:36 load avg: 0.00 running: test_ttk_guionly (19 min 31 sec) 0:20:05 load avg: 0.00 [425/425/1] test_ttk_guionly crashed (Exit code 1) Timeout (0:20:00)! Thread 0x00007f7b8751d080 (most recent call first): File "/home/runner/work/cpython/cpython/Lib/tkinter/__init__.py", line 696 in wait_visibility File "/home/runner/work/cpython/cpython/Lib/tkinter/test/test_ttk/test_widgets.py", line 1539 in test_heading_callback File "/home/runner/work/cpython/cpython/Lib/unittest/case.py", line 549 in _callTestMethod File "/home/runner/work/cpython/cpython/Lib/unittest/case.py", line 592 in run File "/home/runner/work/cpython/cpython/Lib/unittest/case.py", line 652 in __call__ File "/home/runner/work/cpython/cpython/Lib/unittest/suite.py", line 122 in run File "/home/runner/work/cpython/cpython/Lib/unittest/suite.py", line 84 in __call__ File "/home/runner/work/cpython/cpython/Lib/unittest/suite.py", line 122 in run File "/home/runner/work/cpython/cpython/Lib/unittest/suite.py", line 84 in __call__ File "/home/runner/work/cpython/cpython/Lib/unittest/runner.py", line 176 in run File "/home/runner/work/cpython/cpython/Lib/test/support/__init__.py", line 959 in _run_suite File "/home/runner/work/cpython/cpython/Lib/test/support/__init__.py", line 1082 in run_unittest File "/home/runner/work/cpython/cpython/Lib/test/test_ttk_guionly.py", line 31 in test_main File "/home/runner/work/cpython/cpython/Lib/test/libregrtest/runtest.py", line 236 in _runtest_inner2 File "/home/runner/work/cpython/cpython/Lib/test/libregrtest/runtest.py", line 272 in _runtest_inner File "/home/runner/work/cpython/cpython/Lib/test/libregrtest/runtest.py", line 142 in _runtest File "/home/runner/work/cpython/cpython/Lib/test/libregrtest/runtest.py", line 195 in runtest File "/home/runner/work/cpython/cpython/Lib/test/libregrtest/runtest_mp.py", line 81 in run_tests_worker File "/home/runner/work/cpython/cpython/Lib/test/libregrtest/main.py", line 659 in _main File "/home/runner/work/cpython/cpython/Lib/test/libregrtest/main.py", line 639 in main File "/home/runner/work/cpython/cpython/Lib/test/libregrtest/main.py", line 717 in main File "/home/runner/work/cpython/cpython/Lib/test/regrtest.py", line 43 in _main File "/home/runner/work/cpython/cpython/Lib/test/regrtest.py", line 47 in File "/home/runner/work/cpython/cpython/Lib/runpy.py", line 87 in _run_code File "/home/runner/work/cpython/cpython/Lib/runpy.py", line 197 in _run_module_as_main ... test_heading_callback (tkinter.test.test_ttk.test_widgets.TreeviewTest) ... Timeout (0:20:00)! Thread 0x00007f0461140080 (most recent call first): File "/home/runner/work/cpython/cpython/Lib/tkinter/__init__.py", line 696 in wait_visibility File "/home/runner/work/cpython/cpython/Lib/tkinter/test/test_ttk/test_widgets.py", line 1539 in test_heading_callback File "/home/runner/work/cpython/cpython/Lib/unittest/case.py", line 549 in _callTestMethod File "/home/runner/work/cpython/cpython/Lib/unittest/case.py", line 592 in run File "/home/runner/work/cpython/cpython/Lib/unittest/case.py", line 652 in __call__ File "/home/runner/work/cpython/cpython/Lib/unittest/suite.py", line 122 in run File "/home/runner/work/cpython/cpython/Lib/unittest/suite.py", line 84 in __call__ File "/home/runner/work/cpython/cpython/Lib/unittest/suite.py", line 122 in run File "/home/runner/work/cpython/cpython/Lib/unittest/suite.py", line 84 in __call__ File "/home/runner/work/cpython/cpython/Lib/unittest/runner.py", line 176 in run File "/home/runner/work/cpython/cpython/Lib/test/support/__init__.py", line 959 in _run_suite File "/home/runner/work/cpython/cpython/Lib/test/support/__init__.py", line 1082 in run_unittest File "/home/runner/work/cpython/cpython/Lib/test/test_ttk_guionly.py", line 31 in test_main File "/home/runner/work/cpython/cpython/Lib/test/libregrtest/runtest.py", line 236 in _runtest_inner2 File "/home/runner/work/cpython/cpython/Lib/test/libregrtest/runtest.py", line 272 in _runtest_inner File "/home/runner/work/cpython/cpython/Lib/test/libregrtest/runtest.py", line 155 in _runtest File "/home/runner/work/cpython/cpython/Lib/test/libregrtest/runtest.py", line 195 in runtest File "/home/runner/work/cpython/cpython/Lib/test/libregrtest/main.py", line 319 in rerun_failed_tests File "/home/runner/work/cpython/cpython/Lib/test/libregrtest/main.py", line 696 in _main File "/home/runner/work/cpython/cpython/Lib/test/libregrtest/main.py", line 639 in main File "/home/runner/work/cpython/cpython/Lib/test/libregrtest/main.py", line 717 in main File "/home/runner/work/cpython/cpython/Lib/test/__main__.py", line 2 in File "/home/runner/work/cpython/cpython/Lib/runpy.py", line 87 in _run_code File "/home/runner/work/cpython/cpython/Lib/runpy.py", line 197 in _run_module_as_main Makefile:1202: recipe for target 'buildbottest' failed make: *** [buildbottest] Error 1 Error: Process completed with exit code 2. ---------- components: Tests, Tkinter messages: 381357 nosy: christian.heimes, serhiy.storchaka, taleinat, terry.reedy priority: normal severity: normal status: open title: Ubuntu tests hangs on test_ttk_guionly and test_heading_callback type: behavior versions: Python 3.10 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 18 19:48:03 2020 From: report at bugs.python.org (Jean-Charles BERTIN) Date: Thu, 19 Nov 2020 00:48:03 +0000 Subject: [New-bugs-announce] [issue42401] Plislit does not handle date timezone correctly Message-ID: <1605746883.27.0.573891510654.issue42401@roundup.psfhosted.org> New submission from Jean-Charles BERTIN : The plistlib library does not write dates correctly due to its timezone naive date management. For an example, see https://gist.github.com/jcbertin/fedc115ea8122bec9953aa11041294eb or file attached. ---------- components: Library (Lib), macOS files: incorrect_timezone.py messages: 381386 nosy: jcbertin, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: Plislit does not handle date timezone correctly type: behavior versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 Added file: https://bugs.python.org/file49607/incorrect_timezone.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 02:54:10 2020 From: report at bugs.python.org (Dan Merillat) Date: Thu, 19 Nov 2020 07:54:10 +0000 Subject: [New-bugs-announce] [issue42402] Termios module documentation is extremely lacking Message-ID: <1605772450.46.0.534233134191.issue42402@roundup.psfhosted.org> New submission from Dan Merillat : "The interpretation of the flags and the speeds as well as the indexing in the cc array must be done using the symbolic constants defined in the |termios| module." (termios links to itself) These constants are not listed in the documentation and the termios module is installed as a shared library so you can't read it without going to the source. Furthermore the example in the documentation uses the following example: new = termios.tcgetattr(fd) new[3] = new[3] & ~termios.ECHO # lflags Which is explicitly against the documentation on the same page. This has led to most searches on the net turning up people using magic numbers in places instead of symbolic values. Inserting a list of constants with an extremely brief description would improve the module documentation dramatically. ---------- assignee: docs at python components: Documentation messages: 381393 nosy: dan.merillat, docs at python priority: normal severity: normal status: open title: Termios module documentation is extremely lacking versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 03:37:24 2020 From: report at bugs.python.org (STINNER Victor) Date: Thu, 19 Nov 2020 08:37:24 +0000 Subject: [New-bugs-announce] [issue42403] Cleanup importlib code Message-ID: <1605775044.07.0.217782735576.issue42403@roundup.psfhosted.org> New submission from STINNER Victor : Placeholder issuer to enhance the importlib code base and "bootstrap" code. ---------- components: Library (Lib) messages: 381397 nosy: vstinner priority: normal severity: normal status: open title: Cleanup importlib code versions: Python 3.10 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 06:40:44 2020 From: report at bugs.python.org (Christian Heimes) Date: Thu, 19 Nov 2020 11:40:44 +0000 Subject: [New-bugs-announce] [issue42404] clinic: add option to pass module object to converter function Message-ID: <1605786044.41.0.859696579904.issue42404@roundup.psfhosted.org> New submission from Christian Heimes : Sometimes the converter function for CConverter must access the current module object in order to access the current module state. Currently CConverter subclasses have no easy way to pass the module to the converter function. It would be fantastic if easier CConverter would get an option to pass the module. Example: GH-23398 converts the struct module to multiphase initialization. The struct module has a converter for cached struct definitions. The cache used to be a module level object. It is now an interpreter scoped object. I used a custom parse_arg() function to pass the module object: class cache_struct_converter(CConverter): type = 'PyStructObject *' converter = 'cache_struct_converter' c_default = "NULL" def parse_arg(self, argname, displayname): return """ if (!{converter}(module, {argname}, &{paramname})) {{{{ goto exit; }}}} """.format(argname=argname, paramname=self.name, converter=self.converter) def cleanup(self): return "Py_XDECREF(%s);\n" % self.name ---------- components: Argument Clinic messages: 381406 nosy: christian.heimes, corona10, larry, vstinner priority: normal severity: normal status: open title: clinic: add option to pass module object to converter function type: enhancement versions: Python 3.10 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 07:04:38 2020 From: report at bugs.python.org (Adrian Vladu) Date: Thu, 19 Nov 2020 12:04:38 +0000 Subject: [New-bugs-announce] [issue42405] Add distutils mvsccompiler support for Windows ARM64 build Message-ID: <1605787478.54.0.45093731424.issue42405@roundup.psfhosted.org> New submission from Adrian Vladu : To add support for building packages that have C extensions on Windows ARM64, some fixes are required in the integrated distutils wrapper for Visual Studio compiler (Lib/distutils/msvc9compiler.py) This is a hardcoded fix that needs to be improved so that it applies only on windows arm64: https://github.com/ader1990/cpython/commit/b8c59c9b96a7ad11094224b5631aae3b89323f7a Any suggestions are welcome. ---------- components: Windows messages: 381407 nosy: avladu, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Add distutils mvsccompiler support for Windows ARM64 build type: compile error versions: Python 3.10 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 08:19:31 2020 From: report at bugs.python.org (Renato Cunha) Date: Thu, 19 Nov 2020 13:19:31 +0000 Subject: [New-bugs-announce] [issue42406] Importing multiprocessing breaks pickle.whichmodule Message-ID: <1605791971.73.0.31216879751.issue42406@roundup.psfhosted.org> New submission from Renato Cunha : Importing multiprocessing prior to other modules that define `ufunc`s breaks pickle.whichmodule for those functions. Example: Python 3.8.6 (default, Sep 30 2020, 04:00:38) [GCC 10.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import multiprocessing >>> from scipy.special import gdtrix >>> from pickle import whichmodule >>> whichmodule(gdtrix, gdtrix.__name__) '__mp_main__' Now, if we change the order of imports, whichmodule works fine: Python 3.8.6 (default, Sep 30 2020, 04:00:38) [GCC 10.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from scipy.special import gdtrix >>> from pickle import whichmodule >>> import multiprocessing >>> whichmodule(gdtrix, gdtrix.__name__) 'scipy.special._ufuncs' This happens because multiprocessing creates an alias to `__main__` when imported: Lib/multiprocessing/__init__.py 37: sys.modules['__mp_main__'] = sys.modules['__main__'] But doing so changes the ordering of `sys.modules`, and `whichmodule` returns `__mp_main__` instead of the correct `scipy.special._ufuncs`. This bug has arisen in the context of using `dill` (which imports multiprocessing) for serialization and is further documented at https://github.com/uqfoundation/dill/issues/392. I intend to submit a patch/PR with a fix soon. ---------- components: Interpreter Core messages: 381410 nosy: renatolfc priority: normal severity: normal status: open title: Importing multiprocessing breaks pickle.whichmodule type: behavior versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 08:37:42 2020 From: report at bugs.python.org (Ario Aliabadi) Date: Thu, 19 Nov 2020 13:37:42 +0000 Subject: [New-bugs-announce] [issue42407] Grammatical typo in multiprocessing doc Message-ID: <1605793062.09.0.99488545769.issue42407@roundup.psfhosted.org> New submission from Ario Aliabadi : >From the multiprocessing docs: https://docs.python.org/3/library/multiprocessing.html#contexts-and-start-methods > The child process will only inherit those resources necessary to run the process objects run() method. Is grammatically incorrect - the run() method belongs to the process object, and so a possessive appostrophe should be employed instead: > The child process will only inherit those resources necessary to run the process object's run() method. For more information about possessive appostrophes, see here: https://www.thepunctuationguide.com/apostrophe.html#possessives ---------- assignee: docs at python components: Documentation messages: 381412 nosy: arioa, docs at python priority: normal pull_requests: 22292 severity: normal status: open title: Grammatical typo in multiprocessing doc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 08:41:25 2020 From: report at bugs.python.org (Daniel Hrisca) Date: Thu, 19 Nov 2020 13:41:25 +0000 Subject: [New-bugs-announce] [issue42408] passing memoryview slice to struct packing functions Message-ID: <1605793285.19.0.489142790917.issue42408@roundup.psfhosted.org> New submission from Daniel Hrisca : First I have to apologize if this was discussed before; I've searched the issues and googled the problem but I got nothing obvious. I'm trying to pass a memoryview slice as argument to struct packing functions to avoid creating intermediate bytes objects from struct import Struct s = Struct('<2Q500s').pack_into buffer = bytearray(7000) data = bytes(300) s(buffer, 0, 500, 500, memoryview(data)[4:]) and I get this error: error: argument for 's' must be a bytes object Why is it not possible to use memoryviews in this case? It is also strange for me that we can use a memoyview as the target buffer, so this works fine: s(memoryview(buffer)[10:], 0, 500, 500, data[4:]) ---------- messages: 381413 nosy: danielhrisca priority: normal severity: normal status: open title: passing memoryview slice to struct packing functions _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 10:02:33 2020 From: report at bugs.python.org (George Sakkis) Date: Thu, 19 Nov 2020 15:02:33 +0000 Subject: [New-bugs-announce] [issue42409] Interpreter exit blocks waiting for ThreadPoolExecutor.map Message-ID: <1605798153.71.0.514077346974.issue42409@roundup.psfhosted.org> New submission from George Sakkis : ThreadPoolExecutor.map() prevents interpreter exit if there is a reference to the generator it returns. In the attached script: - `python threadpool_map.py run1` exits as soon as the exception is raised on the main thread. This is the desired behavior in our case. - `python threadpool_map.py run2` keeps running until the thread worker processes all queued work items. The only difference from `run1` is that the result of `ThreadPoolExecutor.map()` is assigned to a variable. - `python threadpool_map.py run3` has a `finally` block that shuts down the executor without waiting. Still the worker thread keeps running even after the shutdown. Initially it seemed like https://bugs.python.org/issue36780 but there is no change in the behavior after commenting out the `atexit.register(_python_exit)` call (for the `run2` case at least). ---------- components: Library (Lib) files: threadpool_map.py messages: 381433 nosy: gsakkis priority: normal severity: normal status: open title: Interpreter exit blocks waiting for ThreadPoolExecutor.map type: behavior versions: Python 3.6, Python 3.7, Python 3.8 Added file: https://bugs.python.org/file49608/threadpool_map.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 10:39:07 2020 From: report at bugs.python.org (hai shi) Date: Thu, 19 Nov 2020 15:39:07 +0000 Subject: [New-bugs-announce] [issue42410] Raise a pickleError when convert _functools module to use PyType_FromModuleAndSpec Message-ID: <1605800347.51.0.414802827859.issue42410@roundup.psfhosted.org> New submission from hai shi : Touch an error when convert _functools module to use PyType_FromModuleAndSpec, the error info: _pickle.PicklingError: Can't pickle : it's not the same object as functools.partial The related PR: PR3405 ---------- components: Extension Modules messages: 381436 nosy: petr.viktorin, shihai1991, vstinner priority: normal severity: normal status: open title: Raise a pickleError when convert _functools module to use PyType_FromModuleAndSpec type: behavior versions: Python 3.10 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 12:18:10 2020 From: report at bugs.python.org (Carlos Alexandro Becker) Date: Thu, 19 Nov 2020 17:18:10 +0000 Subject: [New-bugs-announce] [issue42411] respect cgroups limits when trying to allocate memory Message-ID: <1605806290.38.0.199386148713.issue42411@roundup.psfhosted.org> New submission from Carlos Alexandro Becker : A common use case is running python inside containers, for instance, for training models and things like that. The python process sees the host memory/cpu, and ignores its limits, which often leads to OOMKills, for instance: docker run -m 1G --cpus 1 python:rc-alpine python -c 'x = bytearray(80 * 1024 * 1024 * 1000)' Linux will kill the process once it reaches 1GB of RAM used. Ideally, we should have an option to make Python try to allocate only the ram its limited to, maybe something similar to Java's +X:UseContainerSupport. ---------- components: IO messages: 381442 nosy: caarlos0 priority: normal severity: normal status: open title: respect cgroups limits when trying to allocate memory versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 12:31:34 2020 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 19 Nov 2020 17:31:34 +0000 Subject: [New-bugs-announce] [issue42412] Fix bases issues in PyType_FromModuleAndSpec() Message-ID: <1605807094.42.0.125121237362.issue42412@roundup.psfhosted.org> New submission from Serhiy Storchaka : 1. There are leaks if Py_tp_bases is used more than once and if some some calls before setting tp_bases are failed. 2. There is a crash if the bases argument or Py_tp_bases is not a tuple. 3. The documentation is not accurate. ---------- components: C API messages: 381444 nosy: serhiy.storchaka priority: normal severity: normal status: open title: Fix bases issues in PyType_FromModuleAndSpec() type: resource usage versions: Python 3.10, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 14:10:42 2020 From: report at bugs.python.org (Christian Heimes) Date: Thu, 19 Nov 2020 19:10:42 +0000 Subject: [New-bugs-announce] [issue42413] Replace custom exception socket.timeout with TimeoutError Message-ID: <1605813042.63.0.217434537297.issue42413@roundup.psfhosted.org> New submission from Christian Heimes : The socket module has a custom timeout exception "socket.timeout". The exception is documented https://docs.python.org/3/library/socket.html#socket.timeout as : > A subclass of OSError, this exception is raised when a timeout occurs on a socket which has had timeouts enabled via a prior call to settimeout() (or implicitly through setdefaulttimeout()). It's a distinct exception type and not the same as the global TimeoutError. >>> import socket >>> socket.timeout == TimeoutError False I like to follow the example of the deprecated "socket.error", replace the custom exception and make it an alias of TimeoutError. The risk is minimal. Both exceptions are subclasses of OSError. The change would not only make exception handling more consistent. It would also allow me to simplify some code in ssl and socket C code. I might even be able to remove the socket CAPI import from _ssl.c completely. ---------- assignee: christian.heimes components: Extension Modules messages: 381454 nosy: alex, christian.heimes, corona10, dstufft, janssen, vstinner priority: normal severity: normal status: open title: Replace custom exception socket.timeout with TimeoutError type: enhancement versions: Python 3.10 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 15:36:18 2020 From: report at bugs.python.org (John-Mark Gurney) Date: Thu, 19 Nov 2020 20:36:18 +0000 Subject: [New-bugs-announce] [issue42414] unable to document fields of dataclass Message-ID: <1605818178.59.0.432355698283.issue42414@roundup.psfhosted.org> New submission from John-Mark Gurney : per: https://bugs.python.org/issue38401 There is not a way to document fields of a dataclass. I propose that instead of making a language change, that an additional parameter to the field be added in similar vein to property. This currently works: ``` class Foo: def getx(self): return 5 x = property(getx, doc='document the x property') ``` So, I propose this: ``` @dataclass class Bar: x : int = field(doc='document what x is') ``` This should be easy to support as I believe that the above would not require any changes to the core language. ---------- messages: 381455 nosy: jmg priority: normal severity: normal status: open title: unable to document fields of dataclass _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Nov 19 17:47:45 2020 From: report at bugs.python.org (David Hewitt) Date: Thu, 19 Nov 2020 22:47:45 +0000 Subject: [New-bugs-announce] [issue42415] python3.lib in Python3.9.0 Windows distribution does not contain PyObject_CallNoArgs symbol Message-ID: <1605826065.75.0.910654545311.issue42415@roundup.psfhosted.org> New submission from David Hewitt : I'm unsure if this is a packaging error or a misunderstanding by me. I'm trying to link a binary on windows with Py_LIMITED_API set. According to https://www.python.org/dev/peps/pep-0384/#linkage I _think_ I'm supposed to be linking against python3.lib (instead of python39.lib). However my build fails because the PyObject_CallNoArgs symbol is not present in python3.lib I see that the symbol is indeed present in python39.lib Is this a misunderstanding on my part? I was under the impression that python3.lib will only contain symbols available in the limited api, and that (since 3.9) PyObject_CallNoArgs is part of the limited api. ---------- components: Windows messages: 381458 nosy: David Hewitt, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: python3.lib in Python3.9.0 Windows distribution does not contain PyObject_CallNoArgs symbol type: compile error versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 00:52:42 2020 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 20 Nov 2020 05:52:42 +0000 Subject: [New-bugs-announce] [issue42416] IDLE calltip.get_argspec: use inspect.getdoc, comment fob Message-ID: <1605851562.14.0.204332011962.issue42416@roundup.psfhosted.org> New submission from Terry J. Reedy : Followup to PR-23393 of #1635741. Use inspect.getdoc to get docstrings. Restore test skipped in that PR and fix two that will fail because getdoc gets docstrings that are currently missed. The line defining fob is only needed to get signatures for instances of classes with faulty getattr and __call__. inspect.signature is allowed to fail for buggy objects, but this workaround makes it work anyway for CallA() and CallB() in test_buggy_getattr_class. Add comment. ---------- assignee: terry.reedy components: IDLE messages: 381462 nosy: terry.reedy priority: normal severity: normal stage: needs patch status: open title: IDLE calltip.get_argspec: use inspect.getdoc, comment fob type: behavior versions: Python 3.10, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 04:20:23 2020 From: report at bugs.python.org (Bhushan Shelke) Date: Fri, 20 Nov 2020 09:20:23 +0000 Subject: [New-bugs-announce] [issue42417] Empty body {} in POST requests leads to 405 Method not allowed error Message-ID: <1605864023.48.0.825673701965.issue42417@roundup.psfhosted.org> New submission from Bhushan Shelke : I have a Tomcat+Java based server exposing REST APIs. I am writing a client in python to consume those APIs. Everything is fine until I send empty body in POST request. It is a valid use case for us. If I send empty body I get 400 bad request error - Invalid character found in method name [{}POST]. HTTP method names must be tokens. If I send empty request from POSTMAN or Java or CURL it works fine, problem is only when I used python as a client. If I use python based server (attached a simple server program for same) then I get 405 Method not allowed instead of 400 that I get using java based server. Server code is Following is python snippet - json_object={} header = {'alias': 'A', 'Content-Type' : 'application/json', 'Content-Length' : '0'} resp = requests.post(url, auth=(username, password), headers=header, json=json_object) I tried using data as well instead of json param to send payload with not much of success. I captured the wireshark dumps to undertand it further and found that, the request tomcat received is not as per RFC2616 (https://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html). Especially the part - Request-Line = Method SP Request-URI SP HTTP-Version CRLF Because I could see in from wireshark dumps it looked like - {}POST MY-APP-URI HTTP/1.1 As we can see the empty body is getting prefixed with http-method, hence tomcat reports that as an error. I then looked at python http library code -client.py. Following are relevant details - File - client.py Method - _send_output (starting at line # 1001) - It first sends the header at line #1010 and then the body somewhere down in the code. I thought(I could be wrong here) perhaps in this case header is way longer 310 bytes than body 2 bytes, so by the time complete header is sent on wire body is pushed and hence TCP frames are order in such a way that body appears first. To corroborate this I added a delay of 1 second just after sending header line#1011 and bingo, the error disappeared and it started working fine. Not sure if this is completely correct analysis, but can someone in the know can confirm or let me know how to fix this. ---------- components: Windows files: sample_flask.py messages: 381470 nosy: bhushan.shelke, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Empty body {} in POST requests leads to 405 Method not allowed error type: behavior versions: Python 3.9 Added file: https://bugs.python.org/file49609/sample_flask.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 05:28:13 2020 From: report at bugs.python.org (Christian Heimes) Date: Fri, 20 Nov 2020 10:28:13 +0000 Subject: [New-bugs-announce] [issue42418] PyType_GetModule() should warn/fail when type has Py_TPFLAGS_BASETYPE Message-ID: <1605868093.25.0.0769747248067.issue42418@roundup.psfhosted.org> New submission from Christian Heimes : PyType_GetModule() may return wrong or unexpected result when a type has the feature flag Py_TPFLAGS_BASETYPE. The base type flag permits subclassing of an extension class. The function will return NULL when a type is subclasses in Python space or a different module object when the type is subclasses and initialized in a differen C extension module. All subclassable types must use _PyType_GetModuleByDef() to safely access module and module state struct. It's easy to miss the problem. I missed it when I ported some of my code to heap types and multiphase init. I propose to either a guard to PyType_GetModule() to prevent misuse of the function or to add a variant of the function that prevents misuse. ---------- components: Interpreter Core messages: 381475 nosy: christian.heimes, corona10, petr.viktorin, vstinner priority: normal severity: normal stage: needs patch status: open title: PyType_GetModule() should warn/fail when type has Py_TPFLAGS_BASETYPE type: behavior versions: Python 3.10 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 08:26:25 2020 From: report at bugs.python.org (Quentin Hibon) Date: Fri, 20 Nov 2020 13:26:25 +0000 Subject: [New-bugs-announce] [issue42419] Typo in "what's new in Python 3.9" Message-ID: <1605878785.67.0.774510007978.issue42419@roundup.psfhosted.org> New submission from Quentin Hibon : "deprecatations" should be "deprecations" ---------- assignee: docs at python components: Documentation messages: 381478 nosy: docs at python, hiqua priority: normal severity: normal status: open title: Typo in "what's new in Python 3.9" versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 15:55:27 2020 From: report at bugs.python.org (Gerhard van Andel) Date: Fri, 20 Nov 2020 20:55:27 +0000 Subject: [New-bugs-announce] [issue42420] queue.Queue().join() add a timeout option Message-ID: <1605905727.75.0.219502416453.issue42420@roundup.psfhosted.org> New submission from Gerhard van Andel : class Queue: def join(): ... # Can we add a timeout option to the join method on queue.Queue def join(timeout=None): '''Blocks until all items in the Queue have been gotten and processed. The count of unfinished tasks goes up whenever an item is added to the queue. The count goes down whenever a consumer thread calls task_done() to indicate the item was retrieved and all work on it is complete. If 'timeout' is a non-negative number, it blocks at most 'timeout' seconds and raises the Full exception if no free slot was available within that time. When the count of unfinished tasks drops to zero, join() unblocks. ''' if timeout and timeout < 0: raise ValueError("'timeout' must be a non-negative number") with self.all_tasks_done: while self.unfinished_tasks: self.all_tasks_done.wait(timeout) ---------- components: Library (Lib) messages: 381506 nosy: vananger93 priority: normal severity: normal status: open title: queue.Queue().join() add a timeout option type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Nov 20 23:37:46 2020 From: report at bugs.python.org (=?utf-8?b?5ZiJ5LmQ5ZCb5a2Q?=) Date: Sat, 21 Nov 2020 04:37:46 +0000 Subject: [New-bugs-announce] [issue42421] Native open failed to create a file on windows10 when colon exists in the name Message-ID: <1605933466.33.0.956587428318.issue42421@roundup.psfhosted.org> New submission from ???? : with open('./pdfs/' + pdf_name, 'wb') as fo: fo.write(data) On Windows10, the native 'open' in Python3.7 failed to create a file if the name contains colon, such as 'FocalMix: Semi-Supervised Learning for 3D Medical Image Detection.pdf'. ---------- components: IO messages: 381524 nosy: chenhaoran1991 priority: normal severity: normal status: open title: Native open failed to create a file on windows10 when colon exists in the name type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 02:20:07 2020 From: report at bugs.python.org (Sofian Brabez) Date: Sat, 21 Nov 2020 07:20:07 +0000 Subject: [New-bugs-announce] [issue42422] Py_Decref on value crash the interpreter in Python/ceval.c:1104 Message-ID: <1605943207.33.0.904447657295.issue42422@roundup.psfhosted.org> New submission from Sofian Brabez : This PoC is causing a local crash of python interpreters version 2.7,3.6,3.7,3.8 and 3.9. By creating a code object of size 0 with a POP_TOP opcode, in Python/ceval.c the call to Py_DECREF(value) on a NULL pointer lead to a segmentation fault of the python interpreter. It was tested on all python3.x versions against a fresh compilation of a git clone github.com/python/cpython.git on branches and master. You need to adapt the code() constructor because the parameters are different across versions but crash remains. I'm just covering the version 3.7 in following text $ git clone --depth 1 https://github.com/python/cpython.git $ git checkout -b 3.7 origin/3.7 $ export CFLAGS+="-g -O0" $ ./configure $ make $ ./python -V Python 3.7.9+ $ ./python -c 'import sys; print(sys.version)' 3.7.9+ (heads/3.7-dirty:08ba61dade, Nov 21 2020, 04:57:20) [Clang 10.0.1 (git at github.com:llvm/llvm-project.git llvmorg-10.0.1-0-gef32c611a $ ./python crash.py Running the python3.7 execution into gdb, helped me to locate the crash for python3.7 https://github.com/python/cpython/blob/3.7/Python/ceval.c#L1104 $ gdb --batch --silent ./python -ex 'r crash.py' Program received signal SIGSEGV, Segmentation fault. 0x000000000033873a in _PyEval_EvalFrameDefault (f=0x800bdda00, throwflag=0) at Python/ceval.c:1104 1104 Py_DECREF(value); Also I have executed the PoC on different platforms Linux, FreeBSD and MacOSX. The behaviour is the same and SIGSEGV the interpreter. I have located the issue in the source code but I'm wondering what will be the best solution to fix it? Python developers should know better, I am open to your advices and suggestions. I have noticed that one assertion handle this case (in master) https://github.com/python/cpython/blob/master/Python/ceval.c#L1430 but most of the interpreters are built without --with-assertions enabled, so the crash will still persist. More details on this gist https://gist.github.com/sbz/267d35de5766c53835c5c4ef45b18705 I think the python interpreter shouldn't crash and handle properly this edge case. ---------- components: Interpreter Core files: crash.py messages: 381527 nosy: sbz priority: normal severity: normal status: open title: Py_Decref on value crash the interpreter in Python/ceval.c:1104 type: crash versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9 Added file: https://bugs.python.org/file49610/crash.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 05:19:14 2020 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 21 Nov 2020 10:19:14 +0000 Subject: [New-bugs-announce] [issue42423] Support passing single class to PyType_FromSpecWithBases and PyType_FromModuleAndSpec Message-ID: <1605953954.58.0.578836849321.issue42423@roundup.psfhosted.org> New submission from Serhiy Storchaka : It is common that class have a single base class. PyType_FromModuleAndSpec() is only called with NULL as bases (that means inheriting object) in the stdlib, and PyType_FromSpecWithBases() is called with a 1-tuple as bases all three times (not counting tests). Since it is a common case, PyErr_NewException() accept both a tuple and a single class as the base argument. I propose to accept a single class also in PyType_FromSpecWithBases() and PyType_FromModuleAndSpec(). ---------- components: C API messages: 381542 nosy: christian.heimes, serhiy.storchaka priority: normal severity: normal status: open title: Support passing single class to PyType_FromSpecWithBases and PyType_FromModuleAndSpec type: enhancement versions: Python 3.10 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 08:08:04 2020 From: report at bugs.python.org (Vito De Tullio) Date: Sat, 21 Nov 2020 13:08:04 +0000 Subject: [New-bugs-announce] [issue42424] add constructor that support multiple context managers to contextlib.ExitStack and contextlib.AsyncExitStack Message-ID: <1605964084.33.0.932146787408.issue42424@roundup.psfhosted.org> New submission from Vito De Tullio : The enhancement is to add a __init__ method to both contextlib.ExitStack and contextlib.AsyncExitStack, so that you can pass (async)context managers directly in the costructor. additionally, a new "context_managers" / "async_context_managers" field is added to retrieve the values passed This will ease the usage with lists of context managers instead of: with ExitStack() as stack: files = [stack.enter_context(open(fname)) for fname in filenames] you can have with ExitStack(*(open(fname) for fname in filenames)) as stack: files = stack.context_managers In my use case I have a fixed + variable number of (async)context managers, and I don't even need the "as" part ... in_send, in_receive = trio.open_memory_channel(0) out_sends, out_receives = [], [] for _ in range(n): # n is dynamic out_send, out_receive = trio.open_memory_channel(0) out_sends.append(out_send) out_receives.append(out_receive) # syntax error async with in_send, in_receive, *out_sends, *out_receives: ... # with current AsyncExitStack async with AsyncExitStack() as stack: await stack.async_context_managers(in_send) await stack.async_context_managers(in_receive) for out_send in out_sends: await stack.async_context_managers(out_send) for out_receive in out_receives: await stack.async_context_managers(out_receives) ... # with the change async with AsyncExitStack(in_send, in_receive, *out_sends, *out_receives): ... ---------- components: Library (Lib) messages: 381561 nosy: ZeD priority: normal severity: normal status: open title: add constructor that support multiple context managers to contextlib.ExitStack and contextlib.AsyncExitStack type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 10:01:13 2020 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 21 Nov 2020 15:01:13 +0000 Subject: [New-bugs-announce] [issue42425] Possible leak in initialization of errmap for OSError Message-ID: <1605970873.69.0.937757784906.issue42425@roundup.psfhosted.org> New submission from Serhiy Storchaka : There is a potential leak when adding item to errmap (errno to OSError subclass mapping) fails. ---------- components: Interpreter Core messages: 381565 nosy: serhiy.storchaka priority: normal severity: normal status: open title: Possible leak in initialization of errmap for OSError type: resource usage versions: Python 3.10, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 10:19:37 2020 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 21 Nov 2020 15:19:37 +0000 Subject: [New-bugs-announce] [issue42426] IDLE: Fix reporting RE error in searchengine Message-ID: <1605971977.28.0.341326633768.issue42426@roundup.psfhosted.org> New submission from Serhiy Storchaka : In Lib/idlelib/searchengine.py there is a code which decomposes re.error and reports error message, pattern, and position of error. The problem is that that code does not match the structure of re.error. It takes args[0] as error message, and args[1] (if specified) as position in the pattern. But actually re.error always sets args[0] to formatted error message, and args has only one item. So some code in IDLE is dead. Currently reported: Error: bad escape \z at position 1 Pattern: a\z Expected: Error: bad escape \z Pattern: a\z Offset: 1 ---------- assignee: terry.reedy components: IDLE messages: 381566 nosy: serhiy.storchaka, terry.reedy priority: normal severity: normal status: open title: IDLE: Fix reporting RE error in searchengine versions: Python 3.10, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 12:27:58 2020 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 21 Nov 2020 17:27:58 +0000 Subject: [New-bugs-announce] [issue42427] Use the errno attribute of OSError instead of args[0] Message-ID: <1605979678.87.0.367966297181.issue42427@roundup.psfhosted.org> New submission from Serhiy Storchaka : Some code in the stdlib still uses e.args[0] to access errno of OSError instead of e.errno. The latter is more readable, and also it always success (although can return None), but args can be an empty tuple. ---------- components: Library (Lib) messages: 381570 nosy: serhiy.storchaka priority: normal severity: normal status: open title: Use the errno attribute of OSError instead of args[0] type: enhancement versions: Python 3.10 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 14:56:52 2020 From: report at bugs.python.org (JohnSmith11132) Date: Sat, 21 Nov 2020 19:56:52 +0000 Subject: [New-bugs-announce] [issue42428] Inconsistent squaring behavior Message-ID: <1605988612.3.0.228167402053.issue42428@roundup.psfhosted.org> New submission from JohnSmith11132 : Basically when squaring as a negative number, if it's a variable it acts like -3*-3 otherwise it acts like 3*-3. For example: >>> x = -3 >>> x ** 2 9 >>> -3 ** 2 -9 pow(-3, 2) seems to act like -3 * -3? ** 3 seems fine and both seems to act like -3*-3*-3. >>> x = -3 >>> x ** 3 27 >>> -3 ** 3 -27 Will it be safe to use the ** 2 in Python? If I use a variable will it return the same value? I only found this for the bug: https://devforum.roblox.com/t/inconsistent-squaring-behavior/820028/ It looks like the exact same issue I'm having, but I still don't get it and it's not for Python. ---------- components: Interpreter Core messages: 381573 nosy: JohnSmith11132 priority: normal severity: normal status: open title: Inconsistent squaring behavior type: behavior versions: Python 3.10 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Nov 21 18:29:40 2020 From: report at bugs.python.org (Chris Warrick) Date: Sat, 21 Nov 2020 23:29:40 +0000 Subject: [New-bugs-announce] [issue42429] Behavior of general (%g, :g) formatting inconsistent for decimal.Decimal Message-ID: <1606001380.98.0.451619022303.issue42429@roundup.psfhosted.org> New submission from Chris Warrick : When formatting decimal.Decimal using old-style formatting (%g), the output is as short as possible, as expected. When using new-style formatting (str.format or f-strings), the output uses the input precision. Floats behave correctly with new-style formatting. Python 3.9.0 (default, Oct 27 2020, 14:15:17) [Clang 12.0.0 (clang-1200.0.32.21)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import decimal >>> d1 = decimal.Decimal("1.000") >>> d2 = decimal.Decimal("1.500") >>> f1 = 1.0 >>> f2 = 1.5 >>> f"{d1:g} {f1:g}" '1.000 1' >>> f"{d2:g} {f2:g}" '1.500 1.5' >>> "%g %g" % (d1, f1) '1 1' >>> "%g %g" % (d2, f2) '1.5 1.5' ---------- components: Library (Lib) messages: 381578 nosy: Kwpolska priority: normal severity: normal status: open title: Behavior of general (%g, :g) formatting inconsistent for decimal.Decimal type: behavior versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 00:17:38 2020 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 22 Nov 2020 05:17:38 +0000 Subject: [New-bugs-announce] [issue42430] Windows py launcher default for shebang line is surprising Message-ID: <1606022258.04.0.96368349872.issue42430@roundup.psfhosted.org> New submission from Guido van Rossum : I have 3.9 and 3.10 installed on my Windows box. The py launcher runs Python 3.10 when invoked on a script starting with a shebang line #!/usr/bin/env python even though the default without a script is 3.9, as shown here: PS C:\Users\gvanrossum\peps> py -0 Installed Pythons found by C:\WINDOWS\py.exe Launcher for Windows -3.9-64 * -3.8-64 -3.7-64 -3.6-64 -3.5-64 -3.4-64 -3.10-64 PS C:\Users\gvanrossum\peps> py Python 3.9.0 (tags/v3.9.0:9cf6752, Oct 5 2020, 15:34:40) [MSC v.1927 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> ^Z PS C:\Users\gvanrossum\peps> This caused some confusion since I was running a script that imported a package that I had installed in the default interpreter but not in 3.10. I am not using a virtual environment (yet :-). Without the shebang line the 3.9 interpreter is used. (Full disclosure: the script was pep2html.py, and the package was docutils.) ---------- assignee: steve.dower components: Windows messages: 381590 nosy: gvanrossum, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal stage: needs patch status: open title: Windows py launcher default for shebang line is surprising versions: Python 3.10 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 04:38:12 2020 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 22 Nov 2020 09:38:12 +0000 Subject: [New-bugs-announce] [issue42431] Fix outdated bytes comments Message-ID: <1606037892.77.0.133839812824.issue42431@roundup.psfhosted.org> New submission from Serhiy Storchaka : Some comments in C code still refer to bytearray object as bytes object and to bytes object as string object. The proposed PR fixes outdated comments. It also moves the definition of macros F_LJUST etc from public header to private header. They are only used internally and never leaked to the user. They were defined in two places: in Include/bytesobject.h and Objects/bytesobject.c. Is it true that headers in Include/internal are more private than headers in Include/cpython? It is not clear from names. ---------- components: Interpreter Core messages: 381604 nosy: serhiy.storchaka, vstinner priority: normal severity: normal status: open title: Fix outdated bytes comments versions: Python 3.10 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 04:59:54 2020 From: report at bugs.python.org (sicarius noidea) Date: Sun, 22 Nov 2020 09:59:54 +0000 Subject: [New-bugs-announce] [issue42432] Http client, Bad Status Line triggered for no reason Message-ID: <1606039194.24.0.479620011525.issue42432@roundup.psfhosted.org> New submission from sicarius noidea : Hey, BadStatusLine triggered when protocol version is in lowercase. I've encountered a server that answers "Http/1.0 404 Not Found\r\n" instead of "HTTP/1.0 404 Not Found\r\n" ## Expected Result Requests understanding the status line. ## Actual Result Requests is closing the connection. ## Reproduction Steps ### Setup a server that answers the line above bash: ```while 1;do echo "Http/1.0 404 Not Found\r\n" | sudo nc -lnvp 80; done``` ### get the server ```python import requests req = req = requests.get("http://127.0.0.1/", verify=False, allow_redir=False ) ``` ## problem location Look at line 287 of http/client.py the word "HTTP" should be matched in lowercase too. ```python if not version.startswith("HTTP/"):``` Regards. ---------- components: Library (Lib) messages: 381606 nosy: sicarius.ctf priority: normal severity: normal status: open title: Http client, Bad Status Line triggered for no reason type: behavior versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 05:09:32 2020 From: report at bugs.python.org (Florian Klink) Date: Sun, 22 Nov 2020 10:09:32 +0000 Subject: [New-bugs-announce] [issue42433] mailbox.mbox fails on non ASCII characters Message-ID: <1606039772.66.0.933443286563.issue42433@roundup.psfhosted.org> New submission from Florian Klink : I'm importing some mbox archives into my maildirs, and use `mailbox.mbox` to parse archives created by pipermail. Some of these archives seem to contain non-ascii characters, and python just throws a `UnicodeDecodeError` and refuses to process the archive. Reproducer: (successful on 3.7.9, 3.8.5, 3.9.0) ``` curl https://lists.freedesktop.org/archives/systemd-devel/2016-January.txt.gz | zcat > mbox.txt python3 -c "import mailbox; mb = mailbox.mbox('mbox.txt');mb.items()" ``` ---------- components: email messages: 381607 nosy: barry, flokli, r.david.murray priority: normal severity: normal status: open title: mailbox.mbox fails on non ASCII characters versions: Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 06:15:21 2020 From: report at bugs.python.org (=?utf-8?q?David_Sala=C4=8D?=) Date: Sun, 22 Nov 2020 11:15:21 +0000 Subject: [New-bugs-announce] [issue42434] Library json, file json/encoder.py: Function floatstr should be a class-level function. Message-ID: <1606043721.58.0.74896006413.issue42434@roundup.psfhosted.org> New submission from David Sala? : The logic as it is implemented now does not allow to user to override floatstr function. That makes things enormously inconvenient for people who need any different of behaviour (for example return string values defining Infinity, NaN or -Infinity). If it was moved on the class-level, it would easier because it makes floatstr to be a class-level function. ---------- components: Library (Lib) files: encoder.py messages: 381609 nosy: salacdav priority: normal severity: normal status: open title: Library json, file json/encoder.py: Function floatstr should be a class-level function. type: enhancement versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 Added file: https://bugs.python.org/file49613/encoder.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 07:31:52 2020 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 22 Nov 2020 12:31:52 +0000 Subject: [New-bugs-announce] [issue42435] Spped up comparison of bytes and bytearray object with objects of different types Message-ID: <1606048312.33.0.0547387473291.issue42435@roundup.psfhosted.org> New submission from Serhiy Storchaka : The proposed PR speeds up comparison of bytes and bytearray object with objects of different types, especially if use the -b option. Before: $ ./python -m timeit -s "x = b''" "x == None" 10000000 loops, best of 5: 29.5 nsec per loop $ ./python -b -m timeit -s "x = b''" "x == None" 2000000 loops, best of 5: 139 nsec per loop $ ./python -m timeit -s "x = bytearray()" "x == None" 1000000 loops, best of 5: 282 nsec per loop $ ./python -b -m timeit -s "x = bytearray()" "x == None" 1000000 loops, best of 5: 282 nsec per loop After: $ ./python -m timeit -s "x = b''" "x == None" 10000000 loops, best of 5: 29.7 nsec per loop $ ./python -b -m timeit -s "x = b''" "x == None" 10000000 loops, best of 5: 29.9 nsec per loop $ ./python -m timeit -s "x = bytearray()" "x == None" 10000000 loops, best of 5: 32.1 nsec per loop $ ./python -b -m timeit -s "x = bytearray()" "x == None" 10000000 loops, best of 5: 32.2 nsec per loop There were two causes of the slowdown: 1. When checked for bytes warning, the code used slow PyObject_IsInstance() which checks the __class__ attribute and looks up several other attributes. Using fast PyUnicode_Check() and PyLong_Check() is enough, because the only case when these methods give different result if you compare with an instance of special class with the __class__ property which return str or int. It is very uncommon case. 2. For bytearray, it tried to get buffers of arguments, and if they did not support the buffer protocol, a TypeError was raised and immediately suppressed. Using fast check PyObject_CheckBuffer() allows to get rid of raising an exception. Also, PyUnicode_Check() and PyLong_Check() are more convenient, because they do not need error handling. ---------- components: Interpreter Core messages: 381612 nosy: methane, serhiy.storchaka priority: normal severity: normal status: open title: Spped up comparison of bytes and bytearray object with objects of different types type: performance versions: Python 3.10 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 07:43:02 2020 From: report at bugs.python.org (Amirouche Boubekki) Date: Sun, 22 Nov 2020 12:43:02 +0000 Subject: [New-bugs-announce] [issue42436] Google use wrong "hightlight" argument Message-ID: <1606048982.4.0.529831735845.issue42436@roundup.psfhosted.org> New submission from Amirouche Boubekki : At the moment when I search for the following: https://www.google.com/search?q=ast+transformer+python+3.10 I have as second result this url: https://docs.python.org/dev/library/ast.html?highlight=s I do not understand the purpose in the query string of `highlight=s` ---------- assignee: docs at python components: Documentation messages: 381613 nosy: amirouche, docs at python priority: normal severity: normal status: open title: Google use wrong "hightlight" argument versions: Python 3.10 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 09:23:49 2020 From: report at bugs.python.org (=?utf-8?b?0JzQuNC60LDQtdC70LAg0KHRgtC+0LjRh9C60L7QstCw?=) Date: Sun, 22 Nov 2020 14:23:49 +0000 Subject: [New-bugs-announce] [issue42437] crypt produces wrong hashes for passwords containing dollar sign Message-ID: <1606055029.24.0.350061421164.issue42437@roundup.psfhosted.org> New submission from ??????? ????????? : I am having an issue with crypt library (Lib/crypt.py) when hashing passwords containing dolalr sign ("$") . I am using python 3.8.5 on Linux. To compare hashed passwords produced by crypt, I used openssl utilities. When generating hashes for password without "$", crypt and openssl return the same result. But when generating hashes for passwords containing $ dollar sign, crypt returns a result different from the result returned by openssl: openssl passwd -6 "cash$money" $6$C0UG33RcHmBVAjQ/$j1Tm2WSaZzDIzVQTgk71z6nY7fiJnaLe6Lxy8DzGystQ1Jive7IuqIUJq5s2F9wdXRpm8jNs7iksV8oHPVKYC0 python3 -c 'import crypt; print(crypt.crypt("cash$money","$6$C0UG33RcHmBVAjQ/"))' $6$C0UG33RcHmBVAjQ/$Tm9aYQq7BsTT/awN6wiUZ6ysamqX9qUVKBV.TjML5udxWqupAB7luv/.KYypZnpQ9eI33R4Lw3O4Jx4NZjTEV/ I did not find a special mention for dollar sign in the documentation. Thanks for your help. ---------- components: Library (Lib) messages: 381615 nosy: m.stoichkovaaa priority: normal severity: normal status: open title: crypt produces wrong hashes for passwords containing dollar sign type: behavior versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 10:21:58 2020 From: report at bugs.python.org (Vuyyuru Sai Nithish) Date: Sun, 22 Nov 2020 15:21:58 +0000 Subject: [New-bugs-announce] [issue42438] Fatal Python error: init_fs_encoding: failed to get the Python codec of the filesystem encoding Message-ID: <1606058518.9.0.857155986054.issue42438@roundup.psfhosted.org> Change by Vuyyuru Sai Nithish : ---------- nosy: nithish priority: normal severity: normal status: open title: Fatal Python error: init_fs_encoding: failed to get the Python codec of the filesystem encoding type: crash versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 14:46:39 2020 From: report at bugs.python.org (Elian Mariano Gabriel) Date: Sun, 22 Nov 2020 19:46:39 +0000 Subject: [New-bugs-announce] [issue42439] Use of ternary operator instead of if and else in month calculation function Message-ID: <1606074399.89.0.722883814317.issue42439@roundup.psfhosted.org> New submission from Elian Mariano Gabriel : Inside the file calendar.py, there are two functions which are supposed to calculate the previous and next month relative to the actual year and month. def _prevmonth(year, month): if month == 1: return year-1, 12 else: return year, month-1 def _nextmonth(year, month): if month == 12: return year+1, 1 else: return year, month+1 Because of the concise calculation that is being made by these functions, it would be convenient to use the ternary operator to calculate that. So, the result would be: def _prevmonth(year, month): return [year-1, 12] if month == 1 else [year, month-1] def _nextmonth(year, month): return [year+1, 1] if month == 12 else [year, month+1] ---------- components: Library (Lib) files: calendar.py messages: 381629 nosy: ElianMariano priority: normal severity: normal status: open title: Use of ternary operator instead of if and else in month calculation function versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 Added file: https://bugs.python.org/file49614/calendar.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Nov 22 15:26:17 2020 From: report at bugs.python.org (Rawad Bader) Date: Sun, 22 Nov 2020 20:26:17 +0000 Subject: [New-bugs-announce] [issue42440] MACBOOK Python launcher Message-ID: <1606076777.01.0.563926095188.issue42440@roundup.psfhosted.org> New submission from Rawad Bader : I would like to know why when I run my script from python3.8 for the VideoCapture which it was working before the new update for MacBook. Now it runs and the camera lights green but the python launcher, not apple to opens the camera no idea why. ---------- components: macOS messages: 381632 nosy: ned.deily, rawadbader466, ronaldoussoren priority: normal severity: normal status: open title: MACBOOK Python launcher type: behavior versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 03:36:35 2020 From: report at bugs.python.org (Md Tausif Iqbal) Date: Mon, 23 Nov 2020 08:36:35 +0000 Subject: [New-bugs-announce] [issue42441] UnicodeEncodeError Message-ID: <1606120595.58.0.681101827563.issue42441@roundup.psfhosted.org> New submission from Md Tausif Iqbal : my application crashes File "c:\users\tausif\appdata\local\programs\python\python38-32\lib\csv.py", line 154, in writerow return self.writer.writerow(self._dict_to_list(rowdict)) File "c:\users\tausif\appdata\local\programs\python\python38-32\lib\encodings\cp1252.py", line 19, in encode return codecs.charmap_encode(input,self.errors,encoding_table)[0] UnicodeEncodeError: 'charmap' codec can't encode characters in position 22-29: character maps to I know this error is occurring due to a Hindi Language character. ---------- components: Library (Lib) messages: 381650 nosy: mdtausifiqbal priority: normal severity: normal status: open title: UnicodeEncodeError type: crash versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 07:10:03 2020 From: report at bugs.python.org (Ian Laughlin) Date: Mon, 23 Nov 2020 12:10:03 +0000 Subject: [New-bugs-announce] [issue42442] Tarfile to stdout documentation example Message-ID: <1606133403.23.0.511822994999.issue42442@roundup.psfhosted.org> New submission from Ian Laughlin : Recommend adding example to tarfile documentation to provide example of writing a tarfile to stdout. example: files = [(file_1, filename_1), (file_2, filename_2)] with tarfile.open(fileobj=sys.stdout.buffer, mode = 'w|gz') as tar: for file, filename in files: file_obj = io.BytesIO() #starts a BytesIO object file_obj.write(file.encode('utf-8')) #writes the file to the BytesIO object info = tarfile.TarInfo(filename) #creates the TarInfo file_obj.seek(0) #goes to the beginning of the BytesIO object else it won't write info.size = len(file) #sets the length of the file tar.addfile(info, fileobj=file_obj) #writes the tar to stdout. ---------- assignee: docs at python components: Documentation messages: 381665 nosy: docs at python, ilaughlin priority: normal severity: normal status: open title: Tarfile to stdout documentation example versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 10:21:52 2020 From: report at bugs.python.org (Piotr Stanczyk) Date: Mon, 23 Nov 2020 15:21:52 +0000 Subject: [New-bugs-announce] [issue42443] Provide Thread creation hook support Message-ID: <1606144912.59.0.960330614449.issue42443@roundup.psfhosted.org> New submission from Piotr Stanczyk : For monitoring purposes we would like to have a way of registering newly created Python threads with a runtime. For that reason we ask to add a thread creation hook inside threading.py. There are 2 similar hooks already (_profile_hook and _trace_hook). ---------- messages: 381672 nosy: stanczyk priority: normal severity: normal status: open title: Provide Thread creation hook support type: enhancement versions: Python 3.10 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 10:58:31 2020 From: report at bugs.python.org (Paul Ganssle) Date: Mon, 23 Nov 2020 15:58:31 +0000 Subject: [New-bugs-announce] [issue42444] pathlib.PurePath properties annotated with .. data directive Message-ID: <1606147111.69.0.159922070788.issue42444@roundup.psfhosted.org> New submission from Paul Ganssle : Currently, it seems that the pathlib module uses `.. data::` to annotate the properties of the PurePath type (e.g. .parts, .drive, .root, etc). See: https://github.com/python/cpython/blob/ff420f0e08a2443339da0df7ace95e14177bac53/Doc/library/pathlib.rst According to the documentation (https://devguide.python.org/documenting/#information-units), `data` is for module-level constants, specifically: > Describes global data in a module, including both variables and values used > as ?defined constants.? Class and object attributes are not documented using > this directive. I believe that we should switch these over to use the `.. attribute:` directive instead. >From what I can tell, you can still link to these attributes using the `:attr:` role. I haven't checked if you can link to `:attribute:`s using the `:data:` role, though. If not, it might break some links to change these to `:attribute:`. ---------- assignee: docs at python components: Documentation messages: 381673 nosy: docs at python, eric.araujo, ezio.melotti, mdk, p-ganssle, willingc priority: low severity: normal status: open title: pathlib.PurePath properties annotated with .. data directive versions: Python 3.10 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 10:58:37 2020 From: report at bugs.python.org (Jochen Kienzle) Date: Mon, 23 Nov 2020 15:58:37 +0000 Subject: [New-bugs-announce] [issue42445] Assertion in run_coroutine_threadsafe Message-ID: <1606147117.94.0.351862070018.issue42445@roundup.psfhosted.org> New submission from Jochen Kienzle : Hello, in my implementation I want to call mqtt_client.publish_json from a sync method: ----------------------------- def __on_event(self, ev): ... asyncio.run_coroutine_threadsafe(self.mqtt_client.publish_json(INGESTION_TOPIC, msg), loop=self.publish_loop) ----------------------------- where self.broker.publish_json is an async function and publish_loop is a loop which has been started (run_forever) in a separate thread: --- self.publish_loop = asyncio.new_event_loop() t = threading.Thread(target=self.publish_loop.run_forever) t.start() --- Sometimes (about 1 in 400 calls) I get the following Assertion Error: ----------------------------- ?[94;1m== APP == Exception in callback _ProactorBaseWritePipeTransport._loop_writing(<_OverlappedF...ed result=366>) ?[0m ?[94;1m== APP == handle: )> [0m [94;1m== APP == Traceback (most recent call last): [0m [94;1m== APP == File "C:\Users\sio7fe\AppData\Local\Programs\Python\Python38-32\lib\asyncio\events.py", line 81, in _run [0m [94;1m== APP == self._context.run(self._callback, *self._args) [0m [94;1m== APP == File "C:\Users\sio7fe\AppData\Local\Programs\Python\Python38-32\lib\asyncio\proactor_events.py", line 375, in _loop_writing [0m [94;1m== APP == assert f is self._write_fut [0m [94;1m== APP == AssertionError ----------------------------- Run time behavior: - publish_loop will be re-used on each event - run_coroutine_threadsafe will be called multiple times without any sleep (its in a for-loop with 1-3 elements) Since this is a thread safe method and its working multiple times, it seems to be some run-time related issue and I can't figure out the root cause. ---------- components: asyncio messages: 381674 nosy: JoKi, asvetlov, yselivanov priority: normal severity: normal status: open title: Assertion in run_coroutine_threadsafe type: behavior versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 12:00:36 2020 From: report at bugs.python.org (Thoradia Quack) Date: Mon, 23 Nov 2020 17:00:36 +0000 Subject: [New-bugs-announce] [issue42446] Assertion error os.path.exists(pyc_path) while building Python 3.8.6 with-ensurepip Message-ID: <1606150836.33.0.675733019507.issue42446@roundup.psfhosted.org> New submission from Thoradia Quack : I try building Python 3.8.6 with-ensurepip (see configuration below) but this fails with an assertion error (see error below). I do not understand the error and I do not know how to fix it. For what it is worth, I used to successfully build Python 3.8.5 with the same configuration. Thank you for any help with this. Configuration: home/thoradia/9.80.8/build.LibreELEC-RPi4.arm-9.80-devel/build/Python3-3.8.6/configure --host=x86_64-linux-gnu --build=x86_64-linux-gnu --prefix=/home/thoradia/9.80.8/build.LibreELEC-RPi4.arm-9.80-devel/toolchain --bindir=/home/thoradia/9.80.8/build.LibreELEC-RPi4.arm-9.80-devel/toolchain/bin --sbindir=/home/thoradia/9.80.8/build.LibreELEC-RPi4.arm-9.80-devel/toolchain/sbin --sysconfdir=/home/thoradia/9.80.8/build.LibreELEC-RPi4.arm-9.80-devel/toolchain/etc --libexecdir=/home/thoradia/9.80.8/build.LibreELEC-RPi4.arm-9.80-devel/toolchain/lib --localstatedir=/home/thoradia/9.80.8/build.LibreELEC-RPi4.arm-9.80-devel/toolchain/var --disable-static --enable-shared ac_cv_prog_HAS_HG=/bin/false ac_cv_prog_SVNVERSION=/bin/false --disable-pyc-build --disable-ossaudiodev --disable-sqlite3 --disable-codecs-cjk --disable-nis --enable-unicodedata --enable-openssl --disable-readline --enable-bzip2 --enable-zlib --enable-xz --disable-tk --disable-curses --disable-pydoc --disable-test-modules --enable-lib2to3 --disable-idle3 --without-cxx-main --with-expat=builtin --with-libmpdec=none --with-doc-strings --with-system-ffi --without-pymalloc --with-ensurepip Error: if test "xupgrade" != "xno" ; then \ case upgrade in \ upgrade) ensurepip="--upgrade" ;; \ install|*) ensurepip="" ;; \ esac; \ LD_LIBRARY_PATH=/home/thoradia/9.80.8/build.LibreELEC-RPi4.arm-9.80-devel/build/Python3-3.8.6/.x86_64-linux-gnu ./python -E -m ensurepip \ $ensurepip --root=/ ; \ fi Looking in links: /tmp/tmpm7whdxa4 Requirement already up-to-date: setuptools in /home/thoradia/9.80.8/build.LibreELEC-RPi4.arm-9.80-devel/toolchain/lib/python3.8/site-packages (49.2.1) Processing /tmp/tmpm7whdxa4/pip-20.2.1-py2.py3-none-any.whl Installing collected packages: pip ERROR: Exception: Traceback (most recent call last): File "/tmp/tmpm7whdxa4/pip-20.2.1-py2.py3-none-any.whl/pip/_internal/cli/base_command.py", line 216, in _main status = self.run(options, args) File "/tmp/tmpm7whdxa4/pip-20.2.1-py2.py3-none-any.whl/pip/_internal/cli/req_command.py", line 182, in wrapper return func(self, options, args) File "/tmp/tmpm7whdxa4/pip-20.2.1-py2.py3-none-any.whl/pip/_internal/commands/install.py", line 412, in run installed = install_given_reqs( File "/tmp/tmpm7whdxa4/pip-20.2.1-py2.py3-none-any.whl/pip/_internal/req/__init__.py", line 82, in install_given_reqs requirement.install( File "/tmp/tmpm7whdxa4/pip-20.2.1-py2.py3-none-any.whl/pip/_internal/req/req_install.py", line 813, in install install_wheel( File "/tmp/tmpm7whdxa4/pip-20.2.1-py2.py3-none-any.whl/pip/_internal/operations/install/wheel.py", line 852, in install_wheel _install_wheel( File "/tmp/tmpm7whdxa4/pip-20.2.1-py2.py3-none-any.whl/pip/_internal/operations/install/wheel.py", line 734, in _install_wheel assert os.path.exists(pyc_path) AssertionError ---------- components: Build messages: 381680 nosy: thoradia priority: normal severity: normal status: open title: Assertion error os.path.exists(pyc_path) while building Python 3.8.6 with-ensurepip type: behavior versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 12:53:43 2020 From: report at bugs.python.org (Net Offensive) Date: Mon, 23 Nov 2020 17:53:43 +0000 Subject: [New-bugs-announce] [issue42447] robotsparser deny all with some rules Message-ID: <1606154023.13.0.203747153119.issue42447@roundup.psfhosted.org> New submission from Net Offensive : Bonjour, Notre d?veloppeur a un soucis avec l'utilisation de cette librairie. Dans le cadre d'un projet SEO, nous souhaiterions scrapper les pages de notre r?seau de site. Nous avons essay? de tester avec l'un de nos site dont les pages se pr?sentent comme ce guide sur le r?f?rencement : https://www.netoffensive.blog/referencement-naturel/ Elle ne sont pas d?tect?es comme des pages ? cause de leur forme en repertoire. A ton besoin forc?ment de cr?er des pages du type : page.ext ? C'est pourtant un format utilis? sur Wordpress et d'autres CMS. Merci --------------- Hello, Our developer has a problem with the use of this library. As part of an SEO project, we would like to scramble the pages of our site network. We tried to test with one of our site whose pages look like this SEO guide: https://www.netoffensive.blog/referencement-naturel/. They are not detected as pages because of their directory shape. Do you necessarily need to create pages of the type: page.ext? It is however a format used on Wordpress and other CMS. Thanks Translated with www.DeepL.com/Translator (free version) ---------- components: Library (Lib) messages: 381683 nosy: contact priority: normal severity: normal status: open title: robotsparser deny all with some rules type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 14:30:57 2020 From: report at bugs.python.org (=?utf-8?b?6LW16LGq5p2w?=) Date: Mon, 23 Nov 2020 19:30:57 +0000 Subject: [New-bugs-announce] [issue42448] re.findall have different match result against re.search or re.sub Message-ID: <1606159857.65.0.962689074974.issue42448@roundup.psfhosted.org> New submission from ??? <1292756898 at qq.com>: ``` >>> import re >>> text = '121212 and 121212' >>> pattern = '(12)+' >>> print(re.findall(pattern, text)) ['12', '12'] >>> >>> >>> print(re.search(pattern, text)) >>> >>> >>> print(re.sub(pattern, '', text)) and # The re.findall have different search result against re.search or re.sub # re.findall ? re.search ? re.sub ???????? ``` With same pattern and string, the re.findall is supposed to have same match with re.search, but it didn't. This result is from python3.8.5 ---------- components: Regular Expressions messages: 381689 nosy: HaujetZhao, ezio.melotti, mrabarnett priority: normal severity: normal status: open title: re.findall have different match result against re.search or re.sub type: behavior versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 17:06:39 2020 From: report at bugs.python.org (void abuser) Date: Mon, 23 Nov 2020 22:06:39 +0000 Subject: [New-bugs-announce] [issue42449] Adding number to a declared 2 dimension list Message-ID: <1606169199.89.0.319403348996.issue42449@roundup.psfhosted.org> New submission from void abuser : So basically the bug that I found was about adding a number to a sub-list. If you declare li1 as li1=[[0,0,0,0],[0,0,0,0],[0,0,0,0],[0,0,0,0]] in the code below then the code is working as it should do. Although if you create the list called li1 with the same way how I did in the code below (which has the same outcome in terms of looking at that 2 dimension list) then the output is different and in fact false. The code: li1=[[0]*4]*4 for x in range(4): li1[0][1]+=1 print(li1) Expected behavior Expected output: [[0, 1, 0, 0], [0, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 0]] [[0, 2, 0, 0], [0, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 0]] [[0, 3, 0, 0], [0, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 0]] [[0, 4, 0, 0], [0, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 0]] The output that I got: [[0, 1, 0, 0], [0, 1, 0, 0], [0, 1, 0, 0], [0, 1, 0, 0]] [[0, 2, 0, 0], [0, 2, 0, 0], [0, 2, 0, 0], [0, 2, 0, 0]] [[0, 3, 0, 0], [0, 3, 0, 0], [0, 3, 0, 0], [0, 3, 0, 0]] [[0, 4, 0, 0], [0, 4, 0, 0], [0, 4, 0, 0], [0, 4, 0, 0]] ---------- components: Regular Expressions files: bug.png messages: 381698 nosy: ezio.melotti, mrabarnett, void4buser priority: normal severity: normal status: open title: Adding number to a declared 2 dimension list type: behavior versions: Python 3.9 Added file: https://bugs.python.org/file49615/bug.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Nov 23 20:54:26 2020 From: report at bugs.python.org (Peter Norvig) Date: Tue, 24 Nov 2020 01:54:26 +0000 Subject: [New-bugs-announce] [issue42450] Docstrings in itertools recipes should have triple-quotes Message-ID: <1606182866.42.0.941148595918.issue42450@roundup.psfhosted.org> New submission from Peter Norvig : In the itertools recipes ( https://docs.python.org/3/library/itertools.html#itertools-recipes ) there are 21 functions that have single-quote docstrings. These should be changed to triple-quotes, as mandated in PEP 257. ---------- messages: 381704 nosy: peter.norvig2 priority: normal severity: normal status: open title: Docstrings in itertools recipes should have triple-quotes versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 04:41:26 2020 From: report at bugs.python.org (Antony Lee) Date: Tue, 24 Nov 2020 09:41:26 +0000 Subject: [New-bugs-announce] [issue42451] Indicate in the docs that PyTuple_GetItem does not support negative indices Message-ID: <1606210886.35.0.910586888389.issue42451@roundup.psfhosted.org> New submission from Antony Lee : Unlike `PySequence_GetItem`, `PyTuple_GetItem` does not support negative indices ("indexing from the end"). That is fine, but warrants a notice in the docs (as that behavior is certainly not obvious). The same wording as for `PyList_GetItem` (changing "list" to "tuple") should be good enough (`PyList_GetItem` currently states: "The position must be non-negative; indexing from the end of the list is not supported. If index is out of bounds (<0 or >=len(list)), return NULL and set an IndexError exception.") ---------- assignee: docs at python components: C API, Documentation messages: 381716 nosy: Antony.Lee, docs at python priority: normal severity: normal status: open title: Indicate in the docs that PyTuple_GetItem does not support negative indices versions: Python 3.10 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 09:09:55 2020 From: report at bugs.python.org (Julien Jerphanion) Date: Tue, 24 Nov 2020 14:09:55 +0000 Subject: [New-bugs-announce] [issue42452] FIX Optimize 'rgb_to_hls' Message-ID: <1606226995.94.0.128298761861.issue42452@roundup.psfhosted.org> New submission from Julien Jerphanion : This issue has been created after the PR. ---------- components: Library (Lib) messages: 381748 nosy: jjerphan priority: normal pull_requests: 22385 severity: normal status: open title: FIX Optimize 'rgb_to_hls' type: enhancement versions: Python 3.10 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 11:26:27 2020 From: report at bugs.python.org (=?utf-8?b?6LW16LGq5p2w?=) Date: Tue, 24 Nov 2020 16:26:27 +0000 Subject: [New-bugs-announce] [issue42453] utf-8 codec error when pip uninstalling a package which has files containing unicode filename on Windows Message-ID: <1606235187.45.0.542626123736.issue42453@roundup.psfhosted.org> New submission from ??? <1292756898 at qq.com>: When using `pip install package_name` installing a package, it will generate a `installed-files.txt` file, which records the file that the package contains. When updating or uninstalling the package, pip will need to read the `installed-files.txt` file, then delete the old files. If the package installed contains files whose name has unicode character like `??`, the problem will occur. In China (I don't know other places), for historical reasons, the Windows default system codec is `gbk`, so the `installed-files.txt` file is also written with `gbk` codec when installing a package. When it comes to updating or uninstalling, the pip will use `utf-8` codec to read the `installed-files.txt` file. Since the file contains non ascii characters, it went error: ``` File "d:\users\haujet\appdata\local\programs\python\python39\lib\site-packages\pip\_vendor\pkg_resources\__init__.py", line 1424, in get_metadata return value.decode('utf-8') UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb8 in position 343: invalid start byte in installed-files.txt file at path: d:\users\haujet\appdata\local\programs\python\python39\lib\site-packages\Markdown_Toolbox-0.0.8-py3.9.egg-info\installed-files.txt ``` I hate that default `gbk` system codec, but this set is fixed on Windows. So, my suggestion is, make a `try except` at the error point, if the `utf-8` codec went wrong reading `installed-files.txt`, then let `gbk` codec have a go. Or, more foundamental solution is, when pip writing text files, strictly use `utf-8` codec instead of the default system codec. ---------- components: Windows messages: 381753 nosy: HaujetZhao, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: utf-8 codec error when pip uninstalling a package which has files containing unicode filename on Windows type: crash versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 12:11:37 2020 From: report at bugs.python.org (Batuhan Taskaya) Date: Tue, 24 Nov 2020 17:11:37 +0000 Subject: [New-bugs-announce] [issue42454] Move slice creation to the compiler for constants Message-ID: <1606237897.31.0.957567165008.issue42454@roundup.psfhosted.org> New submission from Batuhan Taskaya : Currently, all the slices are created by the interpreter with BUILD_SLICE preceded by 2/3 LOAD_CONSTS. We can move the slice creation into the compiler and deduce the cost of these 3/4 instructions into a single LOAD_CONST operation where all values in the slices are constants (like [:1], [::2], [-1]) which I assume the most common type. There are over 93.000 constant slices in 3.200~ PyPI packages, which I'd assume is a huge amount (ofc I don't claim to know that whether these are in loops / hot functions or static globals). Making these folding could save up to 1.32x on very common slicing behaviors (like [:1]). Here are the benchmarks (thanks to @pablogsal); *** -s "a=list(range(200))" "a[:1]" Mean +- std dev: [baseline] 61.8 ns +- 0.3 ns -> [optimized] 47.1 ns +- 0.2 ns: 1.31x faster (-24%) *** -s "a=list(range(200))" "a[1:1:1], a[::1], a[1::], a[1::1], a[::-1], a[-1::], a[:], a[::]" Mean +- std dev: [baseline] 2.38 us +- 0.02 us -> [optimized] 2.24 us +- 0.02 us: 1.06x faster (-6%) The macro benchmarks appeared to be +1.03x increase which is assumed as noise, so this is a targeted optimization. One problem with slices being constants is that, the code objects are hashable so does all the items in the co_consts tuple (also the internal dict that the compiler uses to store all co_const items). For allowing slices to be stored in the code objects, and not changing any behavior in a backward-incompatible way I'm proposing to make the slice objects hashable. It might not be seen as a feature, but a side-effect caused by this optimization. ---------- messages: 381759 nosy: BTaskaya, pablogsal priority: normal severity: normal status: open title: Move slice creation to the compiler for constants type: performance versions: Python 3.10 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 15:34:37 2020 From: report at bugs.python.org (Yurii Karabas) Date: Tue, 24 Nov 2020 20:34:37 +0000 Subject: [New-bugs-announce] [issue42455] Add decorator_with_params function to functools module Message-ID: <1606250077.84.0.747907374749.issue42455@roundup.psfhosted.org> New submission from Yurii Karabas <1998uriyyo at gmail.com>: In the current python codebases, there are a lot of decorators with parameters, and their code in most cases contains a lot of code boilerplates. The purpose of this issue is to add `decorator_with_params` function to `functools` module. This function will allow using a wrapped function as a simple decorator and decorator with parameter. I believe the real example will bring more context, for instance, `typing._tp_cache` function can be rewritten from: ``` def _tp_cache(func=None, /, *, typed=False): """Internal wrapper caching __getitem__ of generic types with a fallback to original function for non-hashable arguments. """ def decorator(func): cached = functools.lru_cache(typed=typed)(func) _cleanups.append(cached.cache_clear) @functools.wraps(func) def inner(*args, **kwds): try: return cached(*args, **kwds) except TypeError: pass return func(*args, **kwds) return inner if func is not None: return decorator(func) return decorator ``` To ``` @decorator_with_params def _tp_cache(func=None, /, *, typed=False): """Internal wrapper caching __getitem__ of generic types with a fallback to original function for non-hashable arguments. """ cached = functools.lru_cache(typed=typed)(func) _cleanups.append(cached.cache_clear) @functools.wraps(func) def inner(*args, **kwds): try: return cached(*args, **kwds) except TypeError: pass # All real errors (not unhashable args) are raised below. return func(*args, **kwds) return inner ``` And `_tp_cache` can be used as: ``` @_tp_cache(typed=True) def __getitem__(self, parameters): return self._getitem(self, parameters) ... @_tp_cache def __getitem__(self, parameters): return self._getitem(self, parameters) ``` Proposed implementation is quite simple (I used it in a lot of projects): ``` def decorator_with_params(deco): @wraps(deco) def decorator(func=None, /, *args, **kwargs): if func is not None: return deco(func, *args, **kwargs) def wrapper(f): return deco(f, *args, **kwargs) return wrapper return decorator ``` I believe it will be a great enhancement for the Python standard library and will save such important indentations. ---------- components: Library (Lib) messages: 381773 nosy: uriyyo priority: normal severity: normal status: open title: Add decorator_with_params function to functools module type: enhancement versions: Python 3.10 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 23:19:56 2020 From: report at bugs.python.org (Nishant Gautam) Date: Wed, 25 Nov 2020 04:19:56 +0000 Subject: [New-bugs-announce] [issue42456] Logical Error Message-ID: <1606277996.92.0.109667336628.issue42456@roundup.psfhosted.org> New submission from Nishant Gautam : The python programming give wrong output. If any algorithm develop in python then, may be that will be affected by this. ---------- files: 0_PROOF.png hgrepos: 394 messages: 381787 nosy: Kshitish priority: normal severity: normal status: open title: Logical Error type: behavior versions: Python 3.8 Added file: https://bugs.python.org/file49617/0_PROOF.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Nov 24 23:36:54 2020 From: report at bugs.python.org (Carson Wilber) Date: Wed, 25 Nov 2020 04:36:54 +0000 Subject: [New-bugs-announce] [issue42457] ArgumentParser nested subparsers resolve paths in improper order Message-ID: <1606279014.6.0.265447168891.issue42457@roundup.psfhosted.org> New submission from Carson Wilber : ArgumentParser improperly resolves arguments in an improper order when using nested subparsers if there are required arguments at more than one layer. A minimum viable reproduction is to create a set of subparsers on a primary parser, and a set of subparsers on at least one of those parsers. On the main parser and the first-level subparser, add a required argument (in any position as they are appended to the end.) If you attempt to, for example, print the help for a second-level subparser, an error will be thrown and the parser will exit due to the required argument(s) not being provided, despite the expected behavior and the nature of the -h flag not requiring those arguments to be provided. For lack of an appropriate means to show a complete minimum viable reproduction here, please see this StackOverflow thread I initially created believing this to be user error (having now determined this is a bug in behavior): https://stackoverflow.com/questions/64908447/printing-help-for-nested-subparsers-with-required-positional-arguments ---------- messages: 381789 nosy: carsonwilber priority: normal severity: normal status: open title: ArgumentParser nested subparsers resolve paths in improper order type: behavior versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 00:42:59 2020 From: report at bugs.python.org (John Engelke) Date: Wed, 25 Nov 2020 05:42:59 +0000 Subject: [New-bugs-announce] [issue42458] Pathlib resolve() on Mac Catalina prepends secret path Message-ID: <1606282979.63.0.164554102879.issue42458@roundup.psfhosted.org> New submission from John Engelke : On Mac OS X Catalina+, Pathlib's resolve() method prepends the System Integrity Protection (SIP) path to the front of the resolved Path, whether you like it or not. >>> from pathlib import Path >>> host_path_str = "/home/somewhere/there/../nowhere" >>> host_path = Path(host_path_str) >>> host_path PosixPath('/home/somewhere/there/../nowhere') >>> host_path.resolve() PosixPath('/System/Volumes/Data/home/somewhere/nowhere') >>> import platform >>> platform.platform() 'Darwin-19.6.0-x86_64-i386-64bit' >>> import sys >>> print (sys.version) 3.7.3 (v3.7.3:ef4ec6ed12, Mar 25 2019, 16:52:21) [Clang 6.0 (clang-600.0.57)] >>> In my particular case, I'm just using this feature to resolve paths for an FTP host, so the path is contrived and doesn't actually exist locally. As one may guess, this breaks my FTP transfers by foisting a path on me that isn't on the server. I know there are other tix for Pathlib's erratic behavior across platforms which don't talk about this specific issue. I don't think it a behavior across platforms thing, anyway. Pathlib obviously isn't behaving nicely with SIP and Apple's Firmlink wormhole like directory traversal stuffs. Oy vey! ---------- components: macOS messages: 381792 nosy: john.engelke, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: Pathlib resolve() on Mac Catalina prepends secret path type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Nov 25 03:55:15 2020 From: report at bugs.python.org (Nishant Gautam) Date: Wed, 25 Nov 2020 08:55:15 +0000 Subject: [New-bugs-announce] [issue42459] Wrong Output Message-ID: <1606294515.33.0.266172391844.issue42459@roundup.psfhosted.org> New submission from Nishant Gautam