lowercase exception names trip-up .
I've been tripped up a couple of time by a few Exception names being lower case both in code and tracebacks. In particular `error` (all lower case) I tend to read `error` as a function instead of a class.
According to my non-scientific grep-foo, I find that ~ 300 descendant from Exceptions start with an upper case:
~/dev/cpython[master ✗] $ rg '^[ ]*class [A-Z][a-zA-Z]+(' | grep Excep | wc -l 333 18 of those are `Error` uppercase: ~/dev/cpython[master ✗] $ rg '^[ ]*class Error(' | wc -l 18 but 4 are lower case:
~/dev/cpython[master ✗] $ rg '^[ ]*class [a-z][a-zA-Z]+(' | grep Exception Lib/sre_constants.py:class error(Exception): Lib/imaplib.py: class error(Exception): pass # Logical errors - debug required Doc/faq/design.rst: class label(Exception): pass # declare a label Lib/dbm/__init__.py:class error(Exception):
... there are probably others if they don't directly inherit from Exception of course.
My question is in two part:
1) For consistency would it make sens to try to capitalize – where possible – Exceptions names ? For example `error` to `Error` (keeping error as an alias for backward compatibility for now). 2) If (1), would it be ok to actually give a better name to some of those exceptions ? e.g: Lib/sre_constants.py:class error to CompileError for example.
Thanks.
05.12.19 21:25, Matthias Bussonnier пише:
I've been tripped up a couple of time by a few Exception names being lower case both in code and tracebacks. In particular `error` (all lower case) I tend to read `error` as a function instead of a class.
According to my non-scientific grep-foo, I find that ~ 300 descendant from Exceptions start with an upper case:
~/dev/cpython[master ✗] $ rg '^[ ]*class [A-Z][a-zA-Z]+(' | grep Excep | wc -l 333 18 of those are `Error` uppercase: ~/dev/cpython[master ✗] $ rg '^[ ]*class Error(' | wc -l 18 but 4 are lower case:
~/dev/cpython[master ✗] $ rg '^[ ]*class [a-z][a-zA-Z]+(' | grep Exception Lib/sre_constants.py:class error(Exception): Lib/imaplib.py: class error(Exception): pass # Logical errors - debug required Doc/faq/design.rst: class label(Exception): pass # declare a label Lib/dbm/__init__.py:class error(Exception):
... there are probably others if they don't directly inherit from Exception of course.
There are few more lowercase exception names (all of them start with "error"):
dbm/__init__.py:38:class error(Exception): ftplib.py:58:class error_reply(Error): pass # unexpected [123]xx reply ftplib.py:59:class error_temp(Error): pass # 4xx errors ftplib.py:60:class error_perm(Error): pass # 5xx errors ftplib.py:61:class error_proto(Error): pass # response does not begin with [1-5] imaplib.py:180: class error(Exception): pass # Logical errors - debug required poplib.py:31:class error_proto(Exception): pass sre_constants.py:23:class error(Exception):
There are also several aliases:
calendar.py:21:error = ValueError copy.py:57:error = Error # backward compatibility dbm/__init__.py:45:error = (error, OSError) dbm/dumb.py:33:error = OSError distutils/log.py:62:error = _global_log.error getopt.py:54:error = GetoptError # backward compatibility http/client.py:1470:error = HTTPException re.py:181:error = sre_compile.error test/mock_socket.py:151:error = socket_module.error zipfile.py:51:error = BadZipfile = BadZipFile # Pre-3.2 compatibility names
Thanks for pointing those out.
At least when the alias is `error = OtherName` the text is the stack trace are informative.
I notice that most(all?) of those are from pretty old modules, which explains the "old", pre PEP-8 names.
I think it would be good to clean this up with a set of aliases -- but it is a fair bit of code-churn for not much real gain. I guess it comes down to:
- How much maintenance do those modules see anyway? Are they changing much, if at all between recent versions?
- How often to "end users" use them -- as opposed to using high level packages on top of them? What I'm getting at here is that it's a lot more important that a newbie or casual scripter gets consistent names than for package maintainers.
-CHB
On Thu, Dec 5, 2019 at 1:32 PM Matthias Bussonnier < bussonniermatthias@gmail.com> wrote:
Thanks for pointing those out.
At least when the alias is `error = OtherName` the text is the stack trace are informative. -- M _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/JSHM7F... Code of Conduct: http://python.org/psf/codeofconduct/
On 2019-12-06 3:58 p.m., Christopher Barker wrote:
I notice that most(all?) of those are from pretty old modules, which explains the "old", pre PEP-8 names.
I think it would be good to clean this up with a set of aliases -- but it is a fair bit of code-churn for not much real gain. I guess it comes down to:
- How much maintenance do those modules see anyway? Are they changing
much, if at all between recent versions?
- How often to "end users" use them -- as opposed to using high level
packages on top of them? What I'm getting at here is that it's a lot more important that a newbie or casual scripter gets consistent names than for package maintainers.
I almost had my latest lib use lowercase "error" because I was basing it off of re module public API.
-CHB
On Thu, Dec 5, 2019 at 1:32 PM Matthias Bussonnier <bussonniermatthias@gmail.com mailto:bussonniermatthias@gmail.com> wrote:
Thanks for pointing those out. At least when the alias is `error = OtherName` the text is the stack trace are informative. -- M _______________________________________________ Python-ideas mailing list -- python-ideas@python.org <mailto:python-ideas@python.org> To unsubscribe send an email to python-ideas-leave@python.org <mailto:python-ideas-leave@python.org> https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/JSHM7FGTJA7CSCUVZFLKYYFMS3DU7NKB/ Code of Conduct: http://python.org/psf/codeofconduct/-- Christopher Barker, PhD
Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/USDR4A... Code of Conduct: http://python.org/psf/codeofconduct/
I'm torn -- on the one hand, these very old modules may as well stay frozen in time (please double check that they aren't listed in PEP 594). On the other hand, for modules that are still actively maintained, the exception may as well be named Error instead of error, and a rename of error -> Error plus a new alias error = Error should take care of those. I don't recommend a deprecation of the old names though -- this feels like a really minimal maintenance burden for core devs, and potentially a big one for people using the old names.
Some more tips: please use a separate PR per module; please update all docs (both mentions of the exception in the module's comments and docstrings, and the library docs); check that there are no *other* classes in a module that also use a lowercase naming convention (if there are, that module needs more thought before we change just the exception name).
It may also be a good idea to create bugs for each module with a brief description and tagging it as "Easy" or "Easy (C)" (if there's C code involved).
On Fri, Dec 6, 2019 at 11:02 AM Christopher Barker pythonchb@gmail.com wrote:
I notice that most(all?) of those are from pretty old modules, which explains the "old", pre PEP-8 names.
I think it would be good to clean this up with a set of aliases -- but it is a fair bit of code-churn for not much real gain. I guess it comes down to:
- How much maintenance do those modules see anyway? Are they changing
much, if at all between recent versions?
- How often to "end users" use them -- as opposed to using high level
packages on top of them? What I'm getting at here is that it's a lot more important that a newbie or casual scripter gets consistent names than for package maintainers.
-CHB
On Thu, Dec 5, 2019 at 1:32 PM Matthias Bussonnier < bussonniermatthias@gmail.com> wrote:
Thanks for pointing those out.
At least when the alias is `error = OtherName` the text is the stack trace are informative. -- M _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/JSHM7F... Code of Conduct: http://python.org/psf/codeofconduct/
-- Christopher Barker, PhD
Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython
Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/USDR4A... Code of Conduct: http://python.org/psf/codeofconduct/
On Fri, Dec 6, 2019 at 1:02 PM Guido van Rossum guido@python.org wrote <snip>
check that there are no *other* classes in a module that also use a lowercase naming convention (if there are, that module needs more thought before we change just the exception name).
I expect that will be quite common — older code commonly uses lower case class names — including core built is, of course. We’ve gotten used to that, so I’m not sure it’s worth worrying about. It would still be helpful to clean up the exception names. And changing core class names is a lot more churn. Not that there’s anything wrong with more thought.
-CHB
It may also be a good idea to create bugs for each module with a brief description and tagging it as "Easy" or "Easy (C)" (if there's C code involved).
On Fri, Dec 6, 2019 at 11:02 AM Christopher Barker pythonchb@gmail.com wrote:
I notice that most(all?) of those are from pretty old modules, which explains the "old", pre PEP-8 names.
I think it would be good to clean this up with a set of aliases -- but it is a fair bit of code-churn for not much real gain. I guess it comes down to:
- How much maintenance do those modules see anyway? Are they changing
much, if at all between recent versions?
- How often to "end users" use them -- as opposed to using high level
packages on top of them? What I'm getting at here is that it's a lot more important that a newbie or casual scripter gets consistent names than for package maintainers.
-CHB
On Thu, Dec 5, 2019 at 1:32 PM Matthias Bussonnier < bussonniermatthias@gmail.com> wrote:
Thanks for pointing those out.
At least when the alias is `error = OtherName` the text is the stack trace are informative. -- M _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/JSHM7F... Code of Conduct: http://python.org/psf/codeofconduct/
-- Christopher Barker, PhD
Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython
Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/USDR4A...
Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/
I'm torn -- on the one hand, these very old modules may as well stay frozen
in time (please double check that they aren't listed in PEP 594)
And
I expect that will be quite common — older code commonly uses lower case
class names
Thank, checking 594 is a good idea; I understand why you are thorn, and I can see how such a change can be seen as noise. But I believe that consistency will be a win in the long run.
It make complete sens to decide whether and how to rename on a per-module basis. But for each module the discussion should likely be on b.p.o.
My original request on bpo[1] was for `re` which is actively maintained, but I was advised to ask for a more general policy and thoughts here as whether renaming of a an exception was acceptable.
On Fri, Dec 6, 2019 at 5:42 PM Matthias Bussonnier < bussonniermatthias@gmail.com> wrote:
[...] My original request on bpo[1] was for `re` which is actively maintained, but I was advised to ask for a more general policy and thoughts here as whether renaming of a an exception was acceptable.
-- Matthias 1: https://bugs.python.org/issue38981
I wish you had linked to that issue in your original post. It's much easier to discuss a general policy with a concrete example in hand than from an abstract description of the problem. (At least, it is for me. And e.g. the US Supreme Court agrees.)
participants (5)
-
Christopher Barker -
Guido van Rossum -
Matthias Bussonnier -
Serhiy Storchaka -
Soni L.