New submission from Thomas Grainger :
when running "python -m ham.py" KeyboardInterrupt should result in -2, but
results in 1
see test case
--
components: Interpreter Core
files: test_exit.py
messages: 375732
nosy: graingert
priority: normal
severity: normal
status:
Thomas Grainger added the comment:
see also https://bugs.python.org/issue1054041
--
___
Python tracker
<https://bugs.python.org/issue41602>
___
___
Python-bug
Change by Thomas Grainger :
--
nosy: +ncoghlan
___
Python tracker
<https://bugs.python.org/issue41602>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Thomas Grainger :
--
nosy: +gregory.p.smith
___
Python tracker
<https://bugs.python.org/issue41602>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Thomas Grainger :
Added file: https://bugs.python.org/file49415/test_exit.txt
___
Python tracker
<https://bugs.python.org/issue41602>
___
___
Python-bugs-list m
Thomas Grainger added the comment:
I think I've eliminated runpy.py, as I still get a `-2` when using:
import runpy
runpy.run_module("ham")
or
runpy._run_module_as_main("ham")
see attached test_exit_runpy.py
It seems the only difference is if pymain_run_file or
Change by Thomas Grainger :
--
title: Python doesn't exit with proper resultcode on SIGINT in runpy -> Python
doesn't exit with proper resultcode on SIGINT in runpy (pymain_run_module)
___
Python tracker
<https://bugs.pytho
Thomas Grainger added the comment:
I've now eliminated pymain_run_stdin and pymain_run_command, both process a
KeyboardInterrupt as -2
see attached test_exit_command_stdin.py
--
Added file: https://bugs.python.org/file49417/test_exit_command_std
Thomas Grainger added the comment:
seems like a dupe? https://bugs.python.org/issue32308
--
keywords: +patch
message_count: 3.0 -> 4.0
nosy: +graingert
nosy_count: 5.0 -> 6.0
pull_requests: +21050
stage: -> patch review
pull_request: https://github.com/python/cpython/
Thomas Grainger added the comment:
adding vstinner, as this seems related to pymain_run_module rather than runpy
--
nosy: +vstinner
___
Python tracker
<https://bugs.python.org/issue41
Thomas Grainger added the comment:
The purpose of this tutorial section is to document how to catch all types of
exceptions and extract the type and value. When this is required,
`BaseException as err:` is the preferred approach.
This document still mentions the alternative approach so that
Change by Thomas Grainger :
--
type: -> behavior
___
Python tracker
<https://bugs.python.org/issue41602>
___
___
Python-bugs-list mailing list
Unsubscrib
Change by Thomas Grainger :
--
keywords: +patch
pull_requests: +21065
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/21956
___
Python tracker
<https://bugs.python.org/issu
Thomas Grainger added the comment:
I've confirmed that the pymain_run_module fails on master in the same way with
Mac, Windows and Ubuntu
--
___
Python tracker
<https://bugs.python.org/is
New submission from Thomas Grainger :
==
FAIL: test_call_later (test.test_asyncio.test_events.ProactorEventLoopTests)
--
Traceback (most recent call last
Change by Thomas Grainger :
--
title: make shutil.make_archive always accepts pathlib objects -> make
shutil.make_archive always accept pathlib objects
___
Python tracker
<https://bugs.python.org/issu
New submission from Thomas Grainger :
>>> shutil.make_archive(pathlib.Path("./foo"), root_dir=pathlib.Path("./foo"),
>>> format="zip")
'/home/graingert/projects/ham/foo.zip'
>>> shutil.make_archive(pathlib.Path("./foo&q
Change by Thomas Grainger :
--
keywords: +patch
pull_requests: +21072
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/21962
___
Python tracker
<https://bugs.python.org/issu
New submission from Thomas Grainger :
https://docs.python.org/dev/library/asyncio-sync.html#asyncio.Event links to
https://docs.python.org/dev/library/asyncio-task.html#asyncio.wait instead of
https://docs.python.org/dev/library/asyncio-sync.html#asyncio.Event.wait
--
assignee: docs
Change by Thomas Grainger :
--
keywords: +patch
pull_requests: +21129
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/22029
___
Python tracker
<https://bugs.python.org/issu
Thomas Grainger added the comment:
adding `__main__` owners to nosy
--
nosy: +gvanrossum
___
Python tracker
<https://bugs.python.org/issue41602>
___
___
Pytho
Thomas Grainger added the comment:
The return code of python on linux when the program is ended with a
KeyboardInterrupt should be -2, this works in most cases - except when called
via "python -m"
Does this repl help?
Python 3.8.2 (default, Jul 16 2020, 14:00:26)
[GCC 9.3.0
Thomas Grainger added the comment:
> Okay, I got it. Now my next question. What do you mean by "I've eliminated
> runpy" and various other remarks along those lines?
I can use `runpy._run_module_as_main` from another Python entry, eg -c and get
the correct `-2`
>>
Thomas Grainger added the comment:
I'm assuming _Py_UnhandledKeyboardInterrupt is getting incorrectly cleared
somewhere in here
https://github.com/python/cpython/blob/fc23a9483ef0d7c98bea9f82392377d0b6ef7b18/Modules/main.c#L291-L300
Py_DECREF(runpy);
Py_DECREF(runm
Thomas Grainger added the comment:
I pushed that patch
--
versions: -Python 3.10
___
Python tracker
<https://bugs.python.org/issue41602>
___
___
Python-bug
Thomas Grainger added the comment:
nice the tests pass with that fix
--
___
Python tracker
<https://bugs.python.org/issue41602>
___
___
Python-bugs-list mailin
Change by Thomas Grainger :
--
pull_requests: +21438
pull_request: https://github.com/python/cpython/pull/22398
___
Python tracker
<https://bugs.python.org/issue41
New submission from Thomas Grainger :
Current behaviour
$ cat foo.py
def foo():
open('foo', 'wb')
foo()
$ python3.8 -W all::ResourceWarning -X tracemalloc=5 foo.py
foo.py:2: ResourceWarning: unclosed file <_io.BufferedWriter name='foo'>
open(&#
Change by Thomas Grainger :
--
title: print ResourceWarning object traceback when raise as error with -W error
-> print ResourceWarning object traceback when raised as error with -W error
and -X tracemalloc
___
Python tracker
<
Thomas Grainger added the comment:
How about assertIsPermutation?
https://www.fluentcpp.com/2019/06/25/understanding-the-implementation-of-stdis_permutation/
--
nosy: +graingert
___
Python tracker
<https://bugs.python.org/issue27
New submission from Thomas Grainger :
this would allow ``warnings.catch_warnings`` to be threadsafe
--
messages: 348015
nosy: graingert
priority: normal
severity: normal
status: open
title: warnings should use a ContextVar to manage filters/registry
Thomas Grainger added the comment:
note that PEP 550 previously mentions catch_warnings as something that would
benefit from some sort of Execution Context management
> Context managers like decimal contexts, numpy.errstate, and
> warnings.catch_wa
Thomas Grainger added the comment:
It seems that 'viewkeys', 'viewvalues' and 'viewitems' methods were not added
to types.DictProxyType, was that intentional?
--
nosy: +graingert
___
Python tracker
<
New submission from Thomas Grainger :
The docs for
https://docs.python.org/3/library/multiprocessing.html#multiprocessing.Queue.close
read:
> Indicate that no more data will be put on this queue by the current process.
> The background thread will quit once it has flushed all buffere
Thomas Grainger added the comment:
Should the docs be:
> Indicate that no more data will be put on or got from this queue by the
> current process. The background thread will quit once it has flushed all
> buffered data to the pipe. This is called automatically when the queue is
New submission from Thomas Grainger :
Currently it's quite easy for these errors to go unnoticed.
I'd like a way to easily detect these in CI.
nedbat suggested piping the process output to another tool, and looking for
'Exception ignored in:' but this
Thomas Grainger added the comment:
> this option should be used exclusively for debugging user extension modules.
I have a very large codebase that fires the odd ResourceWarning, and after
fixing them all I'd like to ensure that they do not reoccur. When using `-W
error` it still wo
Thomas Grainger added the comment:
The point for me is that CI will fail if it happens, then I can use gdb to
find out the cause
On Thu, 9 May 2019, 23:17 STINNER Victor, wrote:
>
> STINNER Victor added the comment:
>
> Ok, let me come back to the initial issue:
>
&g
Thomas Grainger added the comment:
> I'm not comfortable with forcing users to use a low-level debugger to
debug "unraisable exceptions".
Defaulting to noop when the hook fails means I'll never notice the failure
to be able to debug it
On Fri, 10 May 2019, 00:42
New submission from Thomas Grainger:
Having the password stored in a plain-text configuration file is not great
security.
A better choice would be to try to use the OS keyring and then fall back to a
plaintext file
An example implementation of a generic keyring python interface is available
Thomas Grainger added the comment:
But distutils is a core Python module...
On 9 Sep 2016 00:43, "Christian Heimes" wrote:
>
> Christian Heimes added the comment:
>
> Please take this idea to https://www.pypa.io/
>
> --
> nosy: +christian.heimes
> re
101 - 141 of 141 matches
Mail list logo
