Merge pull request #303962 from MicrosoftDocs/main

Auto Publish – main to live - 2025-08-07 11:00 UTC

Author: learn-build-service-prod[bot]

articles/azure-functions/TOC.yml

@@ -444,6 +444,9 @@
         - name: Developer reference guide
           displayName: python
           href: functions-reference-python.md
+        - name: Updates for Python 3.13+
+          displayName: python
+          href: python-313-changes.md
         - name: Programming models
           displayName: python
           href: functions-reference-python.md#programming-model

articles/azure-functions/functions-reference-python.md

@@ -2,7 +2,7 @@
 title: Python developer reference for Azure Functions
 description: Understand how to develop, validate, and deploy your Python code projects to Azure Functions using the Python library for Azure Functions.
 ms.topic: article
-ms.date: 12/29/2024
+ms.date: 07/31/2025
 ms.devlang: python
 ms.custom:
   - devx-track-python
@@ -20,7 +20,7 @@ This guide is an introduction to developing Azure Functions by using Python. The
 > This article supports both the v1 and v2 programming model for Python in Azure Functions.
 > The Python v1 model uses a *functions.json* file to define functions, and the new v2 model lets you instead use a decorator-based approach. This new approach results in a simpler file structure, and it's more code-centric. Choose the **v2** selector at the top of the article to learn about this new programming model. 
 
-As a Python developer, you might also be interested in these topics:
+As a Python developer, you might also be interested in these articles:
 
 ## [Get started](#tab/get-started)
 
@@ -536,7 +536,7 @@ For select triggers and bindings, you can work with data types implemented by th
 
 ## HTTP streams
 
-HTTP streams lets you accept and return data from your HTTP endpoints using FastAPI request and response APIs enabled in your functions. These APIs lets the host process large data in HTTP messages as chunks instead of reading an entire message into memory. 
+HTTP streams is a feature that lets you accept and return data from your HTTP endpoints using FastAPI request and response APIs enabled in your functions. These APIs lets the host process large data in HTTP messages as chunks instead of reading an entire message into memory. 
 
 This feature makes it possible to handle large data stream, OpenAI integrations, deliver dynamic content, and support other core HTTP scenarios requiring real-time interactions over HTTP. You can also use FastAPI response types with HTTP streams. Without HTTP streams, the size of your HTTP requests and responses are limited by memory restrictions that can be encountered when processing entire message payloads all in memory. 
 
