[issue22577] local variable changes lost after pdb jump command

Henry Chen added the comment: PEP 558 will fix this issue, which I've verified with the proposed implementation (https://github.com/python/cpython/pull/3640/files). Perhaps this issue can be closed? -- ___ Python tracker <https://bugs.py

[issue22577] local variable changes lost after pdb jump command

Change by Henry Chen : -- nosy: +henry ___ Python tracker <https://bugs.python.org/issue22577> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue9633] pdb go stack up/down

Change by Henry Chen : -- pull_requests: +10309 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue9633> ___ ___ Python-bugs-list mai

[issue35738] Update timeit documentation to reflect default repeat of three

Change by Henry Chen : -- keywords: +patch pull_requests: +11196 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue35738> ___ ___ Py

[issue35738] Update timeit documentation to reflect default repeat of three

Change by Henry Chen : -- keywords: +patch, patch pull_requests: +11196, 11197 stage: -> patch review ___ Python tracker <https://bugs.python.org/issu

[issue35738] Update timeit documentation to reflect default repeat of three

Change by Henry Chen : -- keywords: +patch, patch, patch pull_requests: +11196, 11197, 11198 stage: -> patch review ___ Python tracker <https://bugs.python.org/issu

[issue35738] Update timeit documentation to reflect default repeat of five

Change by Henry Chen : -- title: Update timeit documentation to reflect default repeat of three -> Update timeit documentation to reflect default repeat of five ___ Python tracker <https://bugs.python.org/issu

[issue34782] Pdb crashes when code is executed in a mapping that does not define `__contains__`

Change by Henry Chen : -- nosy: +scotchka ___ Python tracker <https://bugs.python.org/issue34782> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34782] Pdb crashes when code is executed in a mapping that does not define `__contains__`

Henry Chen added the comment: I agree that this behavior is normal, unless there is a use case for passing a partially implemented mapping object to pdb.run. However I cannot think of such a use case. -- ___ Python tracker <ht

[issue34782] Pdb crashes when code is executed in a mapping that does not define `__contains__`

Henry Chen added the comment: Hmm, the example works for me (Python 3.6.5): >>> import pdb >>> class FakeContainer: ... def __getitem__(self, key): ... raise KeyError(key) ... >>> pdb.run("eval('1+1',{},FakeContainer())") >

[issue34782] Pdb crashes when code is executed in a mapping that does not define `__contains__`

Henry Chen added the comment: An attempt to clarify the issue in my own mind: def foo(): # import pdb; pdb.set_trace() exec('pass', {}, FakeContainer()) This function runs successfully. But if you uncomment the pdb line and then step thru in the pdb console, there is an

[issue35812] Don't log an exception from the main coroutine in asyncio.run()

Henry Chen added the comment: I'm having trouble reproducing this issue. The main_coro seems to disappear when an exception is raised in it, so that it does not show up in the set of tasks to cancel. I'm probably misunderstanding something basic here. Is it possible to provide

[issue36091] clean up async generator from types module

New submission from Henry Chen : the following script: ``` import sys, types def tr(frame, event, arg): print(frame, event, arg) return tr sys.settrace(tr) ``` gives the output: ``` call None exception (, GeneratorExit(), ) return None ``` This is due to Lib/types.py creating an

[issue36091] clean up async generator from types module

Change by Henry Chen : -- keywords: +patch pull_requests: +12021 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue36091> ___ ___ Py

[issue36091] clean up async generator from types module

Henry Chen added the comment: As it happens @cheryl.sabella has created a very useful data set of which files are impacted by open PRs: https://github.com/csabella/pulls and as of 2019-02-18, the only open PR that relates to Lib/types.py is https://github.com/python/cpython/pull/5068 on an

[issue36114] test_multiprocessing_spawn changes the execution environment

Henry Chen added the comment: Another example of this, same bot: https://buildbot.python.org/all/#/builders/168/builds/669 -- nosy: +scotchka ___ Python tracker <https://bugs.python.org/issue36

[issue36091] clean up async generator from types module

Change by Henry Chen : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue28956] return list of modes for a multimodal distribution instead of raising a StatisticsError

Henry Chen added the comment: The problem remains that the function can return a number or a list for input that is a list of numbers. This means the user will need to handle both possibilities every time, which is a heavy burden for such a simple function. SciPy's mode function does r

[issue28956] return list of modes for a multimodal distribution instead of raising a StatisticsError

Henry Chen added the comment: Yes, the mode function could ALWAYS return a list, but that breaks backward compatibility, as does the currently proposed change. -- ___ Python tracker <https://bugs.python.org/issue28

[issue35892] Fix awkwardness of statistics.mode() for multimodal datasets

Change by Henry Chen : -- nosy: +scotchka ___ Python tracker <https://bugs.python.org/issue35892> ___ ___ Python-bugs-list mailing list Unsubscribe: