[issue25532] infinite loop when running inspect.unwrap over unittest.mock.call

Thomas Kluyver added the comment: I could go either way on that. It's not hard to imagine it as a recursive algorithm, and using the recursion limit provides a simple configuration escape hatch if someone has a desperate need for something wrapped 3000 times for some strange reason. But it

[issue30431] input function truncates prompt by NULL byte

Changes by Kushal Das : -- nosy: +kushal.das ___ Python tracker ___ ___ Python-bugs-list

[issue30433] Devguide lacks instructions for building docs

Stéphane Wirtel added the comment: Hello, Are you sure about the PR ? -- nosy: +matrixise ___ Python tracker ___

[issue30433] Devguide lacks instructions for building docs

New submission from Caleb Hattingh: The official devguide at https://github.com/python/devguide does not include instructions on exactly how to build the docs! If, after cloning, you simply type `make`, you get some helpful output: $ make Please use `make ' where is one of html to

[issue30432] FileInput doesn't accept PathLike objects for file names

New submission from Roy Williams: ``` from fileinput import FileInput from pathlib import Path p = Path('.') FileInput(p) ``` Results in: Traceback (most recent call last): File "", line 1, in File

[issue23894] lib2to3 doesn't recognize rb'...' and f'...' in Python 3.6

Changes by Łukasz Langa : -- pull_requests: +1811 ___ Python tracker ___ ___

[issue25532] infinite loop when running inspect.unwrap over unittest.mock.call

Yury Selivanov added the comment: > Since the limit is arbitrary anyway, sys.getrecursionlimit() seems like a > reasonable choice. The recursion limit can be changed for whatever purposes and I'm not sure that it's a good idea that it will affect unwrap behaviour in such cases. I'd suggest

[issue30339] test_multiprocessing_main_handling: "RuntimeError: Timed out waiting for results" on x86 Windows7 3.x

Davin Potts added the comment: Patch on issue30317 also addresses this issue in a more flexible way. -- dependencies: +test_timeout() of test_multiprocessing_spawn.WithManagerTestBarrier fails randomly on x86 Windows7 3.x buildbot nosy: +davin ___

[issue30317] test_timeout() of test_multiprocessing_spawn.WithManagerTestBarrier fails randomly on x86 Windows7 3.x buildbot

Davin Potts added the comment: To better accommodate very slow buildbots, a parameter is added in PR-1722 to scale up the timeout durations where they are necessary on a per-machine basis. Relevant tests have a timeout set to some default number of seconds times a multiplier value. The

[issue30395] deadlocked child process after forking on pystate.c's head_mutex

Gregory P. Smith added the comment: You cannot safely use Python's os.fork() in a process that has threads. Because of POSIX. The CPython interpreter is by definition not async signal safe so no Python code may safely be executed after the fork() system call if the process contained _any_

[issue19764] subprocess: use PROC_THREAD_ATTRIBUTE_HANDLE_LIST with STARTUPINFOEX on Windows Vista

Segev Finer added the comment: GitHub PR bit rotting away... :P Just a friendly reminder :) -- ___ Python tracker ___

[issue30317] test_timeout() of test_multiprocessing_spawn.WithManagerTestBarrier fails randomly on x86 Windows7 3.x buildbot

Changes by Davin Potts : -- pull_requests: +1810 ___ Python tracker ___ ___

[issue30003] Fix handling escape characters in HZ codec

Xiang Zhang added the comment: New changeset 6e1b832a6c0c8f32962a196ab631ccc17471d32b by Xiang Zhang in branch '2.7': bpo-30003: Fix handling escape characters in HZ codec (#1720) (#1556) https://github.com/python/cpython/commit/6e1b832a6c0c8f32962a196ab631ccc17471d32b --

[issue30003] Fix handling escape characters in HZ codec

Changes by Xiang Zhang : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue30003] Fix handling escape characters in HZ codec

