I can see the benefit of doing this, but the real problem for me is documenting it. Perhaps if iris.Cube existed in our documentation and simply linked to the iris.cube.Cube documentation then that might be a way to go.

Other than that, nice suggestion - it is something that has crossed my mind more than once.

It's crossed my mind too. iris.Constraint comes to mind as an example where we've done it. I know shapely does this kind of thing (e.g. shapely.geometry.Polygon and shapely.geometry.polygon.Polygon). However, I find this confusing and I like namespaces. I'm wary of there not being one and only one obvious way to do it. That said, if we keep the list of top level objects to an absolute minimum I can see why it's appealing.

I think the multiple paths is pretty common and unlikely to be confusing as long as the documentation keeps things straight. For example, you can also find np.array in np.core.multiarray.array.

I agree that the main challenge here is documentation, so perhaps I will leave this to those more familiar with Iris's documentation generator. It should definitely be possible to document iris.Cube and not iris.cube.Cube, since so many other packages manage to do it. The code patch will simply be adding from iris.cube import Cube, CubeList, CubeMetadata to /lib/iris/__init__.py (and adding them to the __all__ list).

The code patch will simply be adding from iris.cube import Cube, CubeList, CubeMetadata to /lib/iris/init.py (and adding them to the all list).

I was concerned about circular imports (they've bitten us before!) but I gave it a quick go and it was fine.

👍 nicer code

Do we still want to do this? Intuitively, it would undo some of the import speed gains from #4174.

Do we still want to do this? Intuitively, it would undo some of the import speed gains from #4174.

It seems unlikely that this desire is limited to Cube. We've previously discussed making all commonly used API available at the top level, taking inspiration from Numpy (#3429 (comment)).

So I don't think this can be easily dismissed, nor can it be easily completed!

@trexfeathers it would undo some of the import speed gains from #4174.

I don't think this is a practical issue in itself : If you're using Iris at all, you will be using cubes, so the additional cost of "import iris.cube" is one that every reasonable usage will get anyway.
The only difference is in the "headline figure" import time : for me, that goes from ~0.1 secs to ~0.6secs.

Test timings on my machine :

Part of a larger conversation:

• Populate namespace: lazy_loader #4710
• Iris Core + Plugins #4798

In order to maintain a backlog of relevant issues, we automatically label them as stale after 500 days of inactivity.

If this issue is still important to you, then please comment on this issue and the stale label will be removed.

Otherwise this issue will be automatically closed in 28 days time.