>
>
> In general Python error messages don't include the relevant values or much
> information about them, although I often wish they would. For example when I
> get a KeyError I wish I could see which keys are present, unless there's too
> many for it to be practical. I'm speculating, but I
I also would prefer richer exceptions especially if it can be done without
introducing any other problems.
In the same vein, I once suggested a richer inheritance failure message
(this, basically: https://github.com/NeilGirdhar/inheritance_graph), for
which if I remember correctly Guido was
There was a proposal (by me) some time ago to add some structured
information to some of the Exceptions. See
https://www.python.org/dev/peps/pep-0473/, but it finally got rejected due
to being too broad. I'd be happy to revive (parts of) the proposal if
anyone is interested.
I managed though to
On Mon, Mar 2, 2020 at 12:47 AM Christopher Barker
wrote:
> That being said, more information is better than less, so maybe an
> unpacking error should show the *value* of what was being unpacked:
>
> >>> a, b = 1, 2, 3
> Traceback (most recent call last):
> File "", line 1, in
> ValueError:
On Sun, Mar 1, 2020 at 6:51 PM Christopher Barker
wrote:
SNIP
the problem here is that "iterable unpacking" (is that what we call it
> now?) is pretty general, and used all over python.
> ValueError: too many values to unpack (expected 2)
>
> Which, in fact, is what iPython already does:
>
> In
the problem here is that "iterable unpacking" (is that what we call it
now?) is pretty general, and used all over python. In the example given, it
seemed that that would be a helpful message, but it wouldn't really solve
the general problem: that is, that dicts iterate over keys, and people
>
> IIRC, the new unpacking code still works like the old in that it
> special-cases list and tuple (where it can use the fast indexing API that
> just accesses the C array underneath), but for everything else it calls a
> function with iter(obj). If so, adding the length for list and tuple would
On Mar 1, 2020, at 05:03, Alex Hall wrote:
>
> Is there anyone who thinks it's acceptable to run `len()` on arbitrary
> objects for an error message? Assuming 'no', then the length is only shown if
> the type is exactly one of list, tuple, str, etc. where we know __len__
> exists and is safe.
On Mon, Mar 2, 2020 at 12:01 AM Alex Hall wrote:
>
> Chris Angelico wrote:
> > So the only way would be to call len(), and if it fails, fall back
> > on
> > the "expected 2" form. And I'm not sure if that would be worthwhile,
> > given that it's going to have to run arbitrary code just for the
Chris Angelico wrote:
> So the only way would be to call len(), and if it fails, fall back
> on
> the "expected 2" form. And I'm not sure if that would be worthwhile,
> given that it's going to have to run arbitrary code just for the sake
> of the error message.
I did address these:
> The length
On Sun, Mar 1, 2020 at 11:35 PM Alex Hall wrote:
>
> Currently this code:
>
> d = {"key": "value"}
> for key, value in d:
> pass
>
> produces this error:
>
> ValueError: too many values to unpack (expected 2)
>
> I suggest that the error message should also have:
>
> 1. The name of the type
11 matches
Mail list logo
