feat: Expose get_feature_flag_result method in public API

[haacked]

This exposes the existing get_feature_flag_result method that returns a FeatureFlagResult object containing enabled, variant, and payload properties. The payload is automatically deserialized from JSON.

Related to #226 where I suggested I would add this method. Here I go.

[greptile-apps]

PR Summary

Exposes get_feature_flag_result method in the PostHog Python client's public API, providing a structured way to access feature flag data.

• Added type-safe get_feature_flag_result method returning a FeatureFlagResult object with enabled, variant, and auto-deserialized payload properties
• Method implementation follows existing patterns using _proxy for client communication
• Added clear documentation and examples in both __init__.py and example.py showing usage of the new method
• Addresses JSON deserialization issues from #226 while maintaining backward compatibility

_{2 files reviewed, 3 comments
Edit PR Review Bot Settings | Greptile}

[Copilot]

Pull Request Overview

Adds a new public API method to fetch a fully detailed feature flag result and demonstrates its usage in the example script.

• Exposes get_feature_flag_result in posthog/__init__.py
• Documents return object fields in the new method’s docstring
• Shows basic usage in example.py

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
posthog/init.py	Added get_feature_flag_result wrapper and docstring
example.py	Added sample code calling the new get_feature_flag_result

Comments suppressed due to low confidence (4)

posthog/init.py:356

• [nitpick] For consistency with get_feature_flag_payload, consider adding an optional match_value parameter (and passing it through _proxy) if the underlying client supports it, or document why it’s intentionally omitted.

    key,

posthog/init.py:355

• This new public API method should have corresponding unit tests to verify behavior under various flag states (enabled/disabled, with/without variants/payload).

def get_feature_flag_result(

example.py:64

• [nitpick] The example prints enabled, variant, and payload but omits key and reason, which are part of FeatureFlagResult. Consider showing all fields to fully demonstrate the API.

result = posthog.get_feature_flag_result("beta-feature", "distinct_id")

posthog/init.py:355

• The return type hint FeatureFlagResult is referenced but not imported in this module. Please add the appropriate import (e.g. from posthog import FeatureFlagResult) so the annotation resolves correctly.

def get_feature_flag_result(

[dmarticus]

this seems reasonable; but didn't we already ship get_feature_flag_result in posthog-python 4.0.0? How is this significantly different?

[haacked]

this seems reasonable; but didn't we already ship get_feature_flag_result in posthog-python 4.0.0? How is this significantly different?

Oh geez. I was working with outdated info.

However, I think my changes to replace default {} values with None in function arguments should be done.

The issue with mutable default parameters (like {} or []) is that they are created once when the function is defined, not each time the function is called. This can lead to unexpected behavior where the default object is shared across all function calls. In our code, this bug likely wouldn't manifest in practice (since the parameters are passed through to other functions rather than being modified), it's still a code smell.

I can fix this PR to solely address that.

[haacked]

Oh wait a minute. We did add get_feature_flag_result in 4.0.0, but we never exposed it publicly. We need to do that in __init__.py correct?

[dmarticus]

@haacked is this still relevant? Don't we already expose this method?

[haacked]

@haacked is this still relevant? Don't we already expose this method?

It is still revelant. This PR exports get_feature_flag_result publicly by adding the function to __init__.py so users can call posthog.get_feature_flag_result() directly.