.NET: Python: Add AGENTS.md files and update coding standards (#3644)

* Add AGENTS.md files and update coding standards for Python

- Add root python/AGENTS.md with project structure and package links
- Add AGENTS.md for each package describing purpose and main classes
- Update .github/copilot-instructions.md with improved structure
- Update python/CODING_STANDARD.md with API review guidance:
  - Future annotations convention (#3578)
  - TypeVar naming convention (#3594)
  - Mapping vs MutableMapping (#3577)
  - Avoid shadowing built-ins (#3583)
  - Explicit exports (#3605)
  - Exception documentation guidelines (#3410)
- Simplify python/.github/instructions/python.instructions.md to reference AGENTS.md
- Remove AGENTS.md from .gitignore

* Fix purview import path in AGENTS.md

* Address PR review comments and restructure instructions

- Slim down .github/copilot-instructions.md to reference language-specific docs
- Add ADR section explaining templates and purpose
- Create dotnet/AGENTS.md with .NET-specific build commands, conventions, and sample guidance
- Update Python build/test instructions for core vs isolated changes
- Fix Microsoft.Extensions.AI package references
- Update kwargs guidance per issue #3642
- Fix Python sample helper placement (top, not bottom)
- Document new 'typing' poe task in DEV_SETUP.md

* Add 'typing' poe task to run both pyright and mypy

* Add kwargs guidelines from issue #3642 to CODING_STANDARD.md

* Clarify that connector packages pull in core as dependency
This commit is contained in:
Eduard van Valkenburg
2026-02-05 11:27:46 +01:00
committed by GitHub
Unverified
parent de80543302
commit eaad042241
30 changed files with 1026 additions and 201 deletions
+7 -22
View File
@@ -1,26 +1,11 @@
---
applyTo: '**/agent-framework/python/**'
---
- Use `uv run` as the main entrypoint for running Python commands with all packages available.
- Use `uv run poe <task>` for development tasks like formatting (`fmt`), linting (`lint`), type checking (`pyright`, `mypy`), and testing (`test`).
- Use `uv run --directory packages/<package> poe <task>` to run tasks for a specific package.
- Read [DEV_SETUP.md](../../DEV_SETUP.md) for detailed development environment setup and available poe tasks.
- Read [CODING_STANDARD.md](../../CODING_STANDARD.md) for the project's coding standards and best practices.
- When verifying logic with unit tests, run only the related tests, not the entire test suite.
- For new tests and samples, review existing ones to understand the coding style and reuse it.
- When generating new functions, always specify the function return type and parameter types.
- Do not use `Optional`; use `Type | None` instead.
- Before running any commands to execute or test the code, ensure that all problems, compilation errors, and warnings are resolved.
- When formatting files, format only the files you changed or are currently working on; do not format the entire codebase.
- Do not mark new tests with `@pytest.mark.asyncio`.
- If you need debug information to understand an issue, use print statements as needed and remove them when testing is complete.
- Avoid adding excessive comments.
- When working with samples, make sure to update the associated README files with the latest information. These files are usually located in the same folder as the sample or in one of its parent folders.
Sample structure:
1. Copyright header: `# Copyright (c) Microsoft. All rights reserved.`
2. Required imports.
3. Short description about the sample: `"""This sample demonstrates..."""`
4. Helper functions.
5. Main functions that demonstrate the functionality. If it is a single scenario, use a `main` function. If there are multiple scenarios, define separate functions and add a `main` function that invokes all scenarios.
6. Place `if __name__ == "__main__": asyncio.run(main())` at the end of the sample file to make the example executable.
See [AGENTS.md](../../AGENTS.md) for project structure, commands, and conventions.
Additional guidance:
- Review existing tests and samples to understand coding style before creating new ones
- When verifying logic, run only related tests, not the entire suite
- Resolve all errors and warnings before running code
- Use print statements for debugging, then remove them when done