On Wed, 4 Mar 2020 at 12:33, Chris Angelico wrote:
> Being able to easily distinguish "that isn't callable" from "the
> parameters don't line up" from "the function, during execution, raised
> TypeError" would be useful.
I **completely** agree. And I add that the change can also be
non-breaking,
It seems to me that this thread is a bit too focused. I know I’ve found
that often I wish I knew better exactly what caused a particular Exception—
there are many that can be raised for various reasons, and you may need to
know which one in order to handle it properly.
At this point, parsing the
On 03/04/2020 06:24 AM, Steven D'Aprano wrote:
My earlier use-case still stands: feature detection where a function has
changed its parameter list. More on this below.
It seems like `inspect.signature` is the right way to do this kind of
feature detection.
On Wed, Mar 04, 2020 at
On Mar 4, 2020, at 03:00, Steven D'Aprano wrote:
>
> On Wed, Mar 04, 2020 at 01:08:35AM -0800, Andrew Barnert wrote:
>
>> I liked everything up to using magic numbers like this.
>
> I'm not wedded to the idea of error number. I chose them because I
> expect there will only be a few of them
> Both of these calls raise TypeError, but for different reasons:
> # right number of arguments passed to the key function,
> # but the wrong argument type
> sorted([3, 5, 1], key=len)
>
> # wrong number of arguments passed to the key function
> sorted([3, 5, 1], key=isinstance)
>
> It might be
On Wed, Mar 4, 2020 at 2:58 AM Steven D'Aprano wrote:
> I don't know enough about the Python internals to give a definitive
> answer, but I'm assuming/hoping that there is a single, or at most a
> few, places in the interpreter that matches up arguments to formal
> parameters, and if there's a
On Wed, Mar 04, 2020 at 12:19:25PM +0200, Alex Hall wrote:
> Can you explain where `except ParameterError` would produce better code
> than the best current alternative?
Serhiy came up with a good use-case that I hadn't considered: functions
which take arbitrary callback functions as argument,
On Wed, Mar 04, 2020 at 02:09:00PM +0200, Serhiy Storchaka wrote:
> If add such exception, ArgumentError looks more appropriate name.
Thanks Serhiy, I considered that but thought that ArgumentError was
likely to be used in third-party libraries.
A quick google shows that argparse and Boost
On Wed, Mar 04, 2020 at 11:10:15AM +, Jonathan Fine wrote:
> We are talking here about an exception message that is generated by core
> Python. So there would be some warning of change, namely the review process
> for core Python.
You can't call the error message a stable part of the
On Wed, Mar 04, 2020 at 10:12:34AM +, Jonathan Fine wrote:
> I find this behaviour perfectly satisfactory. The OP's problem can be
> resolved by looking at the exception, whose type is TypeError.
>
> For this to be completely reliable, certain aspects the exception message
> need to be
04.03.20 09:06, Steven D'Aprano пише:
Proposal: add a new exception, ParameterError, for parameter errors. For
backwards compatibility it would have to be a subclass of TypeError.
If add such exception, ArgumentError looks more appropriate name.
Where the interpreter now raises TypeError for
On Wed, Mar 4, 2020 at 9:58 PM Steven D'Aprano wrote:
>
> The important thing is to be able to programmatically
> distinguish the case where arguments don't match the parameters from the
> case where an argument is the wrong type.
>
Or where you're trying to call something that isn't callable.
Steven D'Aprano wrote:
Another alternative is to testing for key phrases in the exception
> message:
>
> if "too few arguments" in err.args[0]: ...
>
> but that's fragile and only works until the message gets changed to say
> "not enough arguments". (The error message is not part of the API,
On Wed, Mar 04, 2020 at 01:08:35AM -0800, Andrew Barnert wrote:
> I liked everything up to using magic numbers like this.
I'm not wedded to the idea of error number. I chose them because I
expect there will only be a few of them (three?) and the majority
of the time you won't bother to check
Postscript: Things are not as clean as I have hoped and said. However, I
don't think this changes the general form of the conclusion. Just that a
little more work is needed to achieve the goal.
Python 3.7 and 3.8:
>>> def f(x): pass
>>> f()
TypeError: f() missing 1 required positional
Can you explain where `except ParameterError` would produce better code
than the best current alternative? It seems to me that using this is like
stating "this code might be wrong" and would generally produce bad code.
For example if I wanted to use math.gcd on multiple values but I need to
Hi
The present behaviour is:
>>> len()
TypeError: len() takes exactly one argument (0 given)
>>> len(1, 2)
TypeError: len() takes exactly one argument (2 given)
This is nothing special about built-ins. The same goes for:
>>> def f(): pass
>>> f(1)
TypeError: f()
On Mar 3, 2020, at 23:11, Steven D'Aprano wrote:
>
> But for stability reasons (what if the error messages are localised, or
> change in the future?), we could give the exception a "reason"
> attribute, with a documented stable ID, and make that the official way
> to programmatically
18 matches
Mail list logo
