Want to contribute to the Python SDK? Come join the Python Development Syncs every other Wednesday at 9 AM PST. Click here to download the calendar invite.

Last year, we finished shipping the v1.0.1 version of the .NET Semantic Kernel SDK. As part of this move, we made the SDK much easier to use while also increasing its power. We now have our eyes set on getting the Python and Java SDKs to parity with the .NET version. We believe this is important because many companies have both Python and .NET teams; by aligning the SDKs, developers can use the same concepts across languages.

To provide visibility of these changes, we’ve created the following content that outlines 1) the major changes coming to the Python SDK, 2) why we’re making those changes, and 3) when we expect them to land.

The major headline though is that we’re targeting a Beta release (which should have most of the breaking changes) by the end of February with a full v1.0 release coming later this semester. If you ever want to see our progress, you can check out the remaining items we have on our public backlog.

How we’re prioritizing the changes for Python

As we update the Python SDK, we’re focused on front-loading the significant breaking changes. This proactive approach is designed to minimize disruption for developers who want to use the Python SDK as soon as possible. On our public backlog, we’ve labeled these changes as “urgent” and they appear above the Beta cutline. Our goal is to complete these items before March.

The remaining changes necessary to reach parity with .NET may introduce breaking changes, but they should be minimal in nature. On our backlog, we’ve labeled these changes as “high”.

Once we’ve made the larger “urgent” changes, it should be easier for contributors to create PRs on the SDK’s codebase. We’ve already begun to label some features with “needs help” to flag the issues we think should be straightforward enough for the community to work on. If you would like to contribute, please leave us a comment on any of these issues and we’d be happy to help you make your first PR.

1. The enhancements coming with the Beta release

The upcoming Beta release of the Python SDK is all about setting a strong foundation so that future breaking changes are minimized. Because of this, you’ll notice that many of the first issues we’ll be working on are related to naming, control flow, and concept alignment with the .NET SDK.

1.1. Skills will finally become “plugins”

The shift from ‘skills’ to ‘plugins’ is already in flight. With the change, not only are we aligning our terminology to fit with the rest of the industry, but we’re also adding an actual abstraction at the Skill/Plugin level. This makes using plugins more modular so that they can be reused across multiple kernels. This will also simplify the current Python code that requires developers to juggle functions using PluginCollection and ReadOnlyPluginCollection.

To see the status of this item, please refer to issue #4560, #4667, and #4634.

1.2. SKContext will be replaced with KernelArguments

In the .NET library, we found that managing the previous context objects made using the kernel overwhelming to use. By replacing SKContext with Kernel and KernelArguments, we’re simplifying the interaction model, making it more intuitive while offering advanced features such as better state encapsulation, more granular control over execution, and easier access to kernel operations.

To see the status of this item, please refer to issue #4565.

1.3. We’ll lay the foundation for multi-modal support

We believe that this year, there will be more and more models that support more than just text. For example, with GPT-4-vision, you can already provide images as inputs. Other models like Whisper allow you to generate audio. To support these different content types, we’ll introduce the base KernelContent class from the .NET library. In the future, we’ll extend it to support other content types like ImageContent, VideoContent, AudioContent, and more.

To see the status of this item, please refer to issue #4598.

1.4. The SDK will become more idiomatic

To deliver an SDK that resonates with Python developers, we’re reevaluating the interfaces and idioms to align with standard Python conventions. This includes removing view classes, removing _async where it’s not necessary, and other changes so the SDK doesn’t feel like a simple port of a .NET SDK.

To see the status of this item, please refer to issue #4628 and #4629.

2. The additional changes coming soon to Python

Following the Beta release, we plan to introduce additional features that will further enhance the power and usability of the SDK.

2.1. Complex type support

The current Python kernel only supports string input and outputs between functions. To fully integrate native code, however, we found that we needed to fully embrace all data types (including objects) in the .NET SDK. As part of this work, you’ll soon be able to pass in any object type into the kernel as an argument.

To see the status of this item, please refer to issue #4635.

2.2. Enable automatic function calling

One of the best new features of the .NET SDK has been automatic function calling. With it, developers can avoid most of the boilerplate code necessary to build agents that automatically use plugins. This simplifies the interaction with AI services, making the development of sophisticated AI-powered applications more accessible.

To see this in action in the .NET SDK, check out the getting started example on our learn site. To see the status of this item, please refer to issue #4553.

2.3. Observe what’s happening with kernel hooks

We’re introducing kernel hooks to offer developers windows into the kernel’s internal processes. These hooks will allow developers to attach custom logic to various events, such as pre-execution (invoking) or post-execution (invoked), providing a powerful tool for debugging, extending the kernel’s functionality, and enforcing responsible AI.

To see this in action in the .NET SDK, check out the hooks kernel syntax example. To see the status of this item, please refer to issue #3038.

2.4. Support chat roles in prompts

To make it easier for prompt engineers to author chat completion prompts in the .NET SDK, we added a new syntax to prompts to allow developers to add roles to their messages. We’ll be adding the same syntax to Python so prompts can easily be shared between the two SDKs.

To see this in action in the .NET SDK, check out the chat role kernel syntax example. To see the status of this item, please refer to issue #3318.

2.5. Register multiple supported models for a prompt

By allowing the registration of multiple models for a single prompt, the SDK will enable more adaptive and responsive AI interactions. Developers can optimize their applications to select the most suitable model based on the context, improving performance and user experience.

2.6. Introduce Gen 4 and Gen 5 planners

Lastly, we want introduce the Handlebars and Function Calling Stepwise planners to the Python SDK. These new planners have been proven to work faster and more reliability than the old planners, so we’re excited to get them in the hands of our Python community.

To learn more about our Gen 4 and Gen 5 planners, you can read about their launch here. To see the status of this item, please refer to issue #4641 and #4642.

That’s not all!

There are many more features that are necessary for parity between Python and .NET; too many to include in this single blog post. If you’re interested in seeing the full list, please check out our backlog for Python.

By sharing our plans and progress transparently, we aim to build trust and facilitate a smooth transition to the v1.0 release. We’re excited to see how these changes will inspire developers to build innovative applications and contribute to the evolution of the Semantic Kernel SDK.