Hynek Schlawack <h...@ox.cx> added the comment: I took a deep dive into parts of CPython that were unknown to me :) and dug up the following:
Methods like os.stat or even os.open convert the file name using "et" in PyArg_ParseTuple[AndKeywords]. OTOH, open() and io.open() just hand through the object as "O" to the respective low-level io module. The result in 2.7 is that file() tries to convert it for it's own usage eventually – which fails as seen. While a more explicit error message wouldn't hurt, this seems safe to me insofar. In 3.3, file() aka Modules/_io/fileio.c , io_open does no such thing because it seems to handle fds as "nameobj" as well and does a wide range of checks on the argument. After io_open is certain that nameobj is a file name, it uses PyObject_AsCharBuffer()on bytes and PyUnicode_FromObject() + encoding magic on unicode to get an encoded string as a file name. Neither does a check for NUL bytes so the (w)open(er) that follows reacts as demonstrated by Antoine. I presume fixing/breaking PyObject_AsCharBuffer()/PyUnicode_FromObject() is out of question so the most obvious part to fix would be the conversion block inside io_open. Should I have a stab at it or do you disagree with my approach? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue13848> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
