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?