This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author hynek
Recipients alex, hynek, pitrou
Date 2012-01-24.12:55:30
SpamBayes Score 3.271864e-10
Marked as misclassified No
Message-id <>
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 convert the file name using "et" in PyArg_ParseTuple[AndKeywords].

OTOH, open() and 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?
Date User Action Args
2012-01-24 12:55:32hyneksetrecipients: + hynek, pitrou, alex
2012-01-24 12:55:32hyneksetmessageid: <>
2012-01-24 12:55:31hyneklinkissue13848 messages
2012-01-24 12:55:30hynekcreate