[issue39763] distutils.spawn should use subprocess (hang in parallel builds on QNX)

Antoine Pitrou added the comment: @Elad: > I'm not convinced that a multi-threaded fork()+exec() from C would be any > better, unless the Python code goes to great lengths to avoid any > non-async-signal-safe operations between the fork() and the exec(). That's exactly what the C code in th

[issue39809] argparse: add max_text_width parameter to ArgumentParser

Change by Karthikeyan Singaravelan : -- nosy: +paul.j3, rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscr

[issue39811] Curses crash on ^4

New submission from toonn : We got a report about a crash which seems to happen in the curses library when a user pressed ^4. How do we go about debugging this? https://github.com/ranger/ranger/issues/1859 -- components: Library (Lib) messages: 363057 nosy: toonn priority: normal seve

[issue39810] Generic script for finding bugs in get_source_segment

New submission from Alex Hall : Attached is a script which: - Gets all the source code it can find from sys.modules - Looks at every node in the parsed source - Gets source text for that node using ast.get_source_segment - Parses the source text again - Compares the original node with the newly

[issue39577] venv --prompt argument is ignored

Andrea added the comment: Actually, the virtual_info appears to be a function within the theme, that does the following function virtualenv_info { [ $VIRTUAL_ENV ] && echo '('%F{blue}`basename $VIRTUAL_ENV`%f') ' } So, eventually the problems is in the function that retrieves the wrong

[issue39577] venv --prompt argument is ignored

Andrea added the comment: Hi, Apologies for the delays in returning to you. I have been using ZSH and Oh My ZSH on top. The prompt variable, which I have customised, looks like the following: % $(virtualenv_info)$fg[magenta]%}%n%{$reset_color%}@%{$fg[yellow]%}$(box_name)%{$reset_color%}:%{

[issue39809] argparse: add max_text_width parameter to ArgumentParser

New submission from Luca : It is often desirable to limit the help text width, for instance to 78 or 88 columns, regardless of the actual size of the terminal window. Currently you can achieve this in rather cumbersome ways, for instance by setting "os.environ['COLUMNS'] = '80'" (but this req

[issue39776] Crash in decimal module in heavy-multithreaded scenario

Change by Antoine Pitrou : -- priority: normal -> critical versions: +Python 3.9 ___ Python tracker ___ ___ Python-bugs-list mailing

[issue39808] pathlib: reword docs for stat()

Change by swgmma : -- keywords: +patch pull_requests: +18076 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18719 ___ Python tracker ___ _

[issue39808] pathlib: reword docs for stat()

New submission from swgmma : The docs for stat() (https://docs.python.org/3.9/library/pathlib.html#pathlib.Path.stat) state: > Return information about this path (similarly to os.stat()). The result is > looked up at each call to this method." Nit picks: 1) It states "similarly to os.stat()

[issue39806] different behavior between __ior__ and __or__ in dict made by PEP 584

Change by Manjusaka : -- nosy: +xtreak ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.or

[issue39807] Python38 installed in wrong directory on Windows

New submission from Young Wong : I'm on Windows 10 and downloaded the Python 3.8 installation package. I explicitly selected `C:\Program Files\Python38` as my installation path during in the menu, but it installs it in `C:\Program Files (x86)\Python38` at the end. My `C:\Program Files` has Py

[issue39806] different behavior between __ior__ and __or__ in dict made by PEP 584

Manjusaka added the comment: > Augmented assignment behaves identically to the update method called with a > single positional argument, so it also accepts anything implementing the > Mapping protocol (more specifically, anything with the keys and __getitem__ > methods) or iterables of key-v

[issue39806] different behavior between __ior__ and __or__ in dict made by PEP 584

Manjusaka added the comment: In my opinion, make more lenient or not is OK, but we should guarantee the magic method should keep clean and right meaning For example, the __iadd__ in std data structure should be as same as the __add__ except it's an in-place operator. If it's necessary, I wi

[issue39806] different behavior between __ior__ and __or__ in dict made by PEP 584

Change by Karthikeyan Singaravelan : -- nosy: +serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe

[issue39806] different behavior between __ior__ and __or__ in dict made by PEP 584

Karthikeyan Singaravelan added the comment: > Augmented assignment behaves identically to the update method called with a > single positional argument, so it also accepts anything implementing the > Mapping protocol (more specifically, anything with the keys and __getitem__ > methods) or ite

[issue39806] different behavior between __ior__ and __or__ in dict made by PEP 584

Serhiy Storchaka added the comment: It is how PEP 584 specifies it. The in-place operator is more lenient. It corresponds the behavior of list operators. >>> x = [] >>> y = (1, 2) >>> x + y Traceback (most recent call last): File "", line 1, in TypeError: can only concatenate list (not "tu

[issue39806] different behavior between __ior__ and __or__ in dict made by PEP 584

Change by Karthikeyan Singaravelan : -- nosy: +brandtbucher, gvanrossum, steven.daprano ___ Python tracker ___ ___ Python-bugs-list

[issue30082] hide command prompt when using subprocess.Popen with shell=False on Windows

swgmma added the comment: Sorry, perhaps I did not word it clearly. Indeed the code to implement this looks trivial, however the part I am having trouble with is reproducing the reported issue in the first place. For example, running the attached file from a command prompt (`python test.py`)

[issue39806] different behavior between __ior__ and __or__ in dict made by PEP 584

New submission from Manjusaka : Hello Guys: I have tried Python 3.9.0a4, I have an issue: the __ior__ and the __or__ have different behavior For example: x={} y=[(1,2)] x|=y is right and x=x|y will raise an exception. I think it's should be better make the same between two magic method ?

<    1   2