New submission from Barry A. Warsaw:
Let's say you use a custom opener, and that opener happens to return exactly
-1. You end up with a SystemError because NULL got returned without an
exception being set:
def negative(fname, flags):
return -1
with open('/tmp/foo.txt', 'w', encoding='utf-8', opener=negative) as fp:
print('oops', file=fp)
% python3 /tmp/foo.py
Traceback (most recent call last):
File "/tmp/foo.py", line 5, in <module>
with open('/tmp/foo.txt', 'w', encoding='utf-8', opener=negative) as fp:
SystemError: <class '_io.FileIO'> returned NULL without setting an error
Anything else and you get a relatively decent exception. E.g. return -2 and
you get an OSError. Raise an exception and you get that exception.
The problem is pretty clear to see; when an opener is set, after coercing the
fd to an integer, the check is made for that integer being -1, and then it
jumps right to the exit.
Let's say you return some non-integer, like 'foo'. Then the _PyLong_AsInt()
will fail and a proper exception will be set. So I think the "if (self->fd ==
-1)" clause just needs to check for an exception set first and set one if there
isn't one before it does the "goto error". I guess you'd want to see the same
exception as if it returned say, -2:
Traceback (most recent call last):
File "/tmp/foo.py", line 5, in <module>
with open('/tmp/foo.txt', 'w', encoding='utf-8', opener=negative) as fp:
OSError: [Errno 0] Error: '/tmp/foo.txt'
----------
components: IO
messages: 265901
nosy: barry
priority: normal
severity: normal
stage: needs patch
status: open
title: SystemError if custom opener returns -1
type: crash
versions: Python 3.5, Python 3.6
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue27066>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
