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 <python...@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 < > bussonniermatth...@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-le...@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-le...@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/USDR4AFSJYDPE4GK5MUZQ6JBJ3U2X3KA/ > 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/>
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/246EY7CPTNTLM3FWLZ4R3CKURBT2ZJR4/ Code of Conduct: http://python.org/psf/codeofconduct/
