@anntzer@timhoffm another way will be to change

So, I think we have only one option to typecast it. Any suggestions?

Thanks for working on this! In addition to the actually changes this will also need a note inhttps://github.com/matplotlib/matplotlib/blob/master/doc/api/next_api_changes/behaviour.rst

I see the case for changing this is either Axes or Axis. If we are going to do it to x and y, the same should be done for z (inconsistency is one of the most frustrating things for users and one of our biggest problems).

Doing it inAxis fixes it everywhere all, but changing it inAxes is a smaller change.

On balance, given that this api change is primarily on the repr not the coding side (it still has the chance to break people if they are relying on doing anything but looking with their eyes at stdout) I think the "make things as consistent as possible" wins over "make the smallest change you can" so please make the change in Axis.

Thanks for working on this! In addition to the actually changes this will also need a note inhttps://github.com/matplotlib/matplotlib/blob/master/doc/api/next_api_changes/behaviour.rst

I will be happy to make there changes once#17021 is merged. Otherwise it will result in conflicts. So, waiting for it to be merged.

Dealing with merge conflicts / rebases is (for better or worse) a normal part of the workflow on Matplotlib :/ . It is also possible that, so long as there are no over lapping changes to the contents, git will handle the rename smoothly.

Ok. Let me do it now then.

I am :+1 in principle, but I think the API change notes needs a bit more context.

Per#16903 (review) the change should be made on the Axis method, not the Axes wrappers.

44 tests are failing due to indirectly/directly usingAxis methods(get_minorticklabels ORget_majorticklabels). I was worried about this initially(#17028 (comment)) so I did changes on get_{x,y}ticklabels. Shall I now proceed with these changes and change 44 tests OR shall I roll back to changes of get_{x,y}ticklabels?

You need to change the constructor call (the list constructor doesn't take a name, unlike the silent_list one).

Done! Kindly review. Thanks

Rebased

Yeah, sphinx is easy to understand. Varied syntaxes and an uncountable number of new things I am learning here :-)

So, Circle CI is for Sphinx?
Completed the suggested changes

So, Circle CI is for Sphinx?

Yes, we run our doc builds on CircleCI. Note also that you can view the built docs via the respective link in the checks overview list:

That's great! Thanks

I thinkneeds rebase label could be removed now

Thanks@SidharthBansal!

I‘ve squashed the commits before merging. We try to keep the commits reasonably focused to keep our history clean. Since you plan to contribute more, I encouraged you to organize your PRs directly into one or a few semantically separated commits. It‘s ok and common practice to force-push to your feature branch for the fixes and incremental updates.

I will abide by the advice. Thanks!
Yeah, I will continue to contribute. Right now, I am learning packaging and proposal related stuff. So that I can start with that work asap. :)