Allow List[int] or int but not float or str

[alexrudd2]

See #1363.

This does not fully close that issue, but at least corrects the type hints.

[alexrudd2]

@janiversen
I'm going to leave this here to not interrupt your further work with the mixin/base.

[janiversen]

@alexrudd2 this one can be merged, when you want, just change it to "ready for review", I solved a couple of issues.

[janiversen]

While at it, I corrected mixin.py, so it gets a green light from mypy.

[alexrudd2]

While at it, I corrected mixin.py, so it gets a green light from mypy.

Ok, good. I tried other options, but the only two that worked were
(1) removing the return type from execute() => leaves the API untyped
(2) broadening the return types to ModbusResponse (which you've done)

[alexrudd2]

Things brings it down from 150 to 5 mypy errors, all of them in base.py i think. 🎉

[janiversen]

client/base.py is up for a major change, so it is not really worth while investing too much time there.

I know mypy allows a list of files not to consider in the configuration, using that would allow us to add mypy to CI right now, and then you can reduce the list as you go along.

[janiversen]

And just for the record, the old return scope was far too limited, because there are something like 5 classes that can be returned all included in ModbusResponse.

Actually using ModbusResponse, might have a positive effect, because users see that all calls return the same struct (with a field not being filled depending on the request).

[alexrudd2]

client/base.py is up for a major change, so it is not really worth while investing too much time there.

I know mypy allows a list of files not to consider in the configuration, using that would allow us to add mypy to CI right now, and then you can reduce the list as you go along.

Yes, it's why I've not bothered.

I will see if I can get things ready for CI (and enable py.typed). In fact this week, I already tried running mypy on some of my applications which use mypy as a library and it appeared to work.