Azure Functions: V2 Python Programming Model

Azure Functions: V2 Python Programming Model

Azure Functions: V2 Python Programming Model


The Azure Functions team released the V2 programming model for Python, learn more about the offering and try it out today!


The v2 programming model is designed to provide a Functions development experience that is more familiar to Python developers. Key features include triggers and bindings declared as decorators, importing through blueprints, and easy to reference documentation.


With the V2 programming model, customers will benefit from:

  • A simplified folder structure, where there will be fewer files within a function application. Multiple functions in the application can now be defined in the same file.
  • Triggers and bindings will be represented as decorators, eliminating the need for the `function.json` configuration file.
  • Streamlined workflow with importing through blueprints. Blueprints will also promote logical grouping of functions within the application.
  • Documentation is more easily accessible with a new ‘View Template’ option in VS Code.

The v2 new programming model enables customers to create function applications with ease – leaning towards fewer Functions concepts, and instead emphasizing Python principles. Furthermore, it provides an easier import experience, requires fewer files, and is supported by easy to reference documentation. Note that leveraging the v2 model will alter the way you create functions, but the underlying experience when it comes to monitoring, debugging, and deployment will remain the same.


Folder Structure


The structure of function apps with the new Python programming model has been simplified. When creating a new function within a function application, there will no longer be a new folder required. Instead, all functions within the function application can be defined in a single file, `function_app.py`. The file, `function.json`, where triggers and bindings were configured in the v1 model, will also no longer be required. Instead, triggers and bindings will be configured in `function_app.py` alongside function definitions. Triggers and bindings will now be represented as decorators, simulating an experience similar to well-known Python frameworks.


Following is a side-by-side comparison of the programming models, highlighting the difference in changes.


Sample folder structure using the v1 and v2 programming modelSample folder structure using the v1 and v2 programming model




The v2 programming model introduces the concept of blueprints. A blueprint is a new class instantiated to register functions outside of the core function application. The functions registered in blueprint instances aren't indexed directly by function runtime. To get these blueprint functions indexed, the function app needs to register the functions from blueprint instances.


Using blueprints, developers can define functions in multiple Python files, promoting logical grouping of functions within the function app into modular components. Blueprints also provide extensible public function app interfaces to build and reuse APIs.


Decorator Based


In the v2 programming model, triggers and bindings will be represented as decorators. This aligns with well-known Python frameworks and will result in functions being written in much fewer lines of code. Using decorators will also eliminate the need for the configuration file ‘function.json’, and promote a simpler, easier to learn model.




Documentation will be more readily accessible and easier to reference with PyDocs. As shown below, when declaring triggers and bindings, in depth documentation is available from the moment one starts typing.


Documentation and hints are available during developmentDocumentation and hints are available during development


Furthermore, when creating a new function in Visual Studio Code, customers will have the option to “Preview Template” before creating a function. This will enable customers to learn about the trigger and view the code without creating the function or leaving the IDE.


Option to "Preview Template" in VS Code to learn more about the triggerOption to "Preview Template" in VS Code to learn more about the trigger


Next Steps


Try out the v2 programming model today!


Developer Reference Guide

Getting started with VS Code

Getting started with terminal/command prompt

Code samples

Known limitations and workarounds


We’d love to hear your thoughts and feedback, let us know by posting your comments on this discussion.

Published on:

Learn more
Azure Compute Blog articles
Azure Compute Blog articles

Azure Compute Blog articles

Share post:

Related posts

HTTP Trigger Azure Function Authorization Types simplified

Here' how you can quickly understand what are the different Authorization Levels to be set while working with HTTP Azure Functions.

13 hours ago

Increasing Security for SQL Server Enabled by Azure Arc

Back in November 2023, the least privileges deployment model was introduced as a public preview. After thorough testing, we are excited to ann...

2 days ago

Govern your Azure Firewall configuration with Azure Policies

Introduction:  In the rapidly evolving digital landscape, securing cloud environments is more critical than ever. Azure Firewall emerges ...

2 days ago

Azure Verified Modules - Monthly Update [June]

AVM Module Summary The AVM team are excited that our community have been busy building AVM Modules. As of June 17th, the AVM Footprint curren...

2 days ago

General Availability Announcement: Azure VM Regional to Zonal Move

Today, we announce the general availability of the capability to convert regional VMs to a zonal configuration within the same region. Th...

3 days ago

Azure WAF Public Preview: JavaScript Challenge

Microsoft has recently released JavaScript challenge in public preview for Azure WAF on Application Gateway and Azure Front Door.   Appro...

4 days ago
Stay up to date with latest Microsoft Dynamics 365 and Power Platform news!
* Yes, I agree to the privacy policy