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 model

Blueprints

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

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 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 trigger