I would personally prefer if we could define things in one place and avoid adding too much duplication, and we would also not need to create custom tests to enforce it (and just test_create_managers instead).

Using__annotations__ for this would be convenient although a little magic. But the syntax is so clean it might be less cryptic to new contributors who don't care how managers are created. It could be combined with a simple check that it's a real manager, similar to what we already do for the CLIhttps://github.com/python-gitlab/python-gitlab/blob/master/gitlab/cli.py#L92-L96

# namespace = gitlab.v4.objectsmanagers= [manformaninnamespace.__dict__ifman.endswith("Manager")]ifmanagernotinmanagers:continue...

(something prettier than this I guess, but you get the idea :) )

When I look at this in your PR:

classProjectDeployment(SaveMixin,RESTObject):mergerequests:ProjectDeploymentMergeRequestManager_managers= (("mergerequests","ProjectDeploymentMergeRequestManager"),)

The new syntax is just so nice and reminds me of dataclasses, and the old one starts to look ugly and I'd just remove it 😸 On the other hand I don't want to force something that's too magic,@max-wittig what's your opinion here?

I would personally prefer if we could define things in one place and avoid adding too much duplication, and we would also not need to create custom tests to enforce it (and just test_create_managers instead).

Agreed.

I am going to update the PR to just use annotations. We can then decide which one we like better.

I do like the annotation only one.

I kind of really like this as well, despite the magic so I'll approve it (just needs a rebase and I just have a style question) 😀 When you think about it, the dynamic manager creation has always been a bit magic and considering the stuff we already do in:

... this is not really outrageous compared to that :) But would like also@max-wittig to take a quick look.