Skip to content

Conversation

@esc24
Copy link
Member

@esc24 esc24 commented Oct 3, 2012

Modifications to cube.py so that the coord to dimensions mappings (_aux_coords_and_dims and _dim_coords_and_dims) now use tuples rather than lists. This should prevent inadvertent side effects. Cube.coord_dims() now returns a tuple of ints. cube.xml_element() explicitly converts to a list for xml output (there was a mix of tuples and lists before).

@pelson
Copy link
Member

pelson commented Oct 3, 2012

Looks good. +1 once there is an entry in the changelog. :-)

@rhattersley
Copy link
Member

It'd be nice to have a quick test of the defensive, immutable properties. e.g. Pass in a list when constructing a Cube, modify the list, check the Cube is still OK.

@ghost ghost assigned rhattersley Oct 3, 2012
@pelson
Copy link
Member

pelson commented Oct 3, 2012

It'd be nice to have a quick test of the defensive, immutable properties.

Do we even have that in general? I can't imagine that the cube's data is a copy from the one I might have given it - therefore I assume I could directly set it's .shape and change the underlying cube's data. If I do such a silly thing, I think it is my own fault. The point I'm making is that I don't really mind if a user wants to do what you described - its a silly thing to do, and in the future it is very likely that any dependence on such strange behaviour is likely to change without warning.

@esc24
Copy link
Member Author

esc24 commented Oct 3, 2012

I'm going to close this, write a short test, add something to the changelog/what's new and re-open.

@esc24 esc24 closed this Oct 3, 2012
@rhattersley
Copy link
Member

... I don't really mind if a user wants to do what you described - its a silly thing to do, and in the future it is very likely that any dependence on such strange behaviour is likely to change without warning.

Firstly, we're just as fallible as anyone else. There's a chance we'll write code which relies on bad behaviour. So we should try to prevent that where possible. Secondly, once enough people start using something it doesn't matter if it's undocumented, private, silly, whatever ... changing it will cause them pain, and it's our job to reduce pain levels, not increase them. ;-)

@esc24 esc24 reopened this Oct 3, 2012
esc24 added 2 commits October 3, 2012 14:45
…n lists to prevent inadvertent side effects from mutable type. Cube.coord_dims() now returns a tuple of ints.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would have been fine to simply do some type checking here (i.e. assert it is a tuple).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Arguably the current check is better - it's testing the desired behaviour, and could conceivably survive a switch to an alternative immutable type.

pelson added a commit that referenced this pull request Oct 3, 2012
Use of tuples for dimensions in coord to dim mapping
@pelson pelson merged commit c42003d into SciTools:master Oct 3, 2012
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This stuff is already handled in the load API PR.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry already merged. Would you mind re-basing the load api PR and handling this conflict (and I will then merge).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

rolls eyes

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pelson Done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants