Python V1 Release

[toddbaert]

I'd like us to consider releasing a v1.0 of this SDK. After a cursory inspection, I think we've implemented the spec up the most recent release. In addition to that, the usage as reported by PyPI is comparable to our other v1.0+ SDKs.

That leaves us with a few tasks:

• Audit the SDK to ensure we are spec compliant
• Fix any outstanding bugs that would significantly blemish v1.0
• Remove any deprecations we don't want to carry forward into v1.0
• Make any last minute breaking changes to function/type names etc, for ergonomic improvements

Please weigh in with your vote of confidence (or not). Also feel free to mention or create any issues that you believe are blockers.

[federicobond]

I think we are almost ready to ship. I've opened an issue to remove the deprecated openfeature.provider.provider module which is the only remaining deprecation we are still carrying.

One last thing I’d like to revisit before shipping V1 is the from openfeature import api entrypoint.

api is a very common identifier in real projects (routers/clients), so it collides with existing conventions. For example in Django Ninja (from their docs):

from ninja import NinjaAPI

api = NinjaAPI()

If someone also does:

from openfeature import api

client = api.get_client()

They either end up aliasing (from openfeature import api as openfeature) or, worse, accidentally shadowing one api with the other.

The OpenTelemetry’s Python API, for example, avoids this by exporting a domain-specific module name:

from opentelemetry import trace

tracer = trace.get_tracer(__name__)

What do you think about renaming the module to something more specific/collision-resistant (e.g. flags or feature_flags) and keep openfeature.api as a backward-compatible alias for now?

from openfeature import feature_flags

client = feature_flags.get_client()

If this feels like bikeshedding, I’m happy to let it go. I just wanted to raise it before v1 locks it in.

cc/ @gruebel