Morph MORPH
SIGN IN SIGN UP
microsoft / semantic-kernel UNCLAIMED

Integrate cutting-edge LLM technology quickly and easily into your apps

0 0 11 C#
Normal View History Raw
Initial commit
2023-03-16 19:54:34 -07:00
# Copyright (c) Microsoft. All rights reserved.
Python: cleanup/sync/fixes (for examples, docs, tests, notebooks) (#317) ### Motivation and Context The `python-preview` branch is under active development and many docs/tests/examples are getting a bit out of sync. There are also a few small cleanup chores/refactors to make _usage_ easier (e.g., to make examples cleaner). I've grouped these small fixes (plus a few bug fixes) into this "cleanup" PR. ### Description This PR does the following: 1. Updates the out-of-date example in `README.md` 2. Fixes all 5 of the notebooks we support right now (1,2,3,4, and 6; notebook 5 is planner, I've blanked out most of the code there so we don't confuse people, especially as the planner API is changing) 3. Fixes a bug w/ `stop_sequences` in `(Azure)OpenAITextCompletion` 4. Fixes a bug introduced in our upgrades to the embeddings cosine-sim check (we should add more thorough tests here) 5. Cleans up tests 6. Ensures end-to-end tests are all runnable 7. Fixes up the `kernel_extensions` to work more naturally (so that end users can use them directly on the `kernel` object and get good type-hinting)
2023-04-04 16:44:59 -05:00
from semantic_kernel.kernel import Kernel
Initial commit
2023-03-16 19:54:34 -07:00
Python: Bump Python version to 1.41.1 for a release (#13705) ### Motivation and Context Bump Pythong version to 1.41.1 for a release <!-- Thank you for your contribution to the semantic-kernel repo! Please help reviewers and future users, providing the following information: 1. Why is this change required? 2. What problem does it solve? 3. What scenario does it contribute to? 4. If it fixes an open issue, please link to the issue here. --> ### Description Bump Pythong version to 1.41.1 for a release <!-- Describe your changes, the overall approach, the underlying design. These notes will help understanding how your code works. Thanks! --> ### Contribution Checklist <!-- Before submitting this PR, please make sure: --> - [X] The code builds clean without any errors or warnings - [X] The PR follows the [SK Contribution Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md) and the [pre-submission formatting script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts) raises no violations - [X] All unit tests pass, and I have added new tests where possible - [X] I didn't break anyone :smile:
2026-03-25 15:34:30 +09:00
__version__ = "1.41.1"
Python: Introduce feature decorator to allow for experimental and release candidate decorator usage (#10691) ### Motivation and Context <!-- Thank you for your contribution to the semantic-kernel repo! Please help reviewers and future users, providing the following information: 1. Why is this change required? 2. What problem does it solve? 3. What scenario does it contribute to? 4. If it fixes an open issue, please link to the issue here. --> This change is required to improve the flexibility and maintainability of our feature annotation system. Previously, separate decorators (e.g., `experimental_function` and `experimental_class`) were used to mark experimental features, resulting in code duplication and limiting our ability to handle additional feature stages. As our SDK evolves, we need a unified approach that can support multiple stages—such as experimental, release candidate, and future states—while also allowing version information for release candidate features to be centrally managed. ### Description <!-- Describe your changes, the overall approach, the underlying design. These notes will help understanding how your code works. Thanks! --> This PR refactors our feature decorators by introducing a unified `stage` decorator that updates the docstring and attaches metadata for both functions and classes. Two convenience decorators, `experimental` and `release_candidate`, are built on top of `stage`: - The `experimental` decorator marks features as experimental and sets an `is_experimental` attribute. - The `release_candidate` decorator supports multiple usage patterns (with or without parentheses and with an optional version parameter) to mark features as release candidate and sets an `is_release_candidate` attribute. This unified approach reduces duplication, simplifies the codebase, and lays the groundwork for easily extending feature stages in the future. This decorator supports the following usage patterns: - `@experimental` (for both classes and functions) - `@release_candidate` (no parentheses) - `@release_candidate()` (empty parentheses) - `@release_candidate("1.21.3-rc1")` (positional version) - `@release_candidate(version="1.21.3-rc1")` (keyword version) ### Contribution Checklist <!-- Before submitting this PR, please make sure: --> - [X] The code builds clean without any errors or warnings - [X] The PR follows the [SK Contribution Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md) and the [pre-submission formatting script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts) raises no violations - [X] All unit tests pass, and I have added new tests where possible - [X] I didn't break anyone :smile:
2025-02-27 09:17:54 +09:00
Python: Bump Python version to 1.32.0 for a release. (#12287) ### Motivation and Context Bump Python version to 1.32.0 for a release. <!-- Thank you for your contribution to the semantic-kernel repo! Please help reviewers and future users, providing the following information: 1. Why is this change required? 2. What problem does it solve? 3. What scenario does it contribute to? 4. If it fixes an open issue, please link to the issue here. --> ### Description Bump Python version to 1.32.0 for a release. <!-- Describe your changes, the overall approach, the underlying design. These notes will help understanding how your code works. Thanks! --> ### Contribution Checklist <!-- Before submitting this PR, please make sure: --> - [X] The code builds clean without any errors or warnings - [X] The PR follows the [SK Contribution Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md) and the [pre-submission formatting script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts) raises no violations - [X] All unit tests pass, and I have added new tests where possible - [X] I didn't break anyone :smile:
2025-05-28 09:45:05 +09:00
DEFAULT_RC_VERSION = f"{__version__}-rc9"
Python: Introduce feature decorator to allow for experimental and release candidate decorator usage (#10691) ### Motivation and Context <!-- Thank you for your contribution to the semantic-kernel repo! Please help reviewers and future users, providing the following information: 1. Why is this change required? 2. What problem does it solve? 3. What scenario does it contribute to? 4. If it fixes an open issue, please link to the issue here. --> This change is required to improve the flexibility and maintainability of our feature annotation system. Previously, separate decorators (e.g., `experimental_function` and `experimental_class`) were used to mark experimental features, resulting in code duplication and limiting our ability to handle additional feature stages. As our SDK evolves, we need a unified approach that can support multiple stages—such as experimental, release candidate, and future states—while also allowing version information for release candidate features to be centrally managed. ### Description <!-- Describe your changes, the overall approach, the underlying design. These notes will help understanding how your code works. Thanks! --> This PR refactors our feature decorators by introducing a unified `stage` decorator that updates the docstring and attaches metadata for both functions and classes. Two convenience decorators, `experimental` and `release_candidate`, are built on top of `stage`: - The `experimental` decorator marks features as experimental and sets an `is_experimental` attribute. - The `release_candidate` decorator supports multiple usage patterns (with or without parentheses and with an optional version parameter) to mark features as release candidate and sets an `is_release_candidate` attribute. This unified approach reduces duplication, simplifies the codebase, and lays the groundwork for easily extending feature stages in the future. This decorator supports the following usage patterns: - `@experimental` (for both classes and functions) - `@release_candidate` (no parentheses) - `@release_candidate()` (empty parentheses) - `@release_candidate("1.21.3-rc1")` (positional version) - `@release_candidate(version="1.21.3-rc1")` (keyword version) ### Contribution Checklist <!-- Before submitting this PR, please make sure: --> - [X] The code builds clean without any errors or warnings - [X] The PR follows the [SK Contribution Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md) and the [pre-submission formatting script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts) raises no violations - [X] All unit tests pass, and I have added new tests where possible - [X] I didn't break anyone :smile:
2025-02-27 09:17:54 +09:00
__all__ = ["DEFAULT_RC_VERSION", "Kernel", "__version__"]
Reference in New Issue Copy Permalink