@@ -1077,13 +1077,18 @@ For local development, application settings are [maintained in the *local.settin
 
 Azure Functions supports the following Python versions:
 
-| Functions version | Python\* versions |
-| ----- | :-----: |
-| 4.x | 3.13 (Preview)<br/>3.12<br/>3.11<br/>3.10<br/>|
-> [!IMPORTANT]  
-> Python 3.13 is currently supported on the Flex Consumption, Premium, and Dedicated plans. Python 3.13 support on the Consumption plan is pending.
+| Python<sup>1</sup> versions | Support level |
+| ----- | ----- |
+| 3.13 | Preview<sup>2</sup> |
+| 3.12 | Generally available (GA) |
+| 3.11 | GA | 
+| 3.10 | GA |
+
+1. Official Python distributions
+2. Python 3.13 support is in preview and currently isn't supported by the [Consumption plan](./consumption-plan.md). 
 
-\* Official Python distributions
+> [!IMPORTANT]  
+> Python 3.13 support introduces some improvements and a few breaking changes. For more information, see [Python 3.13+ in Azure Functions](./python-313-changes.md).
 
 To request a specific Python version when you create your function app in Azure, use the `--runtime-version` option of the [`az functionapp create`](/cli/azure/functionapp#az-functionapp-create) command. The Functions runtime version is set by the `--functions-version` option. The Python version is set when the function app is created, and it can't be changed for apps running in a Consumption plan.
 
@@ -1362,7 +1367,7 @@ def http_trigger(req: func.HttpRequest) -> func.HttpResponse:
 print(http_trigger(None))
 ```
 
-Note that with this approach, no additional package or setup is required. The function can be tested by calling `python function_app.py`, and it results in `Hello, World!` output in the terminal.
+With this approach, extra packages and configuration isn't required. The function can be tested by calling `python function_app.py`, and it results in `Hello, World!` output in the terminal.
 
 > [!NOTE]
 > Durable Functions require special syntax for unit testing. For more information, refer to [Unit Testing Durable Functions in Python](durable/durable-functions-unit-testing-python.md)
@@ -1374,7 +1379,7 @@ Note that with this approach, no additional package or setup is required. The fu
 The `tempfile.gettempdir()` method returns a temporary folder, which on Linux is */tmp*. Your application can use this directory to store temporary files that are generated and used by your functions when they're running.
 
 > [!IMPORTANT]
-> Files written to the temporary directory aren't guaranteed to persist across invocations. During scale out, temporary files aren't shared between instances.
+> Files written to the temporary directory aren't guaranteed to persist across invocations. During scale-out, temporary files aren't shared between instances.
 
 The following example creates a named temporary file in the temporary directory (*/tmp*):
 
@@ -1418,13 +1423,13 @@ The Azure Functions Python worker requires a specific set of libraries. You can
 > If your function app's *requirements.txt* file contains an `azure-functions-worker` entry, remove it. The functions worker is automatically managed by the Azure Functions platform, and we regularly update it with new features and bug fixes. Manually installing an old version of worker in the *requirements.txt* file might cause unexpected issues.
 
 > [!NOTE]
->  If your package contains certain libraries that might collide with worker's dependencies (for example, protobuf, tensorflow, or grpcio), configure [`PYTHON_ISOLATE_WORKER_DEPENDENCIES`](functions-app-settings.md#python_isolate_worker_dependencies) to `1` in app settings to prevent your application from referring to worker's dependencies.
+>  If your package contains certain libraries that might collide with worker's dependencies (for example, protobuf, TensorFlow, or grpcio), configure [`PYTHON_ISOLATE_WORKER_DEPENDENCIES`](functions-app-settings.md#python_isolate_worker_dependencies) to `1` in app settings to prevent your application from referring to worker's dependencies.
 
 ### The Azure Functions Python library
 
 Every Python worker update includes a new version of the [Azure Functions Python library (azure.functions)](https://github.com/Azure/azure-functions-python-library). This approach makes it easier to continuously update your Python function apps, because each update is backwards-compatible. For a list of releases of this library, go to [azure-functions PyPi](https://pypi.org/project/azure-functions/#history).
 
-The runtime library version is fixed by Azure, and it can't be overridden by *requirements.txt*. The `azure-functions` entry in *requirements.txt* is only for linting and customer awareness.
+The runtime library version is set by Azure, and it can't be overridden by *requirements.txt*. The `azure-functions` entry in *requirements.txt* is only for linting and customer awareness.
 
 Use the following code to track the actual version of the Python functions library in your runtime:
 
@@ -1468,7 +1473,7 @@ You can use a Python worker extension library in your Python functions by doing
 1. Configure the extension instance, if needed. Configuration requirements should be called out in the extension's documentation. 
 
 > [!IMPORTANT]
-> Third-party Python worker extension libraries aren't supported or warrantied by Microsoft. You must make sure that any extensions that you use in your function app is trustworthy, and you bear the full risk of using a malicious or poorly written extension. 
+> Third-party Python worker extension libraries aren't supported or warranted by Microsoft. You must make sure that any extensions that you use in your function app is trustworthy, and you bear the full risk of using a malicious or poorly written extension. 
 
 Third-parties should provide specific documentation on how to install and consume their extensions in your function app. For a basic example of how to consume an extension, see [Consuming your extension](develop-python-worker-extensions.md#consume-your-extension-locally). 
 

articles/azure-functions/python-313-changes.md

@@ -0,0 +1,76 @@
+---
+title: Updates for Python 3.13+ in Azure Functions 
+description: Understand key changes, new features, and compatibility considerations for running Azure Functions with Python 3.13 and later versions.
+ms.topic: concept-article
+ms.date: 07/24/2025
+ms.devlang: python
+ms.custom: devx-track-python, py-fresh-zinc
+---
+
+# Changes and guidance for Python 3.13+ in Azure Functions
+
+This article outlines important Python feature updates introduced by Azure Functions starting with Python 3.13. These changes include runtime version management, performance enhancements, and several removed features.
+
+## Python runtime version control 
+
+Starting with Python 3.13, Functions introduces runtime version control, a new opt-in feature that lets you target specific versions of the Functions Python runtime used by your app.
+
+Without version control enabled, your app continues to run on a default version of the Python runtime, which is managed by Functions. You must modify your *requirements.txt* file to instead request the latest released version, a prereleased version, or to be able to pin your app to a specific version of the Python runtime. 
+
+You enable runtime version control by adding a reference to the Python runtime package to your *requirements.txt* file, where the value assigned to the package determines the runtime version used.
+ 
+The specific reference you add in *requirements.txt* depends on your Python programming model, which can be one of these values:
+
+| Model version |  Package name |
+| ----- | ----- |
+| [v2](functions-reference-python.md?pivots=python-mode-decorators#programming-model) | `azure-functions-runtime` | 
+| [v1](functions-reference-python.md?pivots=python-mode-configuration#programming-model)  | `azure-functions-runtime-v1` |
+
+This table indicates the versioning behavior based on the version value of this setting in your *requirements.txt* file:
+
+| Version | Example | Behavior |
+| --- | ---- | ---- |
+| No value set | `azure-functions-runtime` | Your Python 3.13+ app runs on the latest available version of the Functions Python runtime. This option is best for staying current with platform improvements and features, since your app automatically receives the latest stable runtime updates. |
+| Pinned to a specific version | `azure-functions-runtime==1.2.0` | Your Python 3.13+ app stays on the pinned runtime version and doesn't receive automatic updates. You must instead manually update your pinned version to take advantage of new features, fixes, and improvements in the runtime. Pinning is recommended for critical production workloads where stability and predictability are essential. Pinning also lets you test your app on prereleased runtime versions during development. |
+| No package reference | n/a | By not setting the `azure-functions-runtime`, your Python 3.13+ app runs on a default version of the Python runtime that is behind the latest released version. Updates are made periodically by Functions. This option ensures stability and broad compatibility. However, access to the newest features and fixes are delayed until the default version is updated. | 
+
+Keep these considerations in mind when using runtime version control with your Python 3.13+ app:
+
+- Avoid pinning any production app to prerelease (alpha, beta, or dev) runtime versions.
+- Review [Python runtime release notes](https://github.com/Azure/azure-functions-python-worker/releases) regularly to be aware of changes that are being applied to your app's Python runtime or to determine when to update a pinned version. 
+
+
+## Other changes and improvements introduced in Python 3.13
+
+Python 3.13 introduces several enhancements to Functions that improve performance and reliability and otherwise affect runtime behaviors:
+
+### Dependency isolation now enabled by default
+
+Your apps can now benefit from full *dependency isolation*, which means that when your app includes a dependency that's also used by the Python worker, such as `azure-functions` or `grpcio`, your app can use its own version even though the Python runtime uses a different version internally.
+
+This isolation prevents version conflicts and improves compatibility with custom packages.
+
+### Improved cold start performance
+
+Python 3.13 provides a measurable reduction in [cold start time](./event-driven-scaling.md#cold-start) compared to Python 3.11, which results in faster app startup.
+
+### Faster JSON handling with `Orjson` support
+
+Functions now supports the automatic use of `Orjson`, a high-performance JSON library written in Rust. When `Orjson` is included in your app’s dependencies, the runtime automatically uses it for JSON serialization and deserialization without you having to make any changes in your code.
+
+Using `Orjson` can provide both lower latency and higher throughput for JSON-heavy workloads, such as HTTP API calls and event processing. To ensure backward compatibility, the standard `json` library is used when `Orjson` isn't available.
+
+### Simplified opt-in for HTTP streaming
+
+- The [HTTP Streaming](./functions-bindings-http-webhook-trigger.md?tabs=python-v2&pivots=programming-language-python#http-streams-1) feature is now available without requiring any changes to your app setting or other configurations. While you must still opt in at the function level, you no longer need to add the `PYTHON_ENABLE_INIT_INDEXING` setting to use the feature.
+
+## Feature support removed in Python
+
+These features are no longer supported by Functions when using Python 3.13 and later versions:
+
+- **[Worker Extensions](./functions-reference-python.md#python-worker-extensions)**: Custom worker extensions aren't compatible with the Python 3.13+ runtime. If your app rely on these extensions, you must reevaluate or migrate to using supported alternatives.
+- **[Shared Memory](./functions-reference-python.md#shared-memory)**: The shared memory feature used for large payload optimization isn't available starting with Python 3.13. By default, all communication now uses gRPC-based messaging.
+
+## Related article
+
++ [Azure Functions Python developer guide](functions-reference-python.md)

articles/frontdoor/TOC.yml

@@ -177,6 +177,10 @@
         href: ../cdn/cdn-change-provider.md?toc=/azure/frontdoor/toc.json
       - name: Custom domain
         href: migrate-cdn-to-front-door.md
+    - name: AFD/CDN Classic migration FAQ
+      href: migration-faq.md
+    - name: Post migration Dev-Ops experience
+      href: post-migration-dev-ops-experience.md
   - name: Upgrades
     items:
     - name: Upgrade from Standard to Premium tier - Portal

articles/frontdoor/migration-faq.md

@@ -0,0 +1,60 @@
+---
+title: AFD/CDN Classic Migration FAQ
+description: Frequently asked questions about migrating from AFD/CDN Classic to AFD Standard or Premium.
+author: jainsabal
+ms.author: jainsabal
+ms.service: azure-frontdoor
+ms.topic: overview
+ms.date: 08/06/2025
+
+#CustomerIntent: As a <type of user>, I want <what?> so that <why?>.
+---
+
+# AFD and CDN Classic Migration FAQ
+
+This document provides answers to frequently asked questions regarding the migration from Azure Front Door (AFD) Classic and CDN Classic to AFD Standard/Premium.
+
+### Will there be downtime during migration?
+
+No, there is no downtime during the migration. This is a control plane-only migration, meaning traffic delivery is unaffected.
+
+During migration, the classic Azure Front Door (AFD) endpoint mydomain.azurefd.net is created as a dummy custom domain on AFD standard/premium that is CNAMEd to AFD standard/premium endpoint mydomain.randomstring.z01.azurefd.net. It continues to receive traffic until you update the DNS record of AFD custom domain (www.mydomain.com) to mydomain.randomstring.z01.azurefd.net directly. It is highly recommended to change the CNAME from classic endpoint to AFD standard/premium endpoint after verification.
+
+Even in rare cases where the migration fails, traffic delivery continues to work as expected.
+
+There is no rollback support, please reach out to the support team for help if migration fails.
+
+
+
+### What should I do after migration?
+
+After migration:
+
+- Verify traffic delivery continues to work.
+
+- Update the DNS CNAME record for your custom domain to point to the AFD Standard/Premium endpoint (exampledomain-hash.z01.azurefd.net) instead of the classic endpoint (exampledomain.azurefd.net for classic AFD or exampledomain.azureedge.net). Wait for the DNS update propagation until DNS TTL expires, depending on how long TTL is configured on DNS provider.
+
+- Verify again that traffic works in the custom domain.
+
+- Once confirmed, delete the pseudo custom domain (i.e., the classic endpoint that was pointing to the AFD Standard/Premium endpoint) from the AFD Standard/Premium profile.
+
+### When I change my DNS CNAME from classic AFD endpoint to AFD standard/premium endpoint, does DNS propagation cause downtime?
+
+No, both classic endpoint and Std/premium endpoints point to the same IP, so the final resolution remains the same before and after DNS propagation.
+
+### When should I delete the classic SKU?
+
+For AFD Classic: After verifying that traffic works and the DNS record has been updated to point to the AFD Standard/Premium endpoint, you can safely delete the classic resource.
+
+For CDN Classic: You do not need to delete the classic resource. Migration is treated as a SKU upgrade, and the classic resource can remain.
+
+### Do I need to update my DevOps pipeline?
+
+Yes. After migration, make sure to update your DevOps pipeline to reflect the new AFD Standard/Premium configuration and endpoints.
+
+## Next step
+
+* Understand the [settings mapping between Azure Front Door tiers](tier-mapping.md).
+* Learn how to [migrate from Azure Front Door (classic) to Standard or Premium tier](migrate-tier.md) using the Azure portal.
+* Learn how to [migrate from Azure Front Door (classic) to Standard or Premium tier](migrate-tier-powershell.md) using Azure PowerShell.
+* Learn how to [migrate from Azure CDN from Microsoft (classic)](migrate-tier.md) to Azure Front Door using the Azure portal.