Python
The Unleash Python SDK lets you evaluate feature flags in Python applications. It connects to Unleash or Unleash Edge to fetch flag configurations and evaluates them locally against an Unleash context.
You can use this SDK with Unleash Enterprise or Unleash Open Source.
For an overview of how Unleash SDKs work, including offline behavior, feature compatibility across SDKs, and default refresh and metrics intervals, refer to the SDK overview.
Installation
Initialization
You must initialize the SDK before you use it. Note that until the SDK has synchronized with the API, all features will evaluate to false unless
you have a bootstrapped configuration or you use fallbacks.
Check flags
Once the SDK is initialized, you can evaluate toggles using the is_enabled or get_variant methods.
Stop the client
If your program no longer needs the SDK, you can call destroy(), which shuts down the SDK and flushes any pending metrics to Unleash.
Unleash context
Both the is_enabled and get_variant functions support Unleash contexts as the second parameter.
The context values can be any type that has a __str__ implementation. Types that are explicitly supported are:
- Numerics
- Strings
- Dates
- UUIDs
Gradual rollout strategies require you to pass either a userId or a sessionId for stickiness to work correctly.
Fallback function
You can specify a fallback function for cases where the client doesn’t recognize the toggle by using the fallback_function keyword argument:
The fallback function must accept the feature name and context as positional arguments in that order.
The client will evaluate the fallback function if the feature flag is not found or an exception occurs when calling the is_enabled() method.
Configuration options
The UnleashClient constructor supports the following configuration options:
Bootstrap
By default, the Python SDK fetches your feature flags from the Unleash API at startup. If you want to make your SDK more resilient (e.g., during network outages), you can bootstrap the client with a local or remote toggle config.
How it works:
-
Use a FileCache (or your own BaseCache implementation).
-
Pre-seed it with feature flags using bootstrap_from_dict, bootstrap_from_file, or bootstrap_from_url.
-
Pass your cache to the UnleashClient on startup.
The default FileCache has built-in methods for bootstrapping from a dictionary, file, or URL.
Dictionary
File
URL
Custom strategies
The Python SDK lets you define custom activation strategies if the built-in ones don’t cover your needs. This gives you more fine grained control over how your features evaluate.
A custom strategy is just a class that implements an apply method.
Once you’ve defined your strategy, register it when you initialize the client. The key must match the strategy name in Unleash exactly.
Events
The Python SDK lets you tap into its behavior through impression data and lifecycle events. Provide an event_callback function when you initialize the client.
The SDK does not include a built-in event bus — you’ll need to provide your own. The examples below use Blinker to send signals.
The callback receives a single UnleashEvent. The SDK emits the following event types:
- Impression events: emitted when
is_enabled()orget_variant()is called for a flag with impression data enabled. - READY: triggered once when the SDK first loads feature flags from the Unleash server or a local backup.
- FETCHED: triggered when a new version of feature flags is pulled from the server (not on 304 Not Modified). Includes a
featuresproperty with all flags returned by that fetch.
Impression callbacks run in-process — keep them fast to avoid blocking your app.
Custom cache
By default, the Python SDK stores feature flags in an on-disk cache using fcache. If you need a different storage backend, for example, Redis, memory-only, or a custom database, you can provide your own cache implementation.
Below is an example custom CustomCache using fcache under the hood.
Pass your cache instance to the client with the cache argument:
Running in multi-process setups
The Python SDK runs a background thread to keep feature flags in sync with the Unleash server. Some runtime environments, like WSGI servers and Celery workers, need extra setup to make sure the SDK works correctly.
WSGI
When using WSGI servers (e.g., for Flask or Django apps), be aware that:
- Many WSGI setups disable threading by default. The SDK needs threads to poll for updates in the background.
- Make sure to set
enable-threadsin your WSGI config.
When running under uWSGI with multiple processes (using the --processes option), you may need to enable the lazy-apps option. This ensures each process gets a fresh SDK instance.
See The Art of Graceful Reloading for more details.
Celery
When using the SDK in Celery tasks, make sure you initialize it inside the worker_process_init event. Otherwise, the worker may run but won’t poll for feature flag updates.
Migrating to v6
If you use custom strategies or access the features property on the Unleash Client, read the complete v6 migration guide before upgrading.