I think this misses the semantic difference betweens inscatter andmarkersize inplot. Inscatter,s is meant to be an array inscatter, whereasmarkersize cannot be an array inplot. 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 thats=array is how to specify arrays for the markersizes, andmarkersize=float is a shortcut forplot-like scaling ifs is not provided. eg,markersize shouldnot accept an array. Ifs andmarkersize 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 wantmarkersize to be doing.

There are two things that the original issue/discussion covered: 1. Havingmarkersize (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 formarkersize 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 boths andmarkersize 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 usingmarkersize then they would know already what will be returned based on the docs?

Meeting 9/3: Think instead about makingmarkersize an alias fors 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 changedmarkersize to be an alias fors and added amarkerscale 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 theydon't need to be in themypy-stubtest-allowlist.txt file any more