This is a lot more verbose than #3080 but I think it is a better solution with less hacks and # type: ignore[override]

I did not make a RESTObjectList a generic or add overloads to list methods here to keep this PR more focused on RESTManager but I want to do a follow-up PR in the future.

There was a PR #2067 in the past by @vectro but it looks like there the tox test were not passing? I ran tox on my machine and it seems to be passing everything.

Codecov Report

Attention: Patch coverage is 99.17355% with 3 lines in your changes missing coverage. Please review.

Project coverage is 97.25%. Comparing base (46dfc50) to head (40eb4d0).
Report is 1 commits behind head on main.

@@            Coverage Diff             @@
##             main    #3083      +/-   ##
==========================================
- Coverage   97.28%   97.25%   -0.04%     
==========================================
  Files          97       97              
  Lines        6006     5932      -74     
==========================================
- Hits         5843     5769      -74     
  Misses        163      163              

I also have a 3rd implementation there I made RESTManager a Protocol as described in this comment

#2228 (comment)

It allows mixins to be "mixins" instead of subclasses using def method(sefl: RESTManager).

However, it quickly ran in to several issues:

1. Not possible to mixin attributes as self would only have attributes from RESTManager. You can move all mixins attributes to RESTManager or define new protocols that subclass the RESTManager but it pretty ugly. It seems like the ListMixins are always mixed with RESTManager so using subclasses instead of mixins is a cleaner solution.
2. Not possible to issubclass(some_class, RESTManager). There is something about Protocols which prevent subclass checks.

There is also an idea about SidekiqManager. Set its _obj_cls to RESTObject and _path to "". This way it is still a RESTManager subclass and still defines required attributes.

Thanks a lot for all the work here @igorp-collabora. Technically your 3rd solution would be really clean IMO and would be nice to have proper mixins and IIRC that is also how I imagined protocols last I played around with this. But, I guess they are not real mixins from mypy's perspective anyway whenever we rely on specific instance attributes 😁

The PRs are actually quite reasonable to review but the main chunk is the removal of the manual get overrides, which makes everything a huge change. So I'd be open to reviewing that separately if that works for you (1 PR to add native typing, which should already solve it for other methods, and another for removing the custom overrides and test). Let me know if that works. It would be slightly easier to focus on the details then 🙇

I like the idea of defining a path on the SidekiqManager for consistent typing. We can actually make it /sidekiq and then use that for the methods using {self.path}/endpoint, which we already do in many cases:

1 PR to add native typing, which should already solve it for other methods, and another for removing the custom overrides and test

I can do that but I want to check if keeping the def get around would cause the type checking failure. This would make the commit non-atomic and I am not sure if you are ok with it. Alternatively the get removal commit can be first and then the generic commit after.

I like the idea of defining a path on the SidekiqManager for consistent typing. We can actually make it /sidekiq and then use that for the methods using {self.path}/endpoint, which we already do in many cases:

I will add this.

@igorp-collabora separate commits but the same PR would also work for me if that's ok! 🙇

Things should be a bit calmer now after the backlog merge and release(s) so hopefully less conflict/rebasing here 😀

I rebased the PR and updated all the new RESTManager classes added.

I will split the def get removals to the separate commit tomorrow. I think I will place the get removal commit first followed by adding a generic type hints. The reverse order requires modifying all the get requests anyway because the redundant cast would need to be removed.

@nejch I think this PR is in good enough form. The only possible change I might add is splitting the RESTManager in to 2 classes. (the parent one with just _path and one that adds _obj_cls)

I think there is also room to add a new unit test that verifies that _obj_cls and _path are properly set for subclasses. Since they are no longer defined using @abstractmethod @property the type checkers will not verify that they properly defined.

If you think this PR is good enough. I can start working on splitting the def get removal to a separate commit.

@nejch I'm not sure if I will have time to review this in the near future. I trust your reviews though 👍🤓

@nejch After this gets merged, I will propose a PR to update the black config so that it will do the equivalent of --skip-magic-trailing-comma.

Basically add to pyproject.toml:

[tool.black]
skip-magic-trailing-comma = true

I made a separate PR to remove the get methods: #3110

Once it is merged I will rebase this PR. It should shrink by quite a bit after that.

Rebase done.

The line diff is now +748 -536. Before it was +765 -1485.

I think there shouldn't be any difference with the Get methods because of redefined get methods had the same effective type hints, however, other mixins might make certain code no longer pass type checking. Biggest changes that might impact type checking:

1. RESTManager.path is now always str. This means checking for None is no longer required. I don't think mypy checks for unreachable code but there might be some redundant casts.
2. ListMixin now returns a list of concrete subclasses as a part of union. I also want to make the RESTObjectList generic in the future and add overloads just like download methods.
3. CreateMixin returns concrete subclass.
4. SetMixin returns concrete subclass.

Also it'll be daytime in Oregon by then in case @JohnVillalovos has any objections 😁

No objections from me. Sorry I haven't had the time to review this yet. I trust your decision @nejch

Once this gets merged I plan on adding more typing changes:

• Make RESTObjectList generic to type hint iterated object class
• Add overloads to the list methods so that only RESTObjectList or list gets returned based on the arguments. This can also make skipping get_all have a deprecation warning then type checked.

Once this gets merged I plan on adding more typing changes:

* Make `RESTObjectList` generic to type hint iterated object class

* Add overloads to the list methods so that only `RESTObjectList` or `list` gets returned based on the arguments. This can also make skipping `get_all` have a deprecation warning then type checked.

Thanks @igorp-collabora. I checked out python-gitlab from your branch in a few of our projects and generally it all looks great but indeed the list methods are now failing checks where we previously had workarounds for the union types. I think just for clarity I'd make that a breaking change, but we can do this in a follow-up since the list() return types will change with the incoming PRs again.

I'll go ahead and merge this for now!