Raise error when iterating over patch objects.

[T4rk1n]

Fix #2512

[alexcjohnson]

@T4rk1n what's the issue with raising on __repr__? Not seeing a problem in a simple test but I haven't run the full test suite on it. Anyway raising on __iter__ is nice, we should probably also do __contains__ (currently 5 in Patch().x is an infinite loop) and maybe __bool__ (a patch is always truthy), __eq__, __ne__ (it will not equal the value it has in the actual prop) - ... but those are all very specific usage cases, it would be nice to do something better for folks just trying to print a piece of the prop.

Actually perhaps better than raising on __repr__ would be just a more descriptive string, something like:

<write-only dash.Patch object at ['layout', 'title', 'font', 'color']>

Another related thing I'm noticing, if someone tries to use part of a prop to set a different part, like this:

patched_figure = Patch()
# seems reasonable, make the figure square?
patched_figure["layout"]["height"] = patched_figure["layout"]["width"]
return patched_figure

it leads to infinite recursion inside clean_to_json_compatible in the plotly.py JSON encoder - any way we can break that?

[T4rk1n]

what's the issue with raising on repr?

Not sure I understand why raise on repr? That is for description of the object so maybe add it like you propose is good.

[T4rk1n]

it leads to infinite recursion inside clean_to_json_compatible in the plotly.py JSON encoder - any way we can break that?

Think that will require more thought, maybe check the value in setattr if it's another patch and prevent that?

[T4rk1n]

and maybe bool

Equality comparators may be used with a filtering system so let's leave them out for now.

[alexcjohnson]

💃 Probably more we could do here, but you're right we should be cautious in case we add other functionality later.