The `azure-functions` Python library provides the core programming model for developing serverless functions on Azure Functions. It enables developers to write event-driven code in Python that scales automatically and runs in response to various triggers (e.g., HTTP requests, timer, queue messages). This library, currently at version 2.0.0, is designed for the Python v2 programming model and is typically used with Azure Functions runtime v4.x. It receives updates in alignment with the Azure Functions platform's development cycle, which often includes features, performance improvements, and security patches.
Install & Compatibility
Where this runs
tested against v1.24.0 · pip install
no network on importno background threads
Install × environment matrix
Each cell = how many times install + import succeeded across repeated harness runs. Partial = flaky.
glibc = Debian/Ubuntu slim · musl = Alpine Linux
muslpy 3.10–3.925 runs
installs and imports cleanly · install 0.0s · import 0.540s · 20.8MB
glibcpy 3.10–3.925 runs
installs and imports cleanly · install 1.9s · import 0.433s · 21MB
19MB installed
● package 19MB
Code
Verified usage
Verified import paths — ran on the pinned version, not inferred.
func
✓ import azure.functions as func
The recommended and standard alias for the Azure Functions library.
FunctionApp
✓ app = func.FunctionApp()
Initialize the FunctionApp object, the entry point for defining functions in the v2 programming model.
HttpRequest
✓ req: func.HttpRequest
Type hint for an HTTP request object.
HttpResponse
✓ func.HttpResponse(...)
Class for creating an HTTP response object.
This quickstart demonstrates a simple HTTP-triggered Azure Function using the Python v2 programming model. It shows how to define a function with the `@app.route` decorator, access request parameters (`HttpRequest`), and return an HTTP response (`HttpResponse`). This code is placed in a `function_app.py` file.
import azure.functions as func
import logging
import os
# Instantiate the FunctionApp object
app = func.FunctionApp()
# Define an HTTP trigger function using a decorator
@app.route(route="http_example", methods=["GET", "POST"])
def http_example(req: func.HttpRequest) -> func.HttpResponse:
logging.info('Python HTTP trigger function processed a request.')
# Get name from query parameters or request body
name = req.params.get('name')
if not name:
try:
req_body = req.get_json()
except ValueError:
pass
else:
name = req_body.get('name')
if name:
return func.HttpResponse(f"Hello, {name}. This HTTP triggered function executed successfully.")
else:
return func.HttpResponse(
"Please pass a name on the query string or in the request body for a personalized response.",
status_code=200
)
Debug
Known issues
breakingThe Python v2 programming model (used by `azure-functions` 2.0.0+) introduces significant breaking changes from v1. This shifts from using `function.json` files and a strict 'one function per folder' structure to a Python-first, decorator-based approach. Configuration for triggers and bindings is now directly within Python code.fixRewrite function definitions using decorators (`@app.route`, `@app.timer_trigger`, etc.) in a `function_app.py` file or using blueprints. Remove individual `function.json` files. Refer to the official Azure Functions Python v2 programming model documentation for migration guidance.
affects: All versions using Python v1 programming model when migrating to v2 programming model.
deprecatedAzure Functions Runtime versions 2.x and 3.x are End-of-Life (EOL) and no longer supported. While apps on these runtimes may still function, they will not receive new features, security patches, or performance optimizations.fixMigrate your Function Apps to Azure Functions Runtime version 4.x as soon as possible for full support and access to the latest Python versions (3.10, 3.11, 3.12, 3.13 are supported by runtime 4.x). Ensure your Python code is compatible with the v2 programming model.
affects: Azure Functions Runtime 2.x, 3.x
gotchaCold starts can significantly impact performance on the Consumption Plan. When a function app goes idle, Azure deallocates resources, leading to a delay (cold start) on the next invocation.fixTo mitigate cold starts, consider using a Premium Plan (which keeps instances warm), scheduling periodic 'keep-alive' pings, or keeping your startup code lean by avoiding unnecessary library loads or connections.
affects: All versions on Consumption Plan
gotchaDefault function timeouts on the Consumption Plan are 5 minutes and cannot be changed. Long-running tasks will be terminated.fixFor longer execution times, use a Premium or Dedicated Plan. Alternatively, break down long tasks into smaller, parallelizable chunks, or offload heavy work to Durable Functions or other compute services.
affects: All versions on Consumption Plan
gotchaRepeatedly instantiating network clients (e.g., `HttpClient`, database connections) within a function's execution path can lead to `Socket Exception` errors due to resource exhaustion and inefficient connection management.fixReuse client instances where possible. For Python, this often means creating clients outside the function handler (e.g., as global variables or in a singleton pattern) or utilizing connection pooling where available.
affects: All versions
gotchaFunction App host names (which derive from the app name) have a maximum length of 32 characters. Longer names can lead to host ID collisions, especially when sharing a storage account, which can impede scaling and lease management.fixEnsure your Azure Function App names are 32 characters or less. Avoid sharing a single storage account across multiple Function Apps if possible.
affects: All versions
Errors
Common errors & fixes
ModuleNotFoundError: No module named 'module_name'
A required Python package is not found in the Azure Functions environment, often due to incorrect dependency installation, a platform mismatch (e.g., Windows development, Linux Azure runtime), or an incomplete/incorrect requirements.txt file.
fixEnsure all necessary packages are listed in `requirements.txt`. During deployment, leverage remote build features (e.g., `func azure functionapp publish --build-native-deps` or ensure `SCM_DO_BUILD_DURING_DEPLOYMENT` is set to `true`) to install dependencies on the Azure environment. Verify that the Python version in Azure matches your development environment and is compatible with the packages.
Azure Functions 0 functions loaded
The Azure Functions runtime fails to discover or load the Python functions, typically due to an incompatible runtime or Python worker version, incorrect project structure for the Python v2 model, or unresolved dependency conflicts preventing the worker from starting correctly. This can manifest as 'No HTTP triggers found' in logs.
fixVerify that the project structure adheres to the Python v2 programming model (e.g., `function_app.py` at the root for decorator-based functions). Ensure the Azure Functions runtime is v4.x or higher and the Python worker version is compatible. Check application settings for potential misconfigurations, especially `WEBSITE_RUN_FROM_PACKAGE` and `AzureWebJobsFeatureFlags` (e.g., `EnableWorkerIndexing`).
AZFD0009: Unable to parse host configuration file 'host.json'
The `host.json` file, which configures the Function App's runtime settings, contains invalid JSON syntax or an unsupported configuration. This error can also occur if comments are present in the `host.json` file, as standard JSON does not support comments.
fixCorrect any JSON syntax errors in `host.json` using a JSON linter. Remove all comments from the `host.json` file. Refer to the official Azure Functions `host.json` reference documentation to ensure all configurations are valid and correctly structured.
TypeError: 'NoneType' object is not callable
This error occurs when a variable or object that is expected to be a callable function or method evaluates to `None`. In Azure Functions, this often happens when an HTTP request body is not correctly parsed (e.g., trying to `json.loads()` a byte string with a `b'` prefix from `req.get_body()`) or when a binding input is `None` when a value is expected.
fixFor HTTP POST requests with JSON bodies, use `req.get_json()` to correctly parse the request body. If using `req.get_body()`, ensure to decode it (e.g., `req.get_body().decode('utf-8')`) before attempting `json.loads()`. For binding-related `NoneType` errors, ensure that the upstream service is providing the expected input or add explicit checks for `None` values in your function logic. Audit
Dependencies
azure-functions-workeroptionalThis package is the actual Python language worker that executes Python code within the Azure Functions host. While not a direct `pip` dependency of `azure-functions` itself, it's implicitly required by the Azure Functions runtime to run Python functions.
grpciooptionalOften found in `requirements.txt` for Python Function Apps, as the Python worker uses gRPC for communication with the Functions host.
grpcio-toolsoptionalRelated to gRPC, sometimes listed in `requirements.txt`.
protobufoptionalRelated to gRPC, sometimes listed in `requirements.txt`.