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.

classification
Title: There is no exception correspond to errno EROFS
Type: enhancement Stage:
Components: Library (Lib) Versions: Python 3.4
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: asvetlov, atykhonov, georg.brandl, pitrou
Priority: normal Keywords:

Created on 2013-04-07 10:08 by atykhonov, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (7)
msg186185 - (view) Author: Andrey Tykhonov (atykhonov) * Date: 2013-04-07 10:08
I found errno.EROFS in Lib/mailbox.py but didn't find exception  correspond to this errno. Is it need to be created?
msg186206 - (view) Author: Andrey Tykhonov (atykhonov) * Date: 2013-04-07 13:33
Also:
errno.EXDEV in Lib/distutils/file_util.py
errno.ENOTCONN in Lib/poplib.py
errno.EINVAL in Lib/subprocess.py
errno.ENOTCONN in Lib/smtpd.py, Lib/ssl.py, Lib/imaplib.py
errno.EOPNOTSUPP, errno.ENOTSUP, errno.ENOTSUP, errno.ENODATA in Lib/shutil.py
msg186208 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2013-04-07 13:44
The rationale for not creating dedicated exception classes is that those errors are not common enough. Since the range of possible errno values is basically unbounded (each system can create their own system-specific errors), trying to cover them all is a losing battle.
msg186308 - (view) Author: Andrew Svetlov (asvetlov) * (Python committer) Date: 2013-04-08 15:27
Sorry for reopening.

Do you really sure that ENOTCONN and EINVAL doesn't worth to have separate sublasses?

The same question about Not Supported family.

I don't force to make new exception classes, just like to figure out the status quo.

If we decide to keep in stone our exceptions hierarchy for OSError's — that's ok.
If list is open — let's discuss
msg186344 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2013-04-08 20:29
Antoine will have to decide on this, but IMO now that we released the PEP 3151 set in Python 3.3, we should not continue adding new builtin exceptions in every release.
msg186346 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2013-04-08 20:42
A bit in detail:
- ENOTCONN is a programming error, so there's no use actually catching it (you should fix the bug instead when you encounter it)
- EINVAL could be a candidate, but unfortunately it would clash quite nastily with ValueError and lead to confusion; therefore I think it's better not wrapping it
msg186445 - (view) Author: Andrew Svetlov (asvetlov) * (Python committer) Date: 2013-04-09 19:36
Ok. Antoine's comment is clean.
Let's close the issue.
History
Date User Action Args
2022-04-11 14:57:43adminsetgithub: 61850
2013-04-09 19:36:41asvetlovsetstatus: pending -> closed

messages: + msg186445
2013-04-08 20:42:11pitrousetstatus: open -> pending

messages: + msg186346
2013-04-08 20:29:19georg.brandlsetmessages: + msg186344
2013-04-08 15:27:38asvetlovsetstatus: closed -> open
nosy: + georg.brandl
messages: + msg186308

2013-04-07 17:11:29georg.brandlsetstatus: open -> closed
resolution: wont fix
2013-04-07 13:53:14asvetlovlinkissue16705 dependencies
2013-04-07 13:47:19asvetlovsetnosy: + asvetlov
2013-04-07 13:44:49pitrousetmessages: + msg186208
2013-04-07 13:43:50atykhonovsettype: enhancement
components: + Library (Lib)
versions: + Python 3.4
2013-04-07 13:33:38atykhonovsetmessages: + msg186206
2013-04-07 10:08:13atykhonovcreate