Xiang Zhang added the comment: New changeset 54af41d42eebbe4c6afe6b34ebb0fb550de1e7ba by Xiang Zhang in branch '3.6': bpo-30003: Fix handling escape characters in HZ codec (#1556) (#1719) https://github.com/python/cpython/commit/54af41d42eebbe4c6afe6b34ebb0fb550de1e7ba --

[issue30003] Fix handling escape characters in HZ codec

Xiang Zhang added the comment: New changeset 65440f8278351e16350be716dff61f5f786f7060 by Xiang Zhang in branch '3.5': bpo-30003: Fix handling escape characters in HZ codec (#1556) (#1718) https://github.com/python/cpython/commit/65440f8278351e16350be716dff61f5f786f7060 --

[issue24658] open().write() fails on 2 GB+ data (OS X)

Stéphane Wirtel added the comment: 1. in the case of Windows, maybe we could open a new issue because this fix is only for MacOS 2. the issue was only for the files and not the sockets what do you suggest ? -- ___ Python tracker

[issue30395] deadlocked child process after forking on pystate.c's head_mutex

Changes by Cooper Lees : -- nosy: +cooperlees ___ Python tracker ___ ___

[issue16500] Allow registering at-fork handlers

Antoine Pitrou added the comment: > If the corresponding warnings are ignored, nothing happen, if they are > errors, the child is exited, Right now PyOS_AfterFork() doesn't return an error code. It is not obvious how the caller would react: simply print the error? raise a fatal error?

[issue30430] Cannot write to a tun interface file

Rémy Léone added the comment: I've tackle the 1. by replacing write/open with os.write/os.open. I still get : $ python3 simple_incorrect.py b'\xc3\xa9' Traceback (most recent call last): File "simple_incorrect.py", line 32, in os.write(tun, incorrect_frame) OSError: [Errno 22] Invalid

[issue21074] Too aggressive constant folding

Raymond Hettinger added the comment: > (I reopen the issue since it got a long new comment.) Andrew specifically said, "I don't propose re-opening it". FWIW, the zen of python also says, "practicality beats purity". For most users, most of the time, the peephole optimizer is a net win and it

[issue30429] bdb and pdb: Add watchpoint function

Changes by Louie Lu : -- type: -> enhancement ___ Python tracker ___ ___ Python-bugs-list

[issue30429] bdb and pdb: Add watchpoint function

Changes by Raymond Hettinger : -- title: bdb: Add watchpoint function -> bdb and pdb: Add watchpoint function ___ Python tracker

[issue30430] Cannot write to a tun interface file

Antoine Pitrou added the comment: I know nothing about TUN but you may simply be hitting this code path: https://github.com/spotify/linux/blob/master/drivers/net/tun.c#L601-L614 Since: >>> ('e'.encode()[0] & 0xf0) in (0x40, 0x60) True >>> ('é'.encode()[0] & 0xf0) in (0x40, 0x60) False writing

[issue30430] Cannot write to a tun interface file

Antoine Pitrou added the comment: So basically the write() system call seems to be returning EINVAL. Can I suggest the following steps: 1. try to reproduce using os.open() and os.write() instead of open() and write() (just to make sure something doesn't get in the way) 2. if it still fails,

[issue30430] Cannot write to a tun interface file

Rémy Léone added the comment: The question I'm the most interested about is why depending on what the bytes object contains I get a different result. In one case the bytes are written fine to the TUN interface file descriptor and in the other case I get an Errno22. My assumption is that the

[issue30003] Fix handling escape characters in HZ codec

Changes by Xiang Zhang : -- pull_requests: +1809 ___ Python tracker ___ ___

[issue30431] input function truncates prompt by NULL byte

New submission from Костя Чолак: input('some\x00 text') will prompt for `some` instead of `some text` -- components: IO messages: 294153 nosy: Костя Чолак priority: normal severity: normal status: open title: input function truncates prompt by NULL byte type: behavior versions: Python

[issue30430] Cannot write to a tun interface file

Rémy Léone added the comment: Traceback (most recent call last): File "simple_incorrect.py", line 31, in tun.write(incorrect_frame) OSError: [Errno 22] Invalid argument -- ___ Python tracker

[issue30430] Cannot write to a tun interface file

Antoine Pitrou added the comment: Would you care to post the detailed error and traceback here? Not everyone wants to set up a TUN interface to try to reproduce :-) -- nosy: +pitrou ___ Python tracker

[issue30003] Fix handling escape characters in HZ codec

Changes by Xiang Zhang : -- pull_requests: +1808 ___ Python tracker ___ ___

[issue30003] Fix handling escape characters in HZ codec

Changes by Xiang Zhang : -- pull_requests: +1807 ___ Python tracker ___ ___

[issue30003] Fix handling escape characters in HZ codec

Xiang Zhang added the comment: New changeset 89a5e03244370f41ce9bed5cea38e0dd620edb73 by Xiang Zhang in branch 'master': bpo-30003: Fix handling escape characters in HZ codec (#1556) https://github.com/python/cpython/commit/89a5e03244370f41ce9bed5cea38e0dd620edb73 --

[issue16500] Allow registering at-fork handlers

Serhiy Storchaka added the comment: PyOS_AfterFork() is used by one code, but the "before" and "parent" handlers are registered by the other code (likely the code of other library). The author of the program that uses both libraries (the one that uses PyOS_AfterFork() and the one that

[issue16500] Allow registering at-fork handlers

Antoine Pitrou added the comment: I don't think exiting would be a good idea at all. I'm not sure about emitting a warning: the problem is that the people seeing the warning (plain users) can't do anything about it; worse, they probably will not even understand what it is about, and will get

[issue16500] Allow registering at-fork handlers

Serhiy Storchaka added the comment: I agree that with lambdas and functools.partial the support of arguments is not needed. Unless someone has good reasons for supporting explicit passing of arguments I'm fine with your design. If the user code manually calls the fork() and (now deprecated)

[issue16500] Allow registering at-fork handlers

Antoine Pitrou added the comment: API-wise, I went for the minimal route. This avoids any discussion of adding a separate module for a tiny functionality that is only going to be used by a couple of libraries (and probably no application code). Comparisons with atexit are not really relevant,

[issue16500] Allow registering at-fork handlers

Serhiy Storchaka added the comment: `atexit.register()` has different signature and allows to pass arbitrary positional and keyword arguments to the registered function. This is incompatible with the "when" argument. If we want to support registering arguments with the function, we need

[issue30426] why not use the same style func name. eg: int.to_bytes (with underline) and array.tobytes(without underline).

Eric V. Smith added the comment: There's no particular reason, we just weren't careful about enforcing a consistent style, especially on older code. But whatever the reason, it's now too late to change this. -- nosy: +eric.smith resolution: -> wont fix stage: -> resolved status:

[issue30430] Cannot write to a tun interface file

New submission from Rémy Léone: I cannot write certain bytes object to a tun interface file. I've added a working and unworking example in the attached file. I'm running on Ubuntu16.04 with Python 3.5.2 -- components: IO files: simple_incorrect.py messages: 294143 nosy: Rémy Léone

[issue25532] infinite loop when running inspect.unwrap over unittest.mock.call

Thomas Kluyver added the comment: This was just reported in IPython as well (https://github.com/ipython/ipython/issues/10578 ). I've prepared a pull request based on Nick's proposal: https://github.com/python/cpython/pull/1717 -- nosy: +takluyver

[issue25532] infinite loop when running inspect.unwrap over unittest.mock.call

Changes by Thomas Kluyver : -- pull_requests: +1806 ___ Python tracker ___ ___

[issue16500] Allow registering at-fork handlers

Changes by Antoine Pitrou : -- title: Add an 'atfork' module -> Allow registering at-fork handlers ___ Python tracker ___

[issue16500] Add an 'atfork' module

Antoine Pitrou added the comment: I've posted https://github.com/python/cpython/pull/1715 which adds a single `os.register_at_fork` function to allow registering at-fork handlers. Comments welcome. -- stage: -> patch review versions: +Python 3.7 -Python 3.5

[issue16500] Add an 'atfork' module

Changes by Antoine Pitrou : -- pull_requests: +1805 ___ Python tracker ___ ___

[issue30429] bdb: Add watchpoint function

New submission from Louie Lu: Trying to add watchpoint function to bdb and pdb. It's goal is to do as gdb for three different watch: watch, rwatch and a watch. watch: when expr is written by program and value has changed, it will break rwatch: when expr is read by program, it will break

[issue30290] IDLE: add tests for help_about.py

Cheryl Sabella added the comment: I've made a pull request for 4, 5, and 6. I didn't remove the tk constants as it seemed you'd like to do all the files in one project for that. Also, in query.Query, I noticed that all the widgets were created first and then they were all added to the grid

[issue30290] IDLE: add tests for help_about.py

Changes by Cheryl Sabella : -- pull_requests: +1804 ___ Python tracker ___ ___

[issue18123] fnmatchicase for case insensitive file search

Changes by Serhiy Storchaka : -- status: open -> pending ___ Python tracker ___

[issue30428] mailbox.MMDF wrongly adds From_ header to file

New submission from Ralph Corderoy: Class mailbox.MMDF supports the MMDF-mail-spool file format. This is a file with zero or more records, each starts and ends with a line of four ASCII SOHs. Within those two lines is an email in RFC 5532 format, i.e. a headers section followed by an

[issue30427] isinstance checks in os.path.normcase redundant with os.fspath

Serhiy Storchaka added the comment: Does calling os.fspath() needed in normcase() at all? Is normcase() even called with arguments which are not just str/bytes? -- nosy: +brett.cannon, serhiy.storchaka stage: -> patch review ___ Python tracker

[issue30385] Segfault on OSX with 3.6.1

Gunnar Aastrand Grimnes added the comment: Adding env no_proxy='*' does indeed fix it! Thanks a lot! I guess it's pretty hard to fix. Or even to detect, so that one could log a warning before dying :( -- ___ Python tracker

[issue29619] st_ino (unsigned long long) is casted to long long in posixmodule.c:_pystat_fromstructstat

Changes by Xavier de Gaye : -- resolution: -> fixed status: open -> closed ___ Python tracker ___

[issue29619] st_ino (unsigned long long) is casted to long long in posixmodule.c:_pystat_fromstructstat

Xavier de Gaye added the comment: New changeset 50e86033de85294d87b7e942701d456342abde8e by xdegaye in branch 'master': bpo-29619: Do not use HAVE_LARGEFILE_SUPPORT for type conversions (GH-1666). https://github.com/python/cpython/commit/50e86033de85294d87b7e942701d456342abde8e --

[issue29828] Allow registering after-fork initializers in multiprocessing

Antoine Pitrou added the comment: > BTW, why can't you use `pthread_atfork` in numpy? I suppose Numpy could use that, but it's much more involved than registering a Python-level callback. Also it would only work because Numpy actually implements its random generator in C. --

[issue30413] Add fnmatch.filterfalse function

Wolfgang Maier added the comment: Yet another thing I just realized (sorry for being so annoying): With os.normcase calling os.fspath in 3.6+ it is not really a NOP anymore even on posix. As a consequence, you can now do some weird things with fnmatch: in all cases, and only in these, where

[issue30413] Add fnmatch.filterfalse function

Wolfgang Maier added the comment: > Good catch! It seems to me that they are redundant. Please open a new issue > for this. done: issue 30427 -- ___ Python tracker

[issue30427] isinstance checks in os.path.normcase redundant with os.fspath

Wolfgang Maier added the comment: Just created a PR for this, which eliminates the redundancy. This also changes the error message (making it less specific), but not the type of a raised exception. If you think that the error message deserves to be preserved that could, of course, be done

[issue30427] isinstance checks in os.path.normcase redundant with os.fspath

Changes by Wolfgang Maier : -- pull_requests: +1803 ___ Python tracker ___

[issue30427] isinstance checks in os.path.normcase redundant with os.fspath

New submission from Wolfgang Maier: os.path.normcase as defined in both posixpath and ntpath is now calling os.fspath on its argument first. With that I think the following isinstance(str, bytes) checks have become redundant since AFAIU os.fspath is guaranteed to return either str or bytes

[issue17942] IDLE Debugger: Improve GUI

Terry J. Reedy added the comment: Mark, Python now uses git and pull requests. Can you, and do you wish to, rebase and convert to a pull request, any of your patches we wish to investigate further, yourself, or should we go ahead and do so? Silence for a week will be taken as the latter.

[issue17942] IDLE Debugger: Improve GUI

Louie Lu added the comment: Rebase markroseman patch to latest version, I own no credit on this patch. Just want to check the effect about the patch. -- Added file: http://bugs.python.org/file46884/0001-WIP.patch ___ Python tracker

[issue30426] why not use the same style func name. eg: int.to_bytes (with underline) and array.tobytes(without underline).

Changes by jf : -- title: why not use the same style func name. eg: int.to_bytes (with underline or not) and array.tobytes(). -> why not use the same style func name. eg: int.to_bytes (with underline) and array.tobytes(without underline).

[issue30426] why not use the same style func name. eg: int.to_bytes (with underline or not) and array.tobytes().

New submission from jf: I note that, some functions have different style names, some have underline, and some not. why do so?? eg: int.to_bytes() and array.tobytes() int.from_byte() and array.frombytes() ZipInfo.from_file() and array.fromfile() ... -- components: Library (Lib)

[issue17942] IDLE Debugger: Improve GUI

Louie Lu added the comment: Mark, do you mind to rebase your patch to the latest version? -- nosy: +louielu ___ Python tracker ___

[issue26949] IDLE restarts when one debugs code raising SystemExit

Louie Lu added the comment: PR 1711 fix KeyboardInterrupt with adding rpc.repsonse_queue.put, but it will not print out the exception traceback. And for SystemExit, wait for discussion result. -- ___ Python tracker

[issue26949] IDLE restarts when one debugs code raising SystemExit

Changes by Louie Lu : -- pull_requests: +1802 ___ Python tracker ___ ___ Python-bugs-list

[issue26949] IDLE restarts when one debugs code raising SystemExit

Louie Lu added the comment: The problem is cause by run.py:main function, when it catch KeyboardInterrupt or SystemExit, it won't put a blank msg back to response_queue, that cause the loop in run.py:main triggering except queue.Empty to continue the loop. So, I think the KeyboardInterrupt

<    1   2