[issue20517] Support errors with two filenames for errno exceptions
STINNER Victor
report at bugs.python.org
Mon Feb 10 10:59:15 CET 2014
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>
_______________________________________
More information about the Python-bugs-list
mailing list