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 of the unpacked value
2. The length of the unpacked value, if it exists and
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 of
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 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 sak
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.
>
> 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
>
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
sometim
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 [