Issue 16785: Document the fact that constructing OSError with erron returns subclass if possible (original) (raw)

Issue16785

Created on 2012-12-26 11:35 by asvetlov, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (4)
msg178204 - (view)	Author: Andrew Svetlov (asvetlov) *	Date: 2012-12-26 11:35
I mean adding examples for constructions like this: >>> OSError(errno.ENOENT, 'error msg') FileNotFoundError(2, 'error msg')
msg178205 - (view)	Author: Serhiy Storchaka (serhiy.storchaka) *	Date: 2012-12-26 11:44
However >>> OSError(errno.ENOENT) OSError(2,) >>> OSError(errno.ENOENT, 'error msg', 'filename', 'spam') OSError(2, 'error msg', 'filename', 'spam')
msg253169 - (view)	Author: Martin Panter (martin.panter) *	Date: 2015-10-19 04:09
My proposed patch at Issue 23391 addresses this
msg253513 - (view)	Author: Martin Panter (martin.panter) *	Date: 2015-10-27 03:56
Hopefully revision cb554248ce54 is good enough to close this. The documentation now says ''' The constructor often actually returns a subclass of OSError, as described in “OS exceptions” below. The particular subclass depends on the final “errno” value. This behaviour only occurs when constructing OSError directly or via an alias, and is not inherited when subclassing. ''' Serhiy’s first case does not set the “errno” attribute (by design I assume). In the second case, I suspect the behaviour has changed since 2012, or it depends on the platform. On Windows, the 'spam' argument is meant to become “winerror”, which can override “errno” if it is an integer. 3.6 on Linux: >>> OSError(errno.ENOENT, 'error msg', 'filename', 'spam') FileNotFoundError(2, 'error msg')