Fix type annotation bundle (SAC, TD3, A2C, PPO, base class)

[araffin]

Description

@Rocamonde could you help review that one?
@qgallouedec I found a nice way to make mypy happy (better than assert isinstance()), the only thing is to be careful with instance parameter, never assign anything (otherwise you might get unexpected behavior).

Motivation and Context

• I have raised an issue to propose this change (required for new features and bug fixes)

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation (update in the documentation)

Checklist

• I've read the CONTRIBUTION guide (required)
• I have updated the changelog accordingly (required).
• My change requires a change to the documentation.
• I have updated the tests accordingly (required for a bug fix or a new feature).
• I have updated the documentation accordingly.
• I have opened an associated PR on the SB3-Contrib repository (if necessary)
• I have opened an associated PR on the RL-Zoo3 repository (if necessary)
• I have reformatted the code using make format (required)
• I have checked the codestyle using make check-codestyle and make lint (required)
• I have ensured make pytest and make type both pass. (required)
• I have checked that the documentation builds using make doc (required)

Note: You can run most of the checks using make commit-checks.

Note: we are using a maximum length of 127 characters per line

[araffin]

Fyi, I plan to merge that one and the Gymnasium branch this week (mainly because of all the issues with gym 0.21 and setuptools)

[Rocamonde]

Just took a quick look and LGTM, apologies for the delay. It's a shame there are so many #type ignore's, but I guess some of them are basically impossible to get around.

[araffin]

Just took a quick look and LGTM, apologies for the delay. It's a shame there are so many #type ignore's, but I guess some of them are basically impossible to get around.

thanks and no worry =)

yes, most of them require understanding the code (for instance, that the learn() method is always called after the _setup_model so the replay buffer is never none at that moment) or knowing cast that are valid (float to pytorch tensor for example).

[Rocamonde]

for instance, that the learn() method is always called after the _setup_model so the replay buffer is never none at that moment

One could probably get around some of these by doing asserts

or knowing cast that are valid (float to pytorch tensor for example).

Yeah this seems more inviable if the types of the corresponding libraries don't already support this out of the box.