Remove the iterability of a cube

[pelson]

Making a cube iterable causes more issues than it is worth (@munslowa found this to his surprise).

import iris
fname = iris.sample_data_path('air_temp.pp')
temperature = iris.load_strict(fname)
for thing in temperature:
    print thing

Remove this capability from the cube.

[esc24]

I've always found this a little unintuitive. However, thinking back I have made use of it on occasion when I don't want to list all the other non-scalar coordinates in cube.slices().

[pelson]

Where does this functionality come from?

http://www.python.org/dev/peps/pep-0234/ namely:

    The two methods correspond to two distinct protocols:

    1. An object can be iterated over with "for" if it implements
       __iter__() or __getitem__().

Since we implement __getitem__, one can iterate over a cube.

[esc24]

Given the source of this behaviour, I'm in favour of leaving it.

[pelson]

@esc24 Just to clarify. Your original post was in favour of removing the behaviour, but based on further information you would want to keep it?

[esc24]

To be clear - I want to keep it (for consistency with standard python behaviour relating to __getitem__).

[pelson]

Other than the for consistency argument, I don't see any benefit to this functionality. Worse than that, the behaviour is unexpected (to me and at least @bblay based on his comment), and makes it too easy to act on a cube thinking that it was actually a cube list.

The functionality itself can obviously be replaced with cube.slices, so for me the argument comes down to consistency vs no surprises.

[rhattersley]

... for me the argument comes down to consistency vs no surprises.

You need to throw convenience and conciseness into the mix too. Being able to do cube[:, :10, :, :] to pull out the bottom ten levels of a 4-dimensional cube is pretty handy.

[pelson]

To be clear, I am not suggesting we throw __getitem__ out.

class Thing1(object):
    def __getitem__(self, key):
        if not 0 <= key < 10:
            raise IndexError()
        return key

class Thing2(Thing1):
    def __iter__(self):
        raise IndexError("Thing2 isn't iterable")

print [v for v in Thing1()]
print [v for v in Thing2()]

Result:

[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

Traceback (most recent call last):
  File "iterfoo", line 12, in <module>
    print [v for v in Thing2()]
  File "iterfoo.py", line 9, in __iter__
    raise IndexError("Thing2 isn't iterable")
IndexError: Thing2 isn't iterable

[rhattersley]

I have deliberately used for slice in cube previously, but it's a pretty incidental benefit, so if iterable cubes is causing confusion I'm happy to see it removed.

+1 for raising an error (although I would suggest TypeError)

[esc24]

I'd be happy to let this go if there was a way to iterate through a cube along a specified dimension(s) or coord(s). cube.slices() demands that I specify all the coords I don't want to iterate through.

[esc24]

I've changed my mind again. +1 for removing it with an exception.

[rhattersley]

Fixed in #273.