Note: I'm feeling less and less comfortable with the master branch being deeply modified (with the new _* default funcs). It doesn't change anything for the end user and prevents us from quickly bringing a fix to users or simply fix a dependency version. But we're too far in the changes now
Hey @satyaog, @breuleux thanks for the reviews, sorry I didn't reply earlier.
I just want to emphasize something: This PR doesn't change anything about the behaviour of the code. The type hints that are added describe the types and signatures of the methods as they are currently.
There's a very slight exception with these these _* default functions, which are there for typing purposes and don't have any effect on the runtime. I'm okay with removing them and making the signatures explicit, but this would represent a much bigger change in the implementation of these methods than to just add type annotations to the *args and **kwargs and adding these unused keyword parameters for the wrapped functions.
As for the unit tests, I guess having meh integration tests would be much better than having no tests at all. I think making changes to the master branch to introduce tests actually really aligns with your point: We don't want breaking changes to join master. The problem is, until we add some tests, we have no idea what's breaking or not. We need to take a first jump at some point.
Hey @satyaog, @breuleux thanks for the reviews, sorry I didn't reply earlier.
I just want to emphasize something: This PR doesn't change anything about the behaviour of the code. The type hints that are added describe the types and signatures of the methods as they are currently.
_*
default functions, which are there for typing purposes and don't have any effect on the runtime. I'm okay with removing them and making the signatures explicit, but this would represent a much bigger change in the implementation of these methods than to just add type annotations to the *args and **kwargs and adding these unused keyword parameters for the wrapped functions.As for the unit tests, I guess having meh integration tests would be much better than having no tests at all. I think making changes to the
master
branch to introduce tests actually really aligns with your point: We don't want breaking changes to join master. The problem is, until we add some tests, we have no idea what's breaking or not. We need to take a first jump at some point.