Straw man: alternative solution for non-cubes in cubelists

[rcomer]

As raised at #1897 , it is possible for cubelists to contain objects that are not cubes. This can lead to operations on cubelists failing with AttributeErrors that can be confusing for the user. #3238 attempted to lock down the cubelist contents so only cubes are allowed. That solution turned out to involve a seemingly disproportionate amount of new code, and also prompted objections that cube-like "duck type" objects should be accommodated.

Within #3238, @pp-mo suggested

another possible approach is simply to improve those operations that fail when you give them a list (ideally, an iterable??) of things that it "expects" to be cubes

This new branch introduces a decorator to catch AttributeErrors and instead raise a more helpful error about the cubelist contents being wrong.

Advantage I believe this should solve the question of duck types, as anything that used to work still will.

Disadvantages

• To make this comprehensive, we'd need to hunt out all the functions in the codebase that operate on cubelists and their elements (it also wouldn't help with user-written functions).
• I vaguely remember reading somewhere that try-except loops are inefficient.
• Not really sure of the appeal of having the decorator scattered around the place.
• Potentially AttributeErrors might occur because of some other problem than the cubelist contents. Easiest solution to this is to make the eventual error message more detailed: "This error was triggered: '...' The most likely explanation for an AttributeError here is..."

Disclaimers

• I haven't given any deep thought to the decorator name or exactly what exception it should raise.
• I've decorated a bunch of functions that I know very little about.
• I've never written a decorator before (good to have an excuse to learn though!)

[rcomer]

As per #3238, I don’t think this is going anywhere any time soon.