Raymond Hettinger added the comment:
> The message, imo, is confusing
Sorry, I think this is an invented issue and not a actual problem. ElementTree
has been in the wild for a very long time. AFAICT, no user has ever had an
actual issue with this error message. I've taught ElementTree (specifically
including this method) at least one per month over six years and have never
seen the slightest issue with these error messages (in PyPy, the actual
ElementTree.py is used).
It would just be code clutter to wrap this and all the other accessors in:
try:
self._children.remove(subelement)
except ValueError:
raise ValueError('Element.remove(x): x not in Element')
I would like the standard library to *not* be filled with this sort of thing.
The norm in pure Python code is to let the error checking occur at the lowest
level and propagate its way up with its original error message. Usually, the
only time we rewrap the exception is if the message would be far off from the
actual cause.
I'm concerned at the recent rise of "invented issues" where newcomers posit
that long deployed, stable code, written by very smart people must be changed
even though no actual user has ever been encountered.
Invented issues waste developer time and distract from the numerous real issues
we have to deal with. It also seems to be encouraging a mentality of roaming
through the codebase with a desire to make numerous trivial changes and while
second-guessing all the design decisions made a long time ago. This isn't good
for our project.
Guido has long encouraged "holistic refactoring" for a reason. This particular
tracker issue is a case study about why that is the case. The origin of this
issue was grepping the standard lib for "ValueError" and "remove" with the aim
of second guessing every message. It was not born out of actual usage of or
concern for the ElementTree module.
The reason that matters is that someone working with the module as a whole
would have realized that this tracker issue is at odds with its creator's
intended design as a thin wrapper around lists. The docs explicitly describe
the API "as a cross between a list and a dictionary".
This one error message isn't atypical (you get the same mention of "list" in
most of the methods such as __getitem__, __setitem__, __delitem__, insert, etc).
We really don't want to start a practice of having every pure python class that
accesses a list or dict revise its code to rewrap the error messages just to
change the class mentioned in the message. This isn't a normal pythonic
practice. It would just clutter, constipate, and slow down the code for nearly
zero benefit.
We really should place more value on code stability, start focusing on modules
holistically, respond to actual user issues rather than invented issues, avoid
frequent trivial changes, and consider that the developers who came before us
might have given a great deal of thought into their code.
----------
nosy: +rhettinger
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30507>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
