-
Notifications
You must be signed in to change notification settings - Fork 281
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: move iris.cube.Cube to iris.Cube #891
Comments
I can see the benefit of doing this, but the real problem for me is documenting it. Perhaps if Other than that, nice suggestion - it is something that has crossed my mind more than once. |
It's crossed my mind too. |
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 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 |
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. |
It seems unlikely that this desire is limited to So I don't think this can be easily dismissed, nor can it be easily completed! |
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. Test timings on my machine :
|
Part of a larger conversation: |
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. |
I find myself constructing a lot of cubes and cubelists manually when I implement new functions to manipulate cubes.
Since these are core API objects, I suggest they should be moved from
iris.cube.Cube
andiris.cube.CubeList
toiris.Cube
andiris.CubeList
(via an import statement in/lib/iris/__init__.py
). This would be consistent with many other Python libraries (e.g., Pandas), for which the core API is also usually exposed at the top level.As a library user, it's just easier not to need to know about the structure of Iris's code to find a class or function. I can see a case for consolidating other functions into a broader namespace as well, but Cube and CubeList are the worse offenders (in my view). In my view, exposing submodules in a library's API should be done with caution, and only when it is clearly easier for library users.
The text was updated successfully, but these errors were encountered: