I think that restricting to anint is deeply flawed, really we want any scalar value (including unitful scalars, such as datetime objects). Certainlyat least there is no reason to disallow floating point scalar values if we are allowing setting the baseline to arbitrary values.

I also think that perhaps even more important than the code change allowingbaseline to be scalar is the documentation (and testing) aspects of this code change, which are not reflected here.

I'm pair programming alongside@EricRLeao1311. We've changed to code so it accepts floats, but we still have some questions about testing and documentation. About testing, how could we improve/fix it? We found some tests in test_axes.py, but they use a @image_comparison wrapper, and we are unsure on how to make it work for our case. We tried to include some cases, but we don't know if they were made correctly. And about documentation, we attempted to improve the docstrings related to the function. Is that enough? Thanks!

I still think float is too restrictive, and that we should be looking at unit-aware changes, so whilefloat is a lot better than specificallyint, I still don't think it is far enough

Ok, I see that you want it to be more expansive than float-only, but we are having trouble on what types we should accept and how to treat the different types. Could you enlighten us in any type of way?

Because the units system can have arbitrary values, there isno restriction on the type, much like thebottom value for e.g.ax.bar, which is documented as "float or arraylike", but also contains an explicit note about if it has units.

https://matplotlib.org/stable/api/_as_gen/matplotlib.axes.Axes.bar.html

This should be treated similarly, in that it gets passed throughaxes._process_unit_info:

Where this has odd behavior:

• categorical data (in general), as you cannot just add them in their raw forms and so I don't think it can make sense here (you could maybe add them post-conversion, but I think you actually want to convertmost things after adding...)
• categorical data (in specific), even if we sorted out the general problems, if you happen to have a category called "zero", "sym", "wiggle", etc, then you would be unable to specify those as the baseline... This is an edge case I don't see astoo big of a problem, but it is odd.

I think that it could be:

• remove thecheck_in_list entirely
• add anelse case to theif baseline == chain which callsaxes._process_unit_info(("y", baseline)) setsfirstline = baseline and doesstack += baseline (theremay be some shape massaging for 1D data, like there is forsym, but for scalar data it should just be+=
• Do something about thenp.promote_types call... not sure exactly what, but e.g. datetime64 should not be promoted (and will error)