@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. Seehttps://google.github.io/styleguide/pyguide.html#22-imports. I think their idea would befrom requests import auth ->auth.AuthBase.

It replaces some class/function imports. Likerequests.CaseInsensitiveDict,enum.Enum,enum.IntEnum, andpathlib.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 rockingvim 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 thedecision 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 modulesound.effects.echo may be imported as follows:

fromsound.effectsimportecho...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 likeassert 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 thatSOME_MODULE.some_function() will perform an attribute lookup compared to callingsome_function directly. For hot code sections it is probably best to have a direct reference over indirect through the module.

Be aware thatSOME_MODULE.some_function() will perform an attribute lookup compared to callingsome_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.

This Pull Request (PR) was marked stale because it has been open 90 days with no activity. Please remove the stale label or comment on this PR. Otherwise, it will be closed in 15 days.