I think this misses the semantic difference between s in scatter and markersize in plot. In scatter, s is meant to be an array in scatter, whereas markersize cannot be an array in plot. I think the changes proposed here make the difference even more confusing, and we should be very deliberate about what we do here.

First, I don't think you should snake the scaling through to the low-level object. get_sizes should just return what it's always returned, with an explanation in the docs.

Second, I think you should consider that s=array is how to specify arrays for the markersizes, and markersize=float is a shortcut for plot-like scaling if s is not provided. eg, markersize should not accept an array. If s and markersize are both specified, it should probably error out.

I don't think you should snake the scaling through to the low-level object. get_sizes should just return what it's always returned, with an explanation in the docs.

My only concern with this is if the user has provided the sizes in the linear scale, then it makes sense to return the sizes that were "set" instead of the modified ones. But this goes hand in hand with the discussion of what we want markersize to be doing.

There are two things that the original issue/discussion covered: 1. Having markersize (or better) as a more user-friendly kwarg and 2. To provide a way to have linearly scaling sizes. For 2, it makes more sense to me to be able to add an array for markersize than to not because that is taking away functionality that can be provided without much effort. If the consensus is to not allow arrays, then that should not be difficult.

I agree with not allowing both s and markersize at the same time. It does that already, that's the first check.

My tendency is to be pretty conservative when it comes to multiple ways to do the same thing. I'd be very concerned about the Container returning different values for size based on how the axes helper created it. Yes, you have a new flag on the Container, but downstream libraries don't know that, so if anyone is depending on the markersize being in one units or another, they are not going to know to check the markerscale.

I understand that, but wouldn't having the default behaviour such that it doesn't change anything that already exists resolve that issue? And if they are instead using markersize then they would know already what will be returned based on the docs?

Meeting 9/3: Think instead about making markersize an alias for s and have a scaling factor as the kwarg to control all this. Also look into how to make this scaling factor consistent with all the getter/setters.

@chahak13 does this still need discussion or do you have enough guidance?

@jklymak sorry, I should've put a comment in earlier but I've changed markersize to be an alias for s and added a markerscale variable as we discussed last time in the meeting.

Sorry for the label, was looking for something else!

Needs the aliases added to the mypy-stubtest-allowlist.txt file:

Since aliases are dynamically generated, they are not type hinted. Users wanting to use static type checking should use the canonical name (which is a pretty fair tradeoff, and usually results in more readable code, aliases are more helpful for interactive work where using short names or not needing to remember "is there an s on this function?" is more useful)

Adding to the list is just how we silence stubtest, which looks at what is included at runtime.

Ah, the conflict is because since this was opened I actually started dynamically finding aliases so they don't need to be in the mypy-stubtest-allowlist.txt file any more