-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Switch transOffset to offset_transform. #21965
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
Conversation
dacd3fe
to
125b87c
Compare
lib/matplotlib/collections.py
Outdated
if self._offset_trf is None: | ||
self._offset_trf = transforms.IdentityTransform() | ||
elif (not isinstance(self._offset_trf, transforms.Transform) | ||
and hasattr(self._offset_trf, '_as_mpl_transform')): | ||
self._offset_trf = self._offset_trf._as_mpl_transform(self.axes) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder why this sort of thing didn't happen in the setter? Is it some kind of optimization to avoid calling _as_mpl_transform
?
If it were in the setter, you wouldn't need offset_trf
because they'd all fit in a line even with the full name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't remember a strong reason for it (though there might have been one). Perhaps there is some delay in getting an axes
on a collection, and you can only guarantee it exists when you get_offset_transform
?
Certainly worth exploring though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's defer this to another issue, perhaps?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I was mostly trying to avoid the offset_trf
abbreviation entirely, and not go into performance details just now. Mainly, I don't mind the name within a function, but as the private member, I'd prefer it matched the name of the property/argument.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair point, I renamed to _offset_transform.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd go as far as preferring offset_transform
also for local variables (unless you have really bad wrapping issues). trf
does not speak to me at all.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But we already use trf for local variables if quite a few other places, and I'd rather try to establish it as a standard abbreviation (transform is quite a mouthful). Or we can try to standardize on trans, if you prefer?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I find trans
slightly better than trf
. I agree that a standard abbreviation is desireable.
Note that most APIs *previously* already accepted *offset_transform* as kwarg, due to the presence of the `set_offset_transform` setter. Prefer that name (shortening it to `offset_trf` for local variables). Backcompat for the old `transOffset` name is kept in most places by introducing a property alias.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So long as you work out the name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@anntzer If you want to switch the other places from trf
to trans
, you can start here with trans
and do the rest of the renaming in a second commit/PR. If not feel free to self-merge as is.
Let's get this in as is and poll the devs in #22156 :) |
While `offset_transform` is introduced since `matplotlib>=3.6.0`, (matplotlib/matplotlib#21965), `transOffset` can still be used. Also, instead of `_internal_update` (matplotlib/matplotlib#22451), `update` can still be used.
Note that most APIs previously already accepted offset_transform as
kwarg, due to the presence of the
set_offset_transform
setter. Preferthat name (shortening it to
offset_trf
for local variables).Backcompat for the old
transOffset
name is kept in most places byintroducing a property alias.
PR Summary
PR Checklist
Tests and Styling
pytest
passes).flake8-docstrings
and runflake8 --docstring-convention=all
).Documentation
doc/users/next_whats_new/
(follow instructions in README.rst there).doc/api/next_api_changes/
(follow instructions in README.rst there).