Thanks for your contribution! Can you please provide a reproducible piece of code that failed before, but this fixes. Thanks!

@jklymak https://github.com/atulapra/Emotion-detection for instance

Traceback (most recent call last):
File "emotions.py", line 98, in
plot_model_history(model_info)
File "emotions.py", line 31, in plot_model_history
axs[0].set_xticks(np.arange(1,len(model_history.history['accuracy'])+1),len(model_history.history['accuracy'])/10)

The second argument to set_xticks() is a list of labels. This shows a scalar float being passed in. The bug is in that package.

and I am looking at main right now, and axis.py at these lines don't look like this, so I am quite confused about what is going on...

Ah, I was taken to the specific commit rather than the PR's changes page, which is why I was confused. Yeah, this isn't a bug in matplotlib at all. The bug is in the other package's incorrect use of set_xticks().

I see. Sorry, my misunderstanding. Wouldn't my changes however, also make it work in the case where someone uses set_xticks() incorrectly? Asking because I don't understand all the working parts of matplotlib underneath the hood

No, it actually breaks things further for correct use-cases (by not working for an iterable of strings), and it wouldn't fix anything for your use-case. The code expects an iterable, and the function documentation says that it expects an iterable, and it is getting a single float value that can't serve as a list of labels.

If there is any bug here, it is that matplotlib probably could have raise an error sooner in the stack rather than deeper down in the internals.

Thank you! I would like to help with raising the error, where should I start? What file would I be working on?

So, looking at the very interesting set of indirections we have (we avoid having duplicate code for x and y axis), it appears that this function actually is near the top of the stack that one could reasonably do a check. One could also do a check up in this file's set_ticks(), but that just calls set_ticklabels() if the labels aren't None, and set_ticklabels() is public-facing anyway.

So, basically, check that it is an iterable and if not, raise a TypeError. I think we have some functions for that somewhere in a utils file...

Ok, will do

@WeatherGod Wouldn't

    try:
        _ = (e for e in ticklabels)
    except TypeError:
        print(ticklabels, 'is not iterable') 

be sufficient?

So, really, the objective here is a better exception message, so we'd just capture the TypeError from the list comprehension, and raise a new TypeError like so:

raise TypeError(f"{ticklabels:=} must be an iterable") from None

The from None part is important because it tells python to discard the current exception context so it doesn't think that this is an exception caused by exception-handling.

Maybe "sequence" is a better term, since a string is an iterable, but would be an incorrect input.

        try:
            _ = (e for e in ticklabels)
        except TypeError:
            raise TypeError(f"{ticklabels:=} must be a sequence") from None

Would this work?

@WeatherGod

I've moved to draft until you sort out your approach. Also a reproducible self-contained example would be appreciated. You can't expect us all to download "EmotionDetection"! In lieu of this, you should add self-contained tests. Thanks....

@jklymak Got it but I was referring to the approach @WeatherGod suggested and adding that to set_ticklabels() function

@Krish-sysadmin Yes, that approach looks good (but I would just wrap the current list comprehension rather than adding a new local variable for a generator).

#22710 (comment) This approach of catching errors, printing, and then carrying on is something you should almost never do in a library context. We do not know enough to know that the user wanted so we can not fix it. It is then our job to tell the users something went wrong. It is then up to the application layer to catch that exception and do something about it (because at the application layer they know things might go wrong and how to fix them or know that this was an optional thing that can be ignored or ...) or pass the exception up to their caller who might know what to do and so on and so on up the callstack. In an interactive context you then hit the shell who says "right, I'll just print out the whole traceback for the human to look at" or in a script context Python say "I'm going to print the traceback, but then exit because I have nothing else I can do".

Quoting the Zen of Python https://peps.python.org/pep-0020/#the-zen-of-python

Errors should never pass silently.
Unless explicitly silenced.

I would add that I was doing some user support last week where the user had done exactly this pattern (try: ... except Exception: print() ) and it took use 15 minutes to track down where the try/except was and then once we saw the trace back about 15 seconds to understand and fix the problem.

PS sorry, you tried to fix a bug and instead got a software design philosophy discussion ;)

Thanks, Thomas. If I understand correctly, this is alright then.

        try:
            [e for e in ticklabels]
        except TypeError:
            raise TypeError(f"{ticklabels:=} must be a sequence") from None

?

@tacaswell

No, we mean putting the try...except around this:

        ticklabels = [t.get_text() if hasattr(t, 'get_text') else t
                      for t in ticklabels]

Of course, this is always a risk that t.get_text() has a side-effect of causing an unrelated TypeError, but it is just a getter, so it should be fine.

@WeatherGod

@WeatherGod Now Linux tests fail for some reason. I suspect macos will too

Wait, now all Linux, macOS and Windows tests fail

Does anybody know if the build and test problems are fixed on the main branch? Would merging main into this branch likely fix it?

Does anybody know if the build and test problems are fixed on the main branch? Would merging main into this branch likely fix it?

I have no authority here, but I think you need #22766?

This should be squash-merged.

For 3.7?

So all the tests pass. Can this be merged?

Thanks @Krish-sysadmin, and congratulations on your first contribution to Matplotlib. We hope to see you back!

Can this be merged?

We aim for a concise commit history. Typically that means one or very few logically grouped commits. It's helpful if you could do this in future pull requests yourself. That was the comment in @tacaswell's approval, which prevented immedate merging. - I've now squash-merged all the commits into one. No worries if you need help with handling git to directly have only one commit in your PR even with updates. We can help you in a next PR if needed.

Thanks, Tim!