In article CAMpsgwabYhXB0OG3UhdX=FUCYOnAJGzpwd-g8sTdauKjzpJAMQ@mail.gmail.com, Victor Stinner victor.stinner@gmail.com wrote:
2014-09-02 23:03 GMT+02:00 Matthew Woodcraft matthew@woodcraft.me.uk:
In any case I think PEP 475 should be explaining what is going to happen to signal.siginterrupt(). Will setting flag=True be supported?
I first proposed to deprecate the function, but Charles-François thinks that it's unrelated to the PEP (it can be addressed later).
The function will still be available and work.
If so, will doing so change the behaviour of those parts of the stdlib which have already been modified to retry after EINTR?
I think that the stdlib should not handle InterruptedError exception anymore in the Python code, to simplify the code.
That seems good to me. I think it's worth writing in the PEP.
But if Python is going to provide its own higher-level model of signal handling, then I think signal.siginterrupt() will need to be documented in terms of that model; it should be saying something along the lines of "if a signal arrives while Python is blocking in a system call then InterruptedError will be raised", and I suppose it will need to say what happens if the signal handler also raised an exception.
(I think it would be helpful if we could tell people "if you want the old EINTR behaviour, just do this simple thing". And I suppose siginterrupt flag=True is a candidate for that.)
Why do you want the old behaviour?
Purely to avoid breaking existing programs, particularly in ways which will require effort to fix.
I think Python's backward-compatibility rules are basically "the behavior of an API must not change without going through the deprecation process".
If we're going to be making an exception to that here, then it would be much better to say "here's a simple change to make to keep your old program working", rather than "please rewrite your fiddly signal-handling code to use more modern techniques", however much nicer those modern techniques are.
Or perhaps it would be better to not make an exception at all, and instead add an 'interrupt_syscalls' boolean keyword argument to signal.signal(), while strongly recommending that people set it False.
-M-