This is the same (core) problem as the point about xlabel in #26858. The actual code certainly will accept any object (by virtue of having a __str__ method), but how much of that should be considered "expected" vs "implementation detail"?

One suggestion we have been discussing (from the type hinting side at least) is having an alias like StrLike which actually resolves to object or Any but communicates the intent to treat it as a str.

In the case of passing numbers, it is actually quite unintuitive what happens, as the numbers are now labeling a point (possibly) other than the point that is numerically equivalent. (Even in your (float) example, the numbers appear out of order, for instance, which is likely to cause confusion.) While it works, and if that is truly what you want, you can do it, I actually think by encouraging (if not requiring) explicit casting to string makes your code easier to tell that that was intentional and not e.g. wanting to call set_xticks, but actually calling set_xticklabels. Even moreso with floats, as I think if you were actually wanting float labels, it is likely that you would want to format them to e.g. have 3 decimal places (and also likely that you want it showing up at the numerical equivalence point, at which point, a Formatter is usually the tool for the job rather than passing tick labels directly)

See also this comment on the subject:

#26867 (comment)

As written in #26867 (comment), we’re not going to broaden the docstring types. It’s important that this is logically a str. Consider it an implementation detail that we accept other objects and convert them to str. We’re not making any guarantee that this will always work in the future.