@nejch Thanks for the review.

Thanks @JohnVillalovos I guess it makes sense to align as we have a huge mix now in the library.

But I think this PR doesn't really replace class/function imports, it replaces from-imports with plain imports. Which I think is not the idea behind Google's styleguide that I think this is trying to follow. See https://google.github.io/styleguide/pyguide.html#22-imports. I think their idea would be from requests import auth -> auth.AuthBase.

It replaces some class/function imports. Like requests.CaseInsensitiveDict, enum.Enum, enum.IntEnum, and pathlib.Path

And the other ones I personally like better seeing the full path.

I'm not sure the full path is always needed when referencing especially with modern IDEs and code intelligence enabled on GitHub/GitLab?

Well as someone who is rocking vim I appreciate it a lot.

So I'm not sure how you want to proceed on this. Are you opposed to all of the changes? Some of the changes? Something else? And I'm fine closing this PR. Not a big deal to not get it merged 😊

Thanks!

Thanks @JohnVillalovos I'd maybe go with a compromise and follow Google's styleguide then, maybe like their example in the decision chapter:

• Use import x for importing packages and modules.
• Use from x import y where x is the package prefix and y is the module name with no prefix.
• ...

For example the module sound.effects.echo may be imported as follows:

from sound.effects import echo
...
echo.EchoFilter(input, output, delay=0.7, atten=4)

Otherwise for example if we wanted to be consistent and add this to our tests as well, we'd have to go with things like assert isinstance(allowlist, gitlab.v4.objects.AllowlistProjectManager) + the same in function signatures everywhere and I think that would get super verbose pretty quick. Maybe best to have modules split logically so the source of modules is clear at the import section already (in the tests I think we already do a pretty good job with this).

Sorry, I'm not too familiar with vim specifics, I was under the impression the language server protocol plugins and neovim would also enable this 🙇

Edit: also I'd try to make sure that those are always done in dedicated PRs like this (maybe we can also add those style changes to rev ignore), so we don't mix them with functional changes.

Be aware that SOME_MODULE.some_function() will perform an attribute lookup compared to calling some_function directly. For hot code sections it is probably best to have a direct reference over indirect through the module.

Be aware that SOME_MODULE.some_function() will perform an attribute lookup compared to calling some_function directly. For hot code sections it is probably best to have a direct reference over indirect through the module.

Realistically the time difference is insignificant in this code between the two. In other Python projects maybe, but with the network operations that happen it drowns out any microsecond optimizations.