homepage

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

AltStyle によって変換されたページ (->オリジナル) /