Improve error message when passing an invalid producer to `dict`

[deanm0000]

Bug report

Bug description:

dict("")
# {}
dict(" ")
ValueError: dictionary update sequence element #0 has length 1; 2 is required

I can see how an empty string might be intended to return an empty dict but since " " is raising an error about the 0th element needing a longer length it seems it isn't looking at the type of the input and an empty string works simply because its length is 0.

CPython versions tested on:

3.11

Operating systems tested on:

Linux

[ZeroIntensity]

We might be able to change the error message, but changing the first case would be a breaking change. Empty iterables should always yield an empty dictionary, regardless of their type.

[deanm0000]

Is it a breaking change because of Hyrum's law or is there a genuine use case of generating empty dicts with dict("") instead of dict() or {}? I apologize for coming off argumentative, I'm really just curious if there's something I'm missing.

[ZeroIntensity]

Probably a bit of both. Python is vast, we can't just go changing interfaces because we think they're not used anywhere.

[pochmann3]

Not Hyrum's law. That's about behavior that's only observed. The behavior of dict("") is documented.

[deanm0000]

Not Hyrum's law. That's about behavior that's only observed. The behavior of dict("") is documented.

where?

On this page I see

the positional argument must be an iterable object. Each item in the iterable must itself be an iterable with exactly two elements.

A string doesn't fit that description. It's just that if you ignore its type and when it's empty you can't tell that its items aren't themselves an iterable with exactly two elements.

[ZeroIntensity]

I don't think it's a particularly important distinction here :)

The bottom line is that we can't just disallow strings. dict is documented as accepting any iterable, strings included.

[pochmann3]

A string doesn't fit that description.

An empty string does.