Is it better do do thehasattr checks or catch (and ignore) theTypeError fro just trying?

I wondered the same. My reasoning was that since in the previous discussion it was agreed that only a warning should be raised , it made more sense to check for the attiribute rather than to do a try/except.
From a speed pov, I don't think there is going to be any big differences (try/except should be faster when __ len __ exists and viceversa). Thisstack discussioncould also be useful.

With try/except would be something like:

try:iflen(handles)!=len(labels):_api.warn_external(f"Mismatched number of handles and labels: "f"len(handles) ={len(handles)} "f"len(labels) ={len(labels)}")exceptTypeError:pass

vs the current impl

I think using the hasattr() is cleaner, but I don't have a strong opinion about either.

In this file, hasattr is used once before:

All other cases use try/except.

+0.1 on the version of the PR.
IMHO here: "explicit is better than implicit" > "it's better to ask for foregiveness than for permission", because TypeError is quite generic.

I could see an argument for moving it into theif handles and labels: block, which is already the next check.

Thatshould make it so that both are at least iterable (escaping the one or both is None case), though I guess someone could pass e.g.labels=(str(x) for x in itertools.count()), which has nolen and is relying on thezip, so still needsome guard against unbounded inputs.

I think this is clearer. We're not obliged to jump extra hoops for user-friendly length checks if the user passes an iterable without alen implementation (which should be quite rare anyway).