[issue20517] Support errors with two filenames for errno exceptions

[STINNER Victor]

STINNER Victor added the comment:

Why did you add so many versions of the same functions? Only PyErr_SetExcFromWindowsErrWithFilenameObjects() and PyErr_SetFromErrnoWithFilenameObjects() are used.

The Py_UNICODE type is deprecated, you should not add new functions using it in Python 3.4.

+PyObject *PyErr_SetFromWindowsErrWithUnicodeFilenames(
+    int ierr,
+    const Py_UNICODE *filename,
+    const Py_UNICODE *filename2)

And you should avoid passing raw bytes string to build an error message, you probably has the Python object version of the filename somewhere in your code.

+PyAPI_FUNC(PyObject *) PyErr_SetFromErrnoWithFilenames(
+    PyObject *exc,
+    /* decoded from the filesystem encoding */
+    const char *filename,
+    const char *filename2
+    );

+PyObject *PyErr_SetExcFromWindowsErrWithFilenames(
+    PyObject *exc,
+    int ierr,
+    const char *filename,
+    const char *filename2)

In Python 3.3, there are also too many functions to raise an OSError, I don't that you should so many new functions. Please remove:

- PyErr_SetFromWindowsErrWithUnicodeFilenames
- PyErr_SetFromErrnoWithFilenames
- PyErr_SetExcFromWindowsErrWithFilenames

Having two filenames in OSError is the best fix for functions like os.rename when we don't know which path raised the error. I remember that it was hard to guess if the source or the destination was the problem, so thanks for working on this.

Note: When I wrote "Unicode is really the native type", I mean a PyObject* object which is a str, not Py_UNICODE* which is deprecated.

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20517>
_______________________________________