pytypes: Add iterable_t<T>

[EricCousineau-TRI]

Description

Resolves#1773 as an alternative / less disruptive approach
Drawing from RobotLocomotion/drake#14898

Suggested changelog entry:

iterable_t<T> added as a simple pytype

[rwgk]

Cool! Just questions regarding compatibility with the smart_holder branch.

[alexdewar]

Just commenting to say I'm working on something atm for which this would be useful :-)

[rwgk]

Just commenting to say I'm working on something atm for which this would be useful :-)

This needs to be resurrected after the sweeping changes for clang-format and Python 2 drop. You could transfer the diffs to a new PR and work on it there.

[EricCousineau-TRI]

This needs to be resurrected after the sweeping changes for clang-format and Python 2 drop. You could transfer the diffs to a new PR and work on it there.

It was luckily small enough w/ just a merge + conflict resolution. I think the review is still fine w/ merge. Let me know if you'd still like a new PR.

[EricCousineau-TRI]

is_generic_type split off into #3857

[rwgk]

High-level:

At the moment list_caster in stl.h explicitly checks whether the input argument is a sequence, but I would like to argue that that's slightly too restrictive and iterable should be accepted.

The code seems to be dicy ("bad! For now,") and the gain seems really minute ("slightly too restrictive").

The current implementation doesn't seem exception safe (leaks b/o missed Py_DECREF if exceptions are thrown before the control flow reaches those).

But really I feel it's best not to get into this scraping-the-bottom-of-the-barrel territory at all.

[EricCousineau-TRI]

Aye - so you think it's best to not introduce the feature? Fine by me, just want to clarify some points.

The code seems to be dicy ("bad! For now,") and the gain seems really minute ("slightly too restrictive").

Too restrictive in what sense? Not an iterator, or shouldn't check types, or something else?

[rwgk]

Aye - so you think it's best to not introduce the feature? Fine by me, just want to clarify some points.

The code seems to be dicy ("bad! For now,") and the gain seems really minute ("slightly too restrictive").

Too restrictive in what sense? Not an iterator, or shouldn't check types, or something else?

Sorry I wasn't clear, the "slightly too restrictive" quote is from here: #1773

I.e. my interpretation was that even the original requester was thinking the current behavior is only "slightly too restrictive". (I agree.)

My cost/benefit assessment is just one vote! Yes, I'd say let's not add this, but if there are other opinions I'll reconsider. I'm just offering my current opinion.

[EricCousineau-TRI]

Sounds good! I'm not too wed to this, but will await opinions, and close if we don't hear back for a bit (~month?)

@alexdewar If you're available, is this still useful as-is?