On Mon, Mar 2, 2020 at 12:01 AM Alex Hall <alex.moj...@gmail.com> 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 sake > > of the error message. > > I did address these: > > > The length of the unpacked value, if it exists and (to not execute > > arbitrary __len__ implementations) if the type belongs to a safe subset, > > e.g. only builtin types. > > 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. Alternatively, instead of checking the type, we could > check if `__len__` itself belongs to a safe set, if we want to include e.g. > subclasses of `list`. >
It seems very odd to say "built-in types only", IMO (or any other arbitrary whitelist). It'd be cleaner to either call it regardless of the type, or just not do that. The inconsistency seems like more trouble than it's worth. For your provided use-case, the length is almost irrelevant; the best way to spot the bug is to see "oh, it was trying to unpack a string, not a tuple". And that part can be done much more easily and safely. ChrisA _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/MOM2ZELD6BMVML7AEJ6QMNGYPUFG72I5/ Code of Conduct: http://python.org/psf/codeofconduct/
