On Sun, Jun 10, 2012 at 10:00 PM, Steven D'Aprano <steve at pearwood.info> wrote:
> My concept is that errors due to the wrong argument count, duplicate or
> missing keyword arguments, etc. which currently raise TypeError could raise
> ArgumentError, a subclass, instead.
>> That will make distinguishing between "passed the wrong number of arguments"
> from "passed the wrong type of argument" easier.
This is actually why I prefer "BindError" to the name "ArgumentError".
The former is explicit about what has gone wrong: the supplied
arguments could not be bound to the parameters expected by the
supplied callable.
"ArgumentError", on the other hand, could easily refer to any of:
- failing to bind the supplied arguments to the expected parameters
(currently TypeError, will be BindError when using PEP 362)
- one or more of the arguments is of the wrong type (currently TypeError)
- one or more of the arguments has an unacceptable value (currently ValueError)
While I don't think the PEP should be held up over it, the idea of
making BindError a builtin exception and also raising it in the
interpreter's internal parameter binding code is certainly an
interesting idea to explore in the future.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia