Review public APIs (make sure they are "Pythonic")

[toddbaert]

We know some of the internals of the SDK are a bit "Java-y"; these can be refactored later. However, before a 1.0 we need to make sure the public APIs are idiomatic to ensure we don't regret or design choices post-1.0.

Definition of done:

• Review SDK, issues created for public API changes if necessary.

[federicobond]

The biggest issue is see here is that the module structure is too deeply nested. I have no hard data on this, but in my experience one should be able to import 80-90% of the code that is needed for most use cases from open_feature.<xyz> and only very specialized functionality from open_feature.<xyz>.<abc>

Some examples:

Original import	Proposed import
from open_feature.hooks.hook import Hook	from open_feature.hooks import Hook
from open_feature.provider.no_op_provider import NoOpProvider	from open_feature.provider import NoOpProvider

If needed, additional internal structure can be handled via underscore-prefixed modules to signal that you should not import these directly.

The other Java-ism I am seeing is the open_feature.open_feature_<x> module naming, closely following the main class name in each case. A more Pythonic approach would be to rename them to open_feature.client and open_feature.api.

[toddbaert]

@federicobond the above sounds right to me.

Because this is an issue of style, I'd love to hear some concensus from others. cc @hlipsig @matthewelwell @jamescarr @tcarrio @open-feature/sdk-python-approvers @open-feature/sdk-python-maintainers

[hlipsig]

Agreed.

[beeme1mr]

Sounds like a nice change to me 👍.

[matthewelwell]

Yep, agree.

[gruebel]

@federicobond should we close this?

[federicobond]

Yes, I find no more directly actionable issues here.