-
Notifications
You must be signed in to change notification settings - Fork 2
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
Some TernaryAxes method signatures don't reflect underlying Axes methods #13
Comments
Thank you so much @morganjwilliams for reporting the issue! Reading the above and morganjwilliams/pyrolite#89, I think it is very reasonable to inherit the method signatures from Thank you also for your suggestions to use I have already implemented them in the
(or something equivalent)? If it works also with |
@yuzie007 will do, I'll let you know how it looks later today. |
Can confirm that with Cheers! |
Thank you @morganjwilliams for kind testing! I am happy to hear that the fix worked together with |
Some of the methods of
mpltern.ternary._axes.TernaryAxes
where the behavior is inherited frommpltern.ternary._axes.TernaryAxesBase
(and hence the underlyingmatplotlib
axes class) do not share a common function signature, due to how they're redefined onmpltern.ternary._axes.TernaryAxes
. This is typically not a major issue, as all associated arguments and keyword arguments are directly forwarded through - but does cause issues for introspection.Demo
Issue
This pops up as a bit of an issue for
pyrolite
which attempts to automatically determine what to forward to relevant methods based on function signatures (for better or worse), and with anonymous method signatures (i.e. where methods are re-implemented but with signatures along the lines ofself, *args, **kwargs...
) some keyword arguments won't get automatically forwarded.Solutions
pyrolite
issue foremost, I'm happy to solve it with a patch-on-import there, if this isn't something you'd like to modify inmpltern
(in which case, feel free to close this issue).For a PR, the two main changes would be:
functools.wraps
toparse
within the respective ternary method decorators inmpltern.ternary_parsers
TernaryAxes
- either by replicating the signature and docstring in these re-definitions, or by directly pointing e.g.TernaryAxes.tripcolor
toTernaryAxesBase.tripcolor
, while still wrapping with the appropriate decorator to handleargs
and the transformThe text was updated successfully, but these errors were encountered: