Not sure I fully understood the transition path, but I think that the default value should not be changed to a float at this stage as that will trigger warnings for the default which is a bit confusing (and leads to errors).

Probably, the way is to type it as both int and float for now and keep the int default?

Not sure I fully understood the transition path, but I think that the default value should not be changed to a float at this stage as that will trigger warnings for the default which is a bit confusing (and leads to errors).

Probably, the way is to type it as both int and float for now and keep the int default?

Thanks for the feedback!
The default value as float doesn't trigger warnings. Just in case I changed the test to try that. First test takes the case were int(density) != density

And the second one, passes a float and shouldn get a warning (could be any float 2.0~2.5)

Is that what you meant?

I think the check as implemented will not warn for floating inputs that are integers asint(6.0) == 6.0 evaluates to true and is rather unambiguously represented as a float.

That said, i'm unclear why additional casts were added here, as they seem a) likely to be unintentionally missed when doing the behavior change (a comment would help that point) and b) likely to cause inputs that wewant to warn tonot warn.

I think that the cast to int should be retained inget_path (but after the warning). and not distributed to all of the calling functions. this will keep the code change that is needed on expiry close to the warning.

That said, there may be some patterns (such as circles/stars/etc) thatare required to be integers, so maybe we should think about what the code looks like after expiry here... there may be some that can be continuously changed (lines feels like they should be able to) and some that are necessarily discrete (circles, maybe).

I'm going to play around with the density uncast and see what breaks.