[Python-Dev] Idle, site.py, and the release candidates
Terry Reedy
tjreedy at udel.edu
Sun Mar 31 09:52:26 CEST 2013
On 3/31/2013 2:39 AM, Nick Coghlan wrote:
> On Sun, Mar 31, 2013 at 12:34 PM, Terry Jan Reedy <tjreedy at udel.edu
> <mailto:tjreedy at udel.edu>>
>
> I do not know enough about other circumstances in which
> stdin.fileno would do something other than return 0 to be sure of
> what the proper fix would be. (I increasingly dislike bare
> excepts as they hide the thinking and knowledge of the original
> programmer. What exception was expected that should be passed away?)
>
>
> The other problem is that making *two* function calls inside a broad
> try/except is almost always a terrible idea.
That too. I could not decide which function an exception was expected from.
> It seems to me that the intended logic is more like this:
>
> try:
> # Close stdin if it wraps any fd other than 0
> close_stdin = (sys.stdin.fileno() != 0)
> except (AttributeError, OSError, io.UnsupportedOperation):
> # Also close stdin if it doesn't expose a file descriptor
> close_stdin = True
> if close_stdin:
> try:
> sys.stdin.close()
> except Exception:
> pass
> raise SystemExit(code)
>
There are 4 possible situations for sys.stdin:
1. No .fileno
2. .fileno raises
3. .fileno() != 0
4. lfileno() == 0
I believe the current code calls .close for 1 and raises SystemExit for
2-4. Your code calls for 1-3 and raises for 4. I suspect that is
correct. For an rc patch, the safest temporary patch would be to start
.__call__ with
if sys.stdin.__name__ == 'PseudoInputFile': sys.stdin.close()
I would have to check that the name is correct as seen in the user
process (cannot at moment).
The deeper problem, I think, is that none of sys.version,
sys.hexversion, sys._version, sys.platform tell a program that it is
running under Idle. It usually does not matter but there are a few
situations in which it does.
--
Terry Jan Reedy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130331/51de28dd/attachment.html>
More information about the Python-Dev
mailing list