BindError as a built-in TypeError subclass (on the margin of PEP 362 discussion)
Suggestion ========== I think that BindError proposed in PEP 362 could be a built-in TypeError subclass, raised whenever given arguments do not match a given callable: 1. while using Signature().bind(...) [as proposed in PEP 362], and also 2. while using inspect.getcallargs(...) and *also* 3. while doing *any* call. Rationale ========= The present behaviour (ad 2. and 3.), i.e. raising TypeError, makes it hard to differentiate call-argument-related errors from other TypeError occurrences. Raising BindError (or ArgumentError? the actual name is disputable of course), being a TypeError instance, instead -- would made easier implementing test suites, RPC mechanisms etc. Cheers. *j
Chris Rebert wrote:
Even if I wanted to replace ValueError with ArgumentError (and I don't), we couldn't due to backward compatibility. (Although I suppose ArgumentError could inherit from both TypeError and ValueError.) 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. -- Steven
On Sun, Jun 10, 2012 at 10:00 PM, Steven D'Aprano <steve@pearwood.info> wrote:
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@gmail.com | Brisbane, Australia
Nick Coghlan <ncoghlan@gmail.com> writes:
“ArgumentBindError”, then? -- \ “Airports are ugly. Some are very ugly. Some attain a degree of | `\ ugliness that can only be the result of a special effort.” | _o__) —Douglas Adams, _The Long Dark Tea-Time Of The Soul_ | Ben Finney
On Sun, Jun 10, 2012 at 5:00 AM, Steven D'Aprano <steve@pearwood.info> wrote:
You seem to have misinterpreted the intent behind my post. I'm in no way arguing that ValueError and "ArgumentBindingError" should be conflated. I'm pointing out that another very similar language (Ruby) has an error of the same name with a very similar purpose (which it also distinguishes from its TypeError), thus providing further validation of the use case for the proposed ArgumentBindingError. Cheers, Chris
Chris Rebert wrote:
Even if I wanted to replace ValueError with ArgumentError (and I don't), we couldn't due to backward compatibility. (Although I suppose ArgumentError could inherit from both TypeError and ValueError.) 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. -- Steven
On Sun, Jun 10, 2012 at 10:00 PM, Steven D'Aprano <steve@pearwood.info> wrote:
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@gmail.com | Brisbane, Australia
Nick Coghlan <ncoghlan@gmail.com> writes:
“ArgumentBindError”, then? -- \ “Airports are ugly. Some are very ugly. Some attain a degree of | `\ ugliness that can only be the result of a special effort.” | _o__) —Douglas Adams, _The Long Dark Tea-Time Of The Soul_ | Ben Finney
On Sun, Jun 10, 2012 at 5:00 AM, Steven D'Aprano <steve@pearwood.info> wrote:
You seem to have misinterpreted the intent behind my post. I'm in no way arguing that ValueError and "ArgumentBindingError" should be conflated. I'm pointing out that another very similar language (Ruby) has an error of the same name with a very similar purpose (which it also distinguishes from its TypeError), thus providing further validation of the use case for the proposed ArgumentBindingError. Cheers, Chris
participants (6)
-
Ben Finney -
Chris Rebert -
Jan Kaliszewski -
Nick Coghlan -
Steven D'Aprano -
Yury Selivanov