Nejc Habjan

Thanks for the PR @gagallo7! I was under the impression we were solving this for specific endpoints that expect this format using our ArrayAttribute (https://github.com/python-gitlab/python-gitlab/blob/main/gitlab/types.py#L72-L82). Has GitLab switched to using...

This change makes a lot of sense, thanks @ptalbert. For context, we didn't use to have `_repr_attr` so this may have some historical reason but I'm not entirely sure at...

@ptalbert thanks. In some cases `name` is intentional, for example when there is no `id` returned (like for branches). So if there are other cases where this should not be...

That's a cool idea @gdubicki! Even in my team we often end up creating something like a `list_kwargs` that we pass to all list methods. Having this natively would be...

@Ncoder2 I'm a bit surprised as we use python-gitlab for multiple long-running services that iterate over hundreds of thousands of projects and users on a weekly basis, and haven't seen...

@GeorgeH87 generally all python-gitlab objects lack auto-completion in IDEs, because the attributes are dynamically populated based on the server response, which could change depending on GitLab versions, arguments provided, and...

Ah nice catch @GeorgeH87, I guess we kind of depend on that then. If we're using it in the custom methods then we should add it.

Thanks for the PR @valentingregoire! AFAIK this was an intentional change at some point to enforce namespacing the constants, as the number of package-level exports kept growing. Or am I...

> @nejch, @JohnVillalovos, I see that this could be the intention, indeed. Would it then make sense to add the `const` module to the root `__init__` [here](https://github.com/python-gitlab/python-gitlab/blob/main/gitlab/__init__.py#L36)? Else it is...

This might be the case, as we were probably applying typing across dozens of endpoints at the time. If we consistently get `bytes` regardless of the `streamed` argument we can...