Looks like a great start! I think there were a few places that you added in a definition of cla() into a subclass when it could be inherited from the superclass, so I'd suggest looking at what each of the classes is inheriting from and making sure that there is a cla() in the parent that can get used. Let me know if that doesn't make sense or if I'm mistaken too!

@greglucas Thanks for the feedback and suggestions! I just amended the PR. Summary:

• The cla() methods are now removed from all axes subclasses.
• The test case is also updated and (locally) is verified to be passing.
• Relevant deprecations have been removed and logged in the doc/api/next_api_changes/removals folder.

Please let me know if there's anything else I should do!

Just pushed our updates. Unfortunately, we accidentally fetched from upstream before pushing and as a result there are some changes (particularly in pyplot) that are from upstream (the root matplotlib repo). Hopefully this is ok - if not, is there any way around this?

@greglucas Thanks for the feedback and suggestions! When trying to merge my changes to the current commit, I kept running into Failed to Push Refs due to stale info errors as shown here. Then I tried to "fetch the updates from upstream and rebase first" as outlined in this source, which caused the merge from main commit you saw.

Anyways, my partner (@lijake8) was able to amend our changes for this PR.

Summary:

• Reverted pyplot.py file to the pre-PR version with no addition of a clear() function

• Removed the test_cla_not_redefined() function from the test_figure.py file.

• Removed the def cla(self) for ParasiteAxes , HostAxes, and FloatingAxes as these three inherit from the Axes parent class using theClassFactory method.

Please let me know if there's anything else we should revise or do!

FInally fixed the commits issue with latest updates in accordance with notes above

@timhoffm @oscargus Do either of you mind reviewing this PR? Thanks!

Thanks @lijake8 and congratulations on your first contribution to Matplotlib! We hope to see you again.

@timhoffm My partner @lijake8 and I both worked on contributing to this issue together.

We also added my name as a co-author to the commit message of our PR as instructed by @greglucas above:
"Also, if you want to add your friend as a contributor on the commit, you can use the "co-authored-by" feature in the commit message: https://docs.github.com/en/github-ae@latest/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/creating-a-commit-with-multiple-authors"

Link to Co-Author Confirmation Screenshot: https://drive.google.com/file/d/14Jq8-fY_ZnIRJhUmypprvf4rG7A3Y6xk/view?usp=sharing

Can you confirm that both myself @neil-gurnani (Neil Gurnani) and my partner (@lijake8) will be credited for this contribution?

Thank you for your guidance with this and your approval of our Pull Request!

Can you confirm that both myself @neil-gurnani (Neil Gurnani) and my partner (@lijake8) will be credited for this contribution?

You’ve not followed the format that GitHub defines for co-author attribution. So on the technical side only @lijake8’s account is linked to the PR. OTOH @neil-gurnani your name is in the commit message, which states that you have contributed.

As Tim said, it looks like the commit message did not trigger the co-author logic in GH. I suspect the issue is that GH is looking for the tags at the end, but you put it in the first line of the commit message (that normally says what it is you did).

On one hand I am sympathetic to wanting to get this fixed and get your name listed on GH as a contributor. On the other hand I do not think we want to do a force-push to main to re-write history to fix the commit message (we have force pushed to main in the past but it is my judgement that this does not cross the threshold to do that) and I do not think that adding an empty commit with your name on it is a good option either (it makes it really odd if anyone looks it up later and I think is a bad precedent to set).

Given that the concept of co-authoring is a GH concept (rather than a pure git concept), it may be worth reaching out to github support about this. At a minimum they can add a warning to their docs about where the line is searched